http://metrics.sourceforge.net/
자신의 코드를 리팩토링하는 시점은 여러가지(예를 들면, 새 기능을 추가할 때)가 될 수 있겠지만, 이미 관리하기 힘들 정도로 난잡해진 코드를 리팩토링하기 시작해야할 때는 ‘무엇부터 리팩토링할 것인가‘를 결정해야한다. Martin Fowler는 그의 책 Refactoring에서 리팩토링을 해야하는 나쁜 코드의 증상을 ‘Bad Smell‘이라고 한다. 리팩토링의 우선 순위가 높은 코드는 아마 이러한 ‘Bad Smell’이 강하게 나는 코드일 것이다. ‘Bad Smell’을 맡는 방법은 눈으로 모든 코드를 직접 보는 방법도 있겠지만, 팀 개발을 할 경우, 매일 매일 commit되는 코드를 모두 보기란 쉽지 않은 일이다. 기계가 이 일을 대신해 줄 수는 없을까? Metrics는 바로 그러한 일을 해주는 Eclipse 플러그인으로, 코드의 질을 몇가지 유용한 기준들에 따라 수치화해서 보여주고, 정해진 수준을 넘어설 경우 경고도 해준다.
Metrics가 측정해주는 기준들에는 여러가지가 있지만, 일단 어떤 경우에나 유효하다고 생각되는 기준인 ‘Method Lines of Code‘를 채택해서 리팩토링 작업에 적용해보고 있다. ‘Method Lines of Code’는 말 그대로 메서드의 길이인데, 일반적으로 ‘Long Method‘는 이미 나쁜 코드이거나 나쁜 코드로 발전할 가능성이 상당히 높을 뿐더러, OOP에서는 대략 상식을 벗어나는 코드에 해당한다. 디폴트로 Maximum 값이 설정되어있지 않으므로, Preference에서 일단 이 Maximum 값을 가장 보수적인 수치인 100으로 설정(즉, 100라인 이상의 메서드를 경고)해서 리팩토링 대상을 찾고 있다. 현재 프로젝트에서 1등은 350라인이었다는 놀라운 사실도 발견했다. (다행히도, 내가 짠 코드는 아니었다.) 점차 이 기준을 강화해서 대략 50라인 정도로 만들어야 하지 않을까 싶다.
‘Method Lines of Code’를 해결하고 나면, McCabe Cyclomatic Complexity라는 기준을 적용해보려고 생각하고 있는데, 이 기준은 코드 상에서 얼마나 많은 분기가 존재하는가를 나타내는 것이다. 경험 있는 개발자라면 뼈저리게 느끼듯이, 분기가 많다면 코드는 이해하기 힘들다. 프로그래머가 프로그램을 이해하기 위해서는 프로그램의 특정 부분에서 존재할 수 있는 프로세스의 모든 상태들을 알고 있어야하기 때문이다. (디버깅 세션을 상상해보면 이를 이해하기 쉽다.) OO 프로그래밍의 중요한 강점 중의 하나가 바로 이러한 분기들을 객체의 polymorphism으로 해결하는 것이다. 이는 Procedural 프로그래밍에서도 마찬가지로, 경험 있는 C 프로그래머라면, function pointer를 이용해서 polymorphic behavior를 구현해본 경험이 많을 것이다.
최근에 강문식 군을 통해, 자신들의 프로덕트의 코드 품질을 공개하는 Open Quality (참여하고 있는 프로젝트들의 품질 데이터)라는 개념을 접할 수 있었고 매우 흥미로웠다. 이 곳을 통해 서비스를 받는 것도 가능한 것 같아 보이지만, Metrics의 기능을 Ant task를 사용해서 접근할 수 있기 때문에, 이를 Daily Build에 적용해서, 일단 코드의 품질을 실시간으로 팀내 정도에서 공유해보면 어떨까 생각하고 있는 중이다. 리팩토링을 통한 품질의 개선 정도나, 새 기능의 추가에 따른 품질의 저하 정도 등이 관찰 가능하게 될 것이고, 어쩌면 품질에 대한 다른 접근 방식이 가능하게 될 지도 모른다.