코드 관리에 관한 재미있는 외국 사례 :: 2009/09/22 10:28
|
|
얼마 전에 코드 공동 관리에 대한 재미있는 외국 사례를 하나 들었습니다.
코드를 관리하다보면 항상 골치가 아픈 부분 중에 하나가 코멘트(comment)입니다. 즉 주석 관리를 어떻게 하느냐 하는 것인데요.
이 회사 직원들은 개발을 몇 줄 혹은 얼마나 했느냐에 따라서도 포상을 받지만, 주석을 얼마나 정확히 달았느냐, 얼마나 많이 달았느냐에 따라서도 포상을 받습니다.
함수의 사용 방법을 적는 것은 물론이고, 함수를 호출하는 함수의 목록, 함수 호출 결과로 발생하는 side-effect의 목록, 함수 호출 시 발생할 수 있는 예외 상황, 그리고 함수에 전달되는 인자의 의미 등등을 전부 적습니다. 그러다 보면 주석문의 길이가 길어집니다. 이 회사 직원들은 주석도 평가와 포상의 대상이 된다는 사실을 알기 때문에, 아주 적은 양의 코드에도 아주 자세한 주석을 답니다.
그리고 주석과 실제 코드에 불일치를 발견한 사람에게는 가산점을 줍니다. 종종 주석이 제대로 업데이트 되지 않아 문제가 되는 경우를 많이 보게 되는데, 그런 문제를 포상체계를 통해 해소하고자 하는 것이죠.
주석을 포상과 직접적으로 연결한다는 아이디어는 얼핏 생각하면 좀 졸렬하기도 합니다만, 직원의 적극적인 참여를 이끌어 낼 수 있다는 점에서는 긍정적으로 생각됩니다.
이 이야기를 다른 사람들하고 좀 했더니, 주석 라인수를 생산성 기여도에 그렇게까지 많이 반영하는 것은 무리가 있지만, 가중치와 결합된 마일리지 체계를 도입해서 포상을 하면 긍정적일 수 있겠다는 데는 모두들 동의를 하더군요.
문서와 코드의 일치는, 언제나 문제가 되면서도 좀처럼 해결이 되지 않는 부분입니다. 이런 부분을 해결하기 위한 바람직한 방법을 항상 고민할 필요가 있다고 생각합니다.
-
Developer Capacities – Comment or not comment
Tracked from Bug Inside | 2009/10/07 19:08 | DEL(특히) 팀으로써 소프트웨어를 개발하다보면 주석을 잘 달라는 이야기를 자주 듣는다. 하지만 반대로 주석이 필요없는 코드를 짜라는 이야기도 어렵지 않게 들을 수 있다. 얼핏 생각하기엔 서로 모순되는 주장 같기도 한 이 가이드들에 대해 이해해보고, 또 좋은 주석을 달기 위한 팁과 고려 사항들까지 일부 정리해보도록 하겠다. 주석의 역사 이야기를 시작하기 전에 주석에는 어떤 종류가 있는지부터 명확히 해야 하는데, 주석의 역사에서 시작하는 것이 자연스러울듯...
