신화적인 남자 달 개발자 당 10 라인-큰 프로젝트에 얼마나 가깝습니까? [닫은]

모든 사람들은 항상 "신화적인 남자의 달"에서 "하루에 개발자 당 10 줄"을 이길 수 있고 프로젝트를 시작하면 보통 하루에 몇 백 줄을 얻을 수 있다고 말합니다.

그러나 이전 고용주에서 모든 개발자는 매우 날카로 웠지만 엄청난 프로젝트, 백만 줄 이상의 코드, 매우 엄격한 인증 요구 사항 및 다른 수백만 라인 프로젝트와의 인터페이스였습니다. 어떤 시점에서, 호기심을 불러 일으키기 위해 그룹의 배송 제품에 코드 줄을 작성했으며 (우리가 개발 한 도구는 계산하지 않음), 개발자마다 하루에 약 12 ​​줄이 추가되었습니다. 변경 사항, 테스트 코드 또는 개발자가 매일 실제 프로젝트 코드를 작성하지 않았다는 사실을 세지 마십시오.

다른 사람들은 어떻게 지내고 있습니까? 그리고 어떤 종류의 요구 사항에 직면하고 있습니까?

추가 된 줄 수는 프로젝트 상태에 따라 크게 달라지며 새 프로젝트에 추가하는 비율은 시작하는 프로젝트의 비율보다 훨씬 높습니다.

큰 프로젝트에서는 대부분 부품 간의 관계를 파악하는 데 대부분의 시간을 소비하며 실제로 변경 / 추가하는 데 소량 만 사용됩니다. 반면 새로운 프로젝트에서-당신은 대부분 충분히 씁니다.

현재 프로젝트 중 하나에서 일부 모듈에서 코드베이스에 마이너스 라인 수를 기여한 것을 자랑스럽게 생각합니다. 어떤 코드 영역이 불필요하게 복잡 해졌고 더 깨끗하고 명확한 디자인으로 단순화 될 수 있는지 식별하는 것은 유용한 기술입니다.

물론 일부 문제는 본질적으로 복잡하고 복잡한 솔루션이 필요하지만 요구 사항이 잘못 정의되거나 변경되는 대부분의 대규모 프로젝트 영역에서는 라인 당 더 많은 문제가있는 지나치게 복잡한 솔루션이 있습니다.

해결해야 할 문제가 있다면 줄 수를 줄이는 솔루션을 선호합니다. 물론 작은 프로젝트를 시작할 때 매일 10 줄 이상의 코드를 생성 할 수는 있지만 작성한 코드의 양은 생각하지 않고 코드의 기능과 성능은 생각하지 않습니다. 나는 확실히 하루에 10 줄을 이길 것을 목표로하지 않을 것입니다.

나는이 인용문을 좋아한다 :

코드 줄을 세려면 "생산 라인"으로 간주하지 말고 "소비 라인"으로 간주해야합니다. -Edsger Dijkstra

때때로 당신은 추가하는 것보다 코드를 제거함으로써 더 많은 기여를했습니다

이 측정 항목 사용을 중지해야합니다. 대부분 의미가 없습니다. 응집력, 결합 및 복잡성은 코드 라인보다 더 중요한 지표입니다.

다른 사람들은 어떻게 지내고 있습니까?

저는 회사 에서 유일하게 풀 타임 개발자 이며 지난 7 년간 500,000 줄의 OCaml 및 F # 코드를 작성했으며 이는 하루에 약 200 줄의 코드와 같습니다. 그러나이 코드의 대다수는 각각 수백 줄 길이의 수백 개의 개별 프로젝트로 구성된 자습서 예제입니다. 또한 OCaml과 F #간에 중복이 많이 있습니다. 우리는 50kLOC보다 큰 사내 코드 기반을 유지하지 않습니다.

나는 우리 자신의 소프트웨어를 개발하고 유지하는 것 외에도 지난 7 년 동안 업계의 많은 고객들과 상담했습니다. 첫 번째 고객을 위해 3 개월 동안 하루에 20 줄의 코드 인 2,000 줄의 OCaml을 작성했습니다. 다음 고객을 위해 우리 중 4 명은 개발자 당 하루에 2,000 줄의 코드 인 6 개월의 문서와 수백만 줄의 C / C ++ / Python / Java / OCaml 코드를 생성하는 컴파일러를 작성했습니다. 다른 클라이언트의 경우 C ++ 50kLOC를 6 개월 동안 6kLOC의 F #으로 바 꾸었습니다. 이는 하루에 -352 줄의 코드입니다. 들어 또 다른 클라이언트 , 나는 하루에 코드 0 라인 때문에 같은 크기입니다 F #으로 OCaml의의 15kLOC를 재 작성하고 있습니다.

들어 우리의 현재 클라이언트 , 나는 하루에 코드 -6,000 라인이 될 것이다 (맞춤형 컴파일러 작성) 1 년 F 번호의 ~ 160kLOC와 C ++ 및 매스 매 티카 코드 1600000 개 라인을 대체합니다. 이 프로젝트는 현재까지 제가 가장 성공한 프로젝트이며 고객에게 지속적인 비용으로 연간 수백만 달러를 절약 할 것입니다. 모든 사람이 하루에 -6,000 줄의 코드를 작성하는 것을 목표로해야한다고 생각합니다.

실제로 "The Mythical Man-Month"(이 문서를 읽는 사람은 누구나 쉽게 구할 수있는 사본이 있어야 함)의 사본을 확인하지 않고 Brooks가 작성된 라인으로 생산성을 살펴 보는 장이있었습니다. 그에게 흥미로운 점은 하루에 쓰여진 실제 줄 수가 아니라 어셈블러와 PL / I에서 거의 같은 것으로 보인다는 사실입니다 (고급 언어라고 생각합니다).

Brooks는 일종의 임의의 생산성 수치를 포기하지는 않았지만 실제 프로젝트의 데이터를 사용하여 작업하고 있었으며 평균적으로 하루 12 라인이었을 수도 있습니다.

그는 생산성이 달라질 수 있다고 지적했다. 그는 컴파일러가 애플리케이션 프로그램보다 3 배, 운영 체제는 컴파일러보다 3 배 어렵다고 말했다. (그는 카테고리를 분리하기 위해 3의 승수를 사용하는 것을 좋아 한 것 같습니다.)

그가 프로그래머의 생산성 사이의 개별적인 차이점을 이해했는지는 모르겠지만 (크기 순서의 논쟁에서 그는 7 가지 차이점을 가정했지만) 우리가 아는 것처럼 우수한 생산성은 더 많이 쓰는 것이 아닙니다 코드뿐만 아니라 작업을 수행하기 위해 올바른 코드를 작성합니다.

환경에 대한 질문도 있습니다. Brooks는 개발자를 더 빠르거나 느리게 만드는 것에 대해 조금 추측했습니다. 많은 사람들과 마찬가지로, 그는 현재 유행 (시간 공유 시스템을 사용한 대화 형 디버깅)이 기존 방식보다 더 나은지에 대해 의문을 제기했습니다 (전체 시스템을 사용하여 2 시간 동안 신중하게 사전 계획).

이를 감안할 때, 그가 생각했던 실제 생산성 수치는 쓸모가 없다고 생각합니다. 이 책의 지속적인 가치는 사람들이 배우지 않고 계속 유지하는 원리와보다 일반적인 교훈에 있습니다. (만일 모든 사람이 그것들을 배웠다면이 책은 잠재 의식적인 마음과 같은 무언가가 있다는 프로이트의 모든 주장과 마찬가지로 역사적 관심사 일 뿐이다.)

하루에 수백 줄의 코드를 쉽게 얻을 수 있습니다. 그러나 하루에 수백 줄의 코드를 얻으려고 노력하면 쉽지 않습니다. 하루에 줄이 거의 없거나 전혀없는 디버깅과 며칠을 거치면 평균이 다소 빨리 떨어집니다. 나는 어려운 문제를 디버깅하는 데 몇 주를 보냈으며 대답은 1 또는 2 줄의 코드입니다.

물리적 인 코드 라인을 말하는 것은 의미가 없다는 것을 깨닫는 것이 훨씬 낫습니다. LoC (물리적 코드 라인)의 수는 코딩 스타일에 따라 달라 지므로 개발자마다 규모가 다를 수 있습니다.

.NET 세계에서는 LoC를 계산하는 편리한 방법이 있습니다. 시퀀스 포인트 . 시퀀스 포인트는 디버깅 단위이며, 브레이크 포인트를 넣을 때 진한 빨간색으로 강조 표시된 코드 부분입니다. 시퀀스 포인트를 사용하면 논리적 LoC에 대해 이야기 할 수 있으며이 지표는 다양한 .NET 언어에서 비교할 수 있습니다. 논리적 LoC 코드 메트릭은 VisualStudio 코드 메트릭, NDepend 또는 NCover를 포함한 대부분의 .NET 도구에서 지원됩니다.

예를 들어, 다음은 8 LoC 방법입니다 (시작 및 끝 대괄호 시퀀스 포인트는 고려되지 않음).

LoC 생산은 장기적으로 계산되어야합니다. 어떤 날에는 200 LoC 이상을 뱉고 어떤 날에는 단일 LoC를 추가하지 않아도 버그를 수정하는 데 8 시간을 소비합니다. 언젠가 죽은 코드를 정리하고 LoC를 제거 할 것입니다. 언젠가는 기존 코드를 리팩토링하고 전체 LoC를 추가하지 않는 데 모든 시간을 소비합니다.

개인적으로 다음과 같은 경우에만 생산성 점수에서 단일 LoC를 계산합니다.

1. 단위 테스트에 포함됩니다
2. 그것은 일종의 코드 계약과 관련이 있습니다 (가능한 경우, 모든 LoC를 계약으로 확인할 수있는 것은 아닙니다).

이 조건에서 지난 5 년 동안 .NET 개발자를위한 NDepend 도구를 코딩하는 개인 점수 는 코드 품질을 저하시키지 않으면 서 하루 평균 80 개의 물리적 LoC입니다 . 리듬이 지속되며 조만간 감소하지는 않습니다. 대체로 NDepend는 현재 약 115K 물리적 LoC의 가중치를 부여하는 C # 코드베이스입니다.

LoC 계산을 싫어하는 사람들에게 (여기서 의견에서 많은 것을 보았습니다), 일단 적절하게 보정되면 LoC 계산이 훌륭한 평가 도구 임을 증명합니다 . 특정 개발 환경에서 달성 한 수십 가지 기능을 코딩하고 측정 한 후 LoC의 TODO 기능의 크기와 프로덕션에 제공하는 데 걸리는 시간을 정확하게 추정 할 수있는 시점에 도달했습니다.

은 총알 같은 것은 없습니다.

이와 같은 단일 메트릭은 그 자체로는 쓸모가 없습니다.

예를 들어, 나는 자신의 클래스 라이브러리를 가지고 있습니다. 현재 다음과 같은 통계가 적용됩니다.

총 라인 : 252.682
코드 라인 : 127.323
코멘트 : 99.538
빈 라인 : 25.821

주석을 전혀 쓰지 않는다고 가정 해 봅시다. 즉, 127.323 줄의 코드입니다. 귀하의 비율로 코드 라이브러리를 작성하는 데 약 10610 일이 걸립니다. 29 년입니다.

C 코드이기 때문에 29 년 동안 코드를 작성하지 않았으며 C #은 오랫동안 사용되지 않았습니다.

자, 당신은 코드가 그다지 좋지 않다고 주장 할 수 있습니다. 분명히 나는 ​​하루 12 줄을 넘었을 것이므로 분명히 동의 할 것입니다. 그러나 타임 라인을 낮추려면 1.0이 릴리스 될 때 (그리고 실제로 2.0이 릴리스 될 때까지 실제로 시작하지 않았습니다), 2002-02-13, 약 2600 일, 평균은 하루 48 줄의 코드입니다.

그 코드 줄이 모두 좋습니까? 도대체 그러나 하루에 12 줄의 코드로 줄이겠습니까?

도대체

모든 것이 다릅니다.

하루에 수천 줄의 코드를 생성하는 최고 수준의 프로그래머와 하루에 수백 줄의 코드를 생성하는 중간 프로그래머를 가질 수 있으며 품질은 동일합니다.

그리고 그렇습니다, 벌레가있을 것입니다.

당신이 원하는 총액은 균형입니다. 발견 된 버그 수, 코드의 복잡성, 버그 수정의 어려움과 비교하여 변경된 코드 양.

Steve McConnell은 자신의 저서 "Software Estimation"에서 흥미로운 통계를 제공합니다 (p62 표 5.2) 그는 프로젝트 유형 (Avionic, Business, Telco 등)과 프로젝트 크기 10kLOC, 100kLOC, 250kLOC를 구분합니다. LOC / StaffMonth의 각 조합에 대한 번호가 제공됩니다. EG Avionic : 200, 50, 40 인트라넷 시스템 (내부) : 4000, 800, 600 내장 시스템 : 300, 70, 60

예 : Avionic 250-kLOC 프로젝트의 경우 40 (LOC / Month) / 22 (Days / Month) == <2LOC / day입니다!

프로젝트의 실제 개발 단계가 전체 프로젝트 시간의 20-30 %에 불과할 수있는 폭포 개발 날짜 에서 비롯된 것 같습니다 . 전체 코드 줄을 가져와 전체 프로젝트 시간으로 나누면 하루에 약 10 줄을 얻을 수 있습니다. 코딩 기간만으로 나누면 사람들이 인용 한 내용에 더 가까이 다가 갈 수 있습니다.

우리의 코드베이스는 약 150 만 년 동안 2.2MLoC입니다. 그것은 프로젝트의 전체 수명 동안 개발자 당 하루 에 약 75 줄의 C ++ 또는 C #을 만듭니다.

프로젝트 크기와 관련된 개발자 수가이 요소에 큰 영향을 미친다고 생각합니다. 나는 내 경력보다 훨씬 뛰어 났지만 항상 혼자 일했기 때문에 다른 프로그래머와 일하는 데 손실이 없습니다.

좋은 계획, 좋은 디자인 및 좋은 프로그래머. togheter를 모두 얻으면 한 줄을 작성하는 데 30 분을 소비하지 않습니다. 예, 모든 프로젝트는 중지하고 계획하고, 생각하고, 토론하고, 테스트하고 디버깅해야하지만 모든 회사는 하루에 두 줄씩 테트리스가 작동하도록 군대가 필요합니다 ...

결론적으로, 만약 당신이 시간당 2 줄로 나를 위해 일한다면, 당신은 나에게 많은 커피를 마시고 발을 마사지하여 해고 당하지 않는 것이 좋습니다.

모든 것이 C로 작성된 시스템 응용 프로그램 일 때이 매해 관리자의 사탕이 만들어 졌다고 의심합니다. 다른 경우가 없다면 마법의 숫자는 응용 프로그램의 언어, 규모 및 특성에 따라 수십 배가 될 수 있기 때문입니다. 그리고 의견과 속성을 할인해야합니다. 그리고 궁극적으로 누가 작성된 코드 줄에 관심이 있습니까? 당신이 10K 라인에 도달했을 때 끝내야합니까? 100K? 그래서 임의적입니다.

그건 소용 없어.