static analysis

Edit

이번에 PMD를 프로젝트에 적용하면서 생긴 저의 의견을 정리하면 다음과 같습니다.

PMD에는 광범위한 Rule이 정의되어 있어서, 적용할 Rule의 선별작업이 개발초기에 이루어 져야 할 것을 보입니다.
QA쪽에서는 각 프로젝트마다 쓰인 룰셋 파일을 수집하고, 어느 정도 정리가 되면 신규 프로젝트에 디폴트로 제공해서, 개발자와의 협의를 거쳐 프로젝트마다의 특성에 맞게 수정 반영할 수 있으면 효율적인 적용이 가능할 것입니다.
룰셋파일은 당연히 SVN에 올려져서 프로젝트 팀원들이 공유하고, 같은 Rulset으로 Eclipse plugin으로는 실시간 체크, maven+hudson으로는 통합체크를 해서 빠른 피드백이 이루어졌으면 합니다.
이미 개발을 진행하고 있는 프로젝트 중반에 적용하는 것은 어려움이 많을 것으로 보이며, 테스트코드 작성을 하나도 안 하고 있는 프로젝트에서는 더욱 그러할 것으로 보입니다. ( Rule중에는 단순 명칭변경만이 아닌 로직의 리팩토링을 요구하는 Rule도 많은데, 무작성 시키는대로 고치다보면 에러를 만드는 수도 있습니다. 참고 삼아 제 경험을 소개드리면, String.startsWith 메서드 다음에 한글자의 문자열이 오면 이를 chatAt(0)을 쓰고 ==로 비교하라고 경고를 주는 Rule도 있는데, 시키는대로 하면 빈 스트링(“”)값이 들어가면 startWith로는 문제없는 것이 chatAt으로는 실행시 outOfIndexException을 내게 됩니다. 다행히 intostatic프로젝트에는 해당 케이스를 검사해주는 테스트코드가 있어서 서버에 빌드하기 전에 알 수 있었지만, 그렇지 않은 경우에는 수정이 더욱 신중해야할 것 같습니다.)
코드 검사와 테스트코드, Hudson과 같은 Continuous Integration tool과는 아주 밀접한 관계가 있으므로 관련 프로세스와 표준을 정리해서 개발팀에 안내하는 것도 좋을 것 같습니다. (예를 들어 다소 엄격한 절차를 만든다면, 코드 검사 빌드는 Hudson에서 1시간마다 1번씩 돌리고 에러나 warning개수가 50개가 넘으면 자동으로 QA에게 메일이 가도록 설정하게 한다던지..하는 예입니다.)

결국 프로젝트에 공식 적용하기 위해서는 개발시작 때 개발표준 확인+RuleSet 선정의 작업을 하고 들어가야 될 것 같습니다. 다음에 프로젝트를 시작할 때는 이를 염두에 두고 진행을 하겠습니다. 참고로 더 필요하신 자료 등이 있으면 연락주시기 바랍니다~

http://www.laatuk.com/tools/review_tools.html

http://www.cs.cmu.edu/aldrich/courses/654/tools/index.html

http://findbugs.sourceforge.net/

Glean- 다양한 코드 검사 도구의 결과를 통합하는 도구

웹 프로젝트에서 jslint로 자바스크립트 검증하기: maven 또는 ant

http://stackoverflow.com/questions/207652/how-do-commercial-java-static-analysis-tools-compare-with-the-free-ones

So it depends on whether your priority is quality checking (Findbugs, Coverity) or security vulnerability analysis (Klocwork, or Fortify).

Jones Capers, Assessment and Control of Software Risks

'이미 1978년에 LOC는 .. 생산성과 품질 데이터를 수집하는데 있어 신뢰할 수 없다는 것이 입증됐다.' , 'LOC 페트릭을 사용하는 것은 가장 심각한 문제로 분류된다'

JavanCSS

Simian

Optimization SimplifyStartsWith

자바 패스파인더를 이용한 소프트웨어 모델 검사

Macker

Architectural Rule check

http://innig.net/macker/

XRadar

http://xradar.sourceforge.net/

Relief

프로젝트 의존관계, 패키지 크기 등을 시각화

http://www.workingfrog.org/

JDepend + Eclipse + Maven2

JDepend는 Java패키지간의 의존성에 대한 수치들을 알려 주는 도구입니다.

JDepend의 Eclipse의 Plugin은 를 Update site에 추가하면 설치할 수 있습니다. 다음의 링크들에서 보다 자세한 내용을 참조할 수 있습니다. 분석을 하고자 하는 소스폴더 위에서 우클릭을 한 후 'Run JDepend Analysis' 메뉴를 선택하면 의존성 분석 결과가 나옵니다.

이를 Maven을 통해서 생성하는 jdepend-maven-plugin 은 pom.xml에 아래와 같이 추가할 수 있습니다.

<reporting>
    .....
    <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>jdepend-maven-plugin</artifactId>
        <version>2.0-beta-2</version>
    </plugin>
</reporting>

mvn jdepend:generate 또는 mvn site명령을 통해서 보고서가 생성됩니다. mvn site로 실행했다면 Hudson의 프로젝트 홈에서 Maven Generated Site 메뉴를 통해서도 확인할 수 있습니다. 샘플페이지 에 생성된 보고서의 형식이 나와있습니다.

JDepend 첫페이지나 생성된 보고서 안에서도 위의 요약 테이블에 수치들에 대한 설명이 잘 나와있습니다. 간단히 요약해서 정리하면,

TC (Total Classes) : 전체 클래스 수. CC + AC
CC (Concrete Classes) : Inteface나 추상클래스가 아닌 구상 클래스 수
AC (Abstract Classes) : Interface나 Abstract Class로 선언된 클래스 수
Ca (Afferent Couplings) : 이 패키지를 의존하고 있는 다른 패키지의 수. 이 패키지의 책임감을 나타내는 지표
Ce (Efferent Couplings) : 이 패키지가 의존하고 있는 클래스가 있는 다른 패키지의 수. 이 패키지의 독립성을 나타내는 지표.
A (Abstractness) : 총 클래스 갯수 중 인터페이스나 추상클래스의 비율. 1이라면 해당 패키지는 추상클래스나 인터페이스 밖에 없는 것.
I (Instability) : 총 결합도 중 이 패키지의 외부의존성의 비율 (Ce / (Ce + Ca)). 변화에 대한 내성을 나타내는 지표. I=0이라면 완전하게 안정적인 것.
D (Distance from Main Sequence) : 이상적인 균형의 상태인 A + I = 1 의 함수에서 수직으로 떨어진 거리. (아래 그래프 참조)

가장 중요한 것은 패키지 간의 순환참조를 보여주는 Cycles 부분입니다.