HowToMeasureProgrammerProductivity

프로그래머의 생산성 측정이 필요한 가장 큰 이유는 스스로의 생산성을 측정해봄으로써 자신을 발전시키기 위해서이다. If you can't measure it, you can't improve it. 측정 가능한 무언가 기준이 있다면 프로그래머의 의욕을 고취시키는데도 도움이 될 것이다. Ron Jeffries는 늘 자신의 일을 정량적으로 잴 수 있는 방법을 찾으려고 애쓴다고 한다.

CleanCodeThatWorks. Ron Jeffries가 한 말이며 TDDBE 첫 페이지에도 인용된 말이다. 이것이 아마 프로그래머의 목표일 것이다. TDD는 CleanCodeThatWorks에서 work를 먼저 해결하고 그 다음 clean을 해결하는 방법이다. 이 정의에 따르면 프로그래머의 생산성은 시간당 생산해내는 CleanCodeThatWorks의 양이라고 요약할 수 있다. 고로 우리가 측정해야할 것은 work, 즉 기능의 양과 clean, 코드의 품질 두 가지이다. 물론 정량적으로 재기 쉬운 것은 아니지만 NBA의 IBM Award 정도의 신뢰도는 확보할 수 있을 것이다. 언제나 그렇듯 통계는 전체의 진실을 반영하진 못하지만 늘 일부분의 진실은 반영한다.

work의 양을 재는 방법으로 FunctionPointAnalysis가 있지만 별로 좋은 방법은 아니라고 생각된다.

다른 방법은 UserStory와 test의 개수를 적절한 비율로 혼합하여 계산하는 방법이다. TDD에 익숙해질수록 test나 UserStory 단위의 크기는 어느 정도 normalize될 것이라 기대를 하는 것이다.

더 중요한 것은 품질을 재는 것이다. 20명 짜리 팀이 2년 동안 해냈던 프로젝트를 혼자서 2주만에 해냈다든가 하는 에피소드를 들을 때마다 과연 소프트웨어의 크기란 것이 무엇일까 하는 의문이 들곤 한다. 품질에 대한 측정이 없는 사이즈의 측정은 LoC를 측정하는 것과 다를 바 없다.

clean code에 대해서 여러 가지 정의가 가능하겠지만 Kent Beck의 rules of simple code가 유용할 것이다.

1. Runs all the tests;
2. Contains no duplication;
3. Expresses all the important design intentions;
4. Minimizes entities (e.g. classes and methods).

1번은 테스트 돌려보면 간단하다. 2번은 [http://pmd.sourceforge.net/cpd.html cpd]가 도움이 될 것이다. 3번은 어렵다. 아직은 test에 assert가 있는지 정도 밖에. magic number 체크도 도움이 될 것이다. 4번은 entities 뿐 아니라 size problem을 종합적으로 잴 수 있을 것이다. 메쏘드의 길이, 클래스의 크기, 클래스당 메쏘드의 숫자 등등.

[http://pmd.sourceforge.net/ PMD]가 꽤 유용한 도구가 될 것이다.

XP를 한다면 스토리 점수를 이용한 속도 측정이 어느 정도 도움이 될 것이다.