코드 인스펙션 룰을 작성하는 과정

by NeO posted Jul 31, 2018
?

단축키

Prev이전 문서

Next다음 문서

ESC닫기

크게 작게 위로 아래로 댓글로 가기 인쇄

훌륭한 Code Inspection 도구가 많고, 도구의 완성도와 빌트인 룰의 효용성이 좋아지고 있지만 여전히 프로젝트에서는 커스텀 룰을 필요로 합니다. 이것은 시큐어코딩이나 보안감사, 데이터 관리평가와 같은 외적 요인에 의한 동기와, 코드의 가독성 향상, 유지보수성 향상, 더 좋은 코드와 디자인을 위한 개발자/아키텍트의 내적 동기가 만날 때 보다 큰 효과를 발휘합니다.


제가 알고 있는 어떤 Code Inspection 툴에서는 기 정의된 수 백개의 Java 또는 C/C++ 룰셋에서 프로젝트에 맞게 취사선택하여 목적에 맞는 룰셋을 정의하고 짧게는 수 분, 길게는 수 시간에 걸쳐 스캔을 돌려 룰 위반 결과를 표시하고, (해당 툴이 IDE기반이라면) 룰을 위반한 코드라인으로 이동할 수 있도록 링크를 걸어주고 (만일 위반사항이 쉽게 리팩토링할 수 있는 룰이라면) 퀵픽스할 수 있는 기능이 있었습니다. 그리고 Birt나 기타 보고서 양식툴을 활용하여 위반사항을 문서화할 수 있는 기능이 있었습니다.


예를 들어 J2EE 우수사례, J2SE 우수사례라는 카테고리 안에 Switch, 루프, 문자열, 리플렉션, 비교 등 코딩법에 대한 룰 뿐만 아니라 싱글턴, 데코레이터 같은 디자인패턴과 컴포넌트의 loose & couple을 가늠하는 메트릭들과 코드중복, 사이클로메틱 복잡도 같은 소프트웨어 메트릭 그리고 저작물로서의 코드를 바라보는 하나의 지표가 될 수 있는 Halstead 메트릭도 포함되어 있었습니다.


현존하는 Code Inspection 툴을 충분히 많이 사용해보지는 않았지만, 정적분석 툴의 기본적인 사용방법과 활용방법, 예를 들어 개발자 또는 QA팀의 관리하에 룰셋을 정의하고 스캐닝하며 IDE, 커맨드라인 또는 API를 활용하여 CI에서 빌드 전 스텝에서 동작하거나 또는 엄격한 QA/QC를 한다면 스코어기반으로 평가하여 만족하지 못하면 코드를 커밋하지 못하게 하는 등의 툴체인 활용법은 비슷할 것이라 생각합니다. 결과적으로 어떤 툴을 선택할 것인가는 우리가 원하는 룰이 정의되어 있는지, 사용하는 언어에 대한 분석이 가능한지, 결과값을 평가할 근거를 축적할 수 있는지 그리고 커스텀 룰을 정의하여 운영할 수 있는지에 귀결됩니다.


일반적으로 우수사례에 해당하는 베스트프랙티스 룰은 그야말로 일반적으로 그러하더라 라는 룰이며, 정의된 모든 룰을 만족시켜야 바른 코드가 되는 것은 아닙니다. 그래서 취사선택을 합니다. 만일 룰셋을 만들지 않고 가능한 모든 룰을 만족하는 방향을 잡았다면 룰 간에 충돌하는 일이 발생할 수 있습니다. 특히 명명룰이라면 그렇습니다.


그리하여, (사설이 길어졌지만) 이 문서에서는 커스텀 룰을 작성할 때 생각해야 하는 것에 대해 이야기해보겠습니다.


사전지식

먼저, 커스텀 룰을 만들 도구에 대해 알아야 합니다. 

도구에 대한 이해가 충분히 되었다면 커스텀 룰을 만들기 위해 필요한 기술이 무엇인지 알아야합니다.

예를 들어, 도구가 Eclipse 기반의 플러그인형태로 개발된 툴이라면 기본적으로 플러그인을 개발하는 환경과 방법에 대해 알아야 할 것입니다. 더불어 도구에서 제공하는 SDK를 파악하여 기 정의 룰과 동일하게 적용할 수 있어야 합니다.

그리고 커스텀 룰을 구현할 언어가 무엇인지 알아야합니다. Java일 수도 있고 Xpath일 수도 있고 제 3의 언어일 수도 있습니다.

룰을 적용할 대상언어에 대해서도 알아야합니다. 룰을 구현하려면 어떤 소스가 어떻게 파싱되었을 때 어떻게 표시해주어야 한다는 기본적인 스펙이 나와야합니다. 그러기 위해서는 명확하게 정해진 룰 명세를 아키텍트로부터 제공받거나 프로젝트 개발가이드를 분석할 줄 알아야합니다.

마지막으로 분석된 룰 명세에 맞게 AST(Abstract Syntax Tree)를 이용하여 분석대상을 가져오고 적절하게 바인딩, 파싱하고 명명룰이라면 특히 Regular Expression 등으로 룰 준수여부를 파악해야할 것입니다.


그림1.png


위 그림은 Code Inspection을 위한 단계를 말해줍니다. 

발주회사의 개발가이드와 컨설팅 회사로부터 받은 개발환경, 개발가이드 그리고 개발사의 QA팀에서 가지고 있는 표준 개발가이드 등의 소스로부터 커스텀 룰을 정의하고 개발하며 테스트하는 작업을 반복하고 안정화할 것입니다.


룰 정의하기

룰을 정의하는 단계는 가장 어렵고 중요합니다. 기 정의된 룰에서 만족하지 못한 요건은 커스텀 룰에서 커버 가능한지 여부를 알아야합니다. 룰을 개발하는 사람이 이 과정에 참여하지 않는 경우 룰 설명과 샘플가이드와 코드를 미리 만들어두는 것이 좋습니다. 샘플 코드를 만들어 놓으면 룰을 개발한 사람이 해당 룰을 정확히 작성했는지 평가하는 데에 사용할 수 있으므로 룰 정의단계에서 위와 같은 산출물이 나오는 것이 좋습니다.

대체적으로 개발가이드에서는 특정 prefix, postfix로 시작하거나 끝나는 클래스 안에 특정 이름의 메소드가 정의되어 있어야 한다거나, try catch문에서 catch문 내에 Exception에 대한 변수명은 명명규칙을 따른다거나 하는 (예를 들어, DevBizException 이라면 대문자만 따와서 dbe라고 명명한다거나) 룰을 만듭니다. 메소드의 파라미터 타입이나 변수명, 코드명에 대한 명명룰도 있을 수 있습니다. 또 메타데이터 연동하여 명명룰에 맞는지 여부를 파악하는 룰도 있을 수 있습니다.

개인적으로 기억에 남는 룰은 Javadoc의 @author에 홍길동이라는 이름을 쓰지 않는 룰입니다.


룰 개발하기

룰 정의하기 단계보다는 덜 어렵지만 앞서 나열한 사전지식을 십분 발휘해야하는 단계입니다.

만일 앞 단계에서 테스트용 샘플코드가 만들어지지 않았다면 룰 개발자는 자신이 만든 룰이 정상동작하는지 파악하가 위해 샘플코드를 만들어야 할 것입니다. 이 과정에서 룰을 잘못해석한다면 전혀 다른 룰을 만들것이고 또한 전혀 다른 샘플코드가 만들어질 것입니다. 특히 룰을 정의하고 개발하는 주체가 서로 다르다면, 샘플코드는 더 중요해집니다.

현업의 개발가이드 변경과 개발구조 변경도 변수입니다.

유관부서에서는 변경된 개발가이드에 맞게 룰을 보완할 수 있도록 대응해야합니다.

룰 개발자는 룰 명세를 기반으로 적용될 소스의 범위를 가져오고 내용에 맞게 필터링, 바인딩 또는 파싱하여 구현한 후 위반사항을 표시하도록 개발합니다.


룰 테스트하기

1차적으로 룰개발자는 스스로가 작성한 룰을 테스트하기 위한 샘플코드를 작성합니다. 그러나 최종적으로 인수자 또는 수행자의 샘플을 통한 룰 테스트가 존재하며 두 방법 모두가 수행되어야 할 것입니다.

실제 룰을 적용할 코드베이스는 방대하기 때문에 그 결과를 가지고 룰의 성공/실패 판단을 하기는 여러가지로 어렵습니다.

False Positive를 찾을 수는 있겠지만 테스트 목적의 의도된 샘플코드가 아니라면 False Negative를 찾기는 힘들기 때문입니다.


룰 안정화하기

이렇게 한 사이클 돌았다면 안정화단계는 위 과정을 반복하며 프로젝트에 맞는 룰을 개발하고 효율적으로 운영하기 위한 방안을 마련하는 단계가 될 것입니다.

커스텀 룰에는 다음과 같은 대표적인 유형이 있는것 같습니다.

타입 및 scope에 따른 명명규칙, 타입 또는 구문을 금지, 기타 홍길동같은 룰과 표준정의, 프레임워크 사용정의 룰입니다.



이 글은 약 7-8년전 당시 작성했던 자료를 기반으로 작성했습니다.

보다가 관심이 있는 분들께 도움이 될만한 링크가 있어 추가합니다.


http://codesonar.grammatech.com/detecting-domain-specific-coding-errors

https://www.grammatech.com/products/source-code-analysis

https://itnext.io/ast-for-javascript-developers-3e79aeb08343

https://www.slideshare.net/BohdanLiashenko/ast-for-javascript-developers

http://www.egovframe.go.kr/wiki/doku.php?id=egovframework:dev:imp:inspection

https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

http://www.ieee-scam.org/2008/papers/Anderson.pdf