코드 정리

소프트웨어 회사 JunkCode의 경영진은 강화된 코딩 가이드라인을 도입한 뒤 생산성이 떨어졌다는 사실을 알고 놀라고 실망했다. 모든 개발자가 소프트웨어 저장소의 master 브랜치에 푸시하는 모든 코드 변경이 코딩 가이드라인을 엄격히 따라야 한다는 것이었다. 개발자 중 한 명인 Perikles는 이 규정이 시행되기 훨씬 전부터 그렇게 해 왔으니 그리 어려운 일은 아닐 터였다.

생산성 저하의 원인을 파악하는 데 시간을 쏟는 대신, 팀장은 요구 사항을 완화하자고 제안한다. 개발자는 코드를 가끔 정리 단계(cleanup phase)로 실행해 저장소를 깔끔하게 유지하기만 하면 가이드라인을 약하게 위반하는 코드를 푸시할 수 있다.

그녀는 개발자 코드의 "더러움(dirtiness)"을 그 개발자가 한 가이드라인 위반 푸시, 즉 더티 푸시(dirty push)의 합으로 정의하되 각각을 푸시한 이후 지난 일수로 가중한 값으로 측정하자고 제안한다. 더티 푸시 이후 지난 일수는 푸시 다음 자정마다 1씩 증가하는 계단 함수다. 따라서 어떤 개발자가 1일, 2일, 5일에 더티 푸시를 했다면 6일의 더러움은 5 + 4 + 1 = 10이다. 그녀는 더러움이 20에 도달하기 전에 코딩 가이드라인 위반을 모두 고치는 정리 단계를 반드시 완료해야 한다고 제안한다. 개발자 중 한 명인 Petra는 이 규칙이 회사 방침이기 때문에 지켜야 한다고 느낀다. 어기면 왜 Perikles처럼 할 수 없냐고 묻는 걱정 많은 관리자들과 어색한 회의를 해야 한다. 그래도 그녀는 정리 단계를 최대한 드물게 실행하고 싶어 하며, 항상 반드시 필요해질 때까지 미룬다. 정리 단계는 항상 하루가 끝날 때 실행되며 그날까지의 모든 더티 푸시를 고친다. 모든 개발자는 매년 초에 새 프로젝트로 배치되므로 새해 전날 자정이 지난 뒤에는 더러움이 남아 있어서는 안 된다.

첫째 줄에 Petra가 한 해 동안 한 더티 푸시의 수 n (1 ≤ n ≤ 365)이 주어진다. 둘째 줄에 Petra가 더티 푸시를 한 날짜 d1, d2, . . . , dn (1 ≤ di ≤ 365, 1 ≤ i ≤ n)이 주어진다. i < j이면 di < dj라고 가정할 수 있다.

Petra가 더러움을 항상 20 미만으로 유지하기 위해 필요한 정리 단계의 총 횟수를 출력한다.