everydayminder
사실, 개발하면서 주석을 다는 것은 무척이나 흥미로운 귀찮은 일이다. 게다가 포맷을 지키고, 어떤 파라미터가 넘겨지고, 리턴 값은 어떻고, 어떤 상황에서 어떤 exception이 던져진다는 것까지 써야 한다면 더더욱 그렇다. 보통 프로그램부터 작성한 후, 주석을 달라고 한다면, 주석을 다는 것이 아주 하기 싫은 일이 될 가능성이 크다고 생각한다. 주석을 달면서, 코드 리뷰도 하고, 분석도 하고, 수정도 하는 선순환이 되기 보다는 상당히 형식적인 주석 작업이 될 확률이 더 높아진다. 오히려, 보다 양질의 주석을 달기에 좋은 시기는 해당 부분을 프로그램화 할 때라고 생각한다. 모든 프로젝트를 완료한 후, javadoc을 사용하는 대신에 초기부터 javadoc을 사용해 보자. 자신이 작성하는 코드와 비슷한 시..
지난 글t에서 hudson에 JUnit 테스트를 수행하는 방법에 대해 소개하였다. 물론, 코드의 품질은 어떤 테스트 코드를 어떻게 작성하느냐에 코드의 신뢰도가 달라진다. 그렇다면, 좋은 테스트는 테스트 케이스의 수에 단순히 비례할까? 두 말할 필요 없이 얼마나 양질의 테스트가 어떻게 수행되었는지가 중요할 것이다. 본 포스트에서 말하고자 하는 metric은 테스트의 커버리지(coverage)이다. 즉, 테스트의 커버리지가 높은 프로젝트 코드들은 검증을 거친 부분이 많으므로, 상대적으로 양질이라고 볼 수 있다. Emma는 프로젝트 코드와, 프로젝트 코드를 테스트하는 테스트 코드를 조합하여 비교함으로써, 주어진 테스트 코드가 원본 소스 코드에 대해 어느 정도의 커버리지를 갖는지를 조사해 준다. Emma는 어디..
