메뉴 건너뛰기

훌륭한 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

Who's NeO

ALM, SW 모델링, SW 정적분석, Devops 특히 CI/CD, APM을 통한 Shiftleft에 관심이 많습니다. 

차세대 APM Cisco AppDynamics와 모바일 앱 모니터링 VMware Apteligent를 소개합니다.

http://www.solulink.co.kr

Atachment
첨부 '1'
?
  • profile
    PSEG 2019.01.24 00:54
    오. 멋집니다. SonarQube 커스텀 룰을 만드는데 도움이 되겠네요.

 


  1. AppDynamics Cognition Engine을 통한 이상징후와 근본원인 분석

    Anomaly Detection and Root Cause Analysis with AppDynamics Cognition Engine Summary AIOps와 어플리케이션 인텔리전스를 결합하여 AppDynamics Cognition Engine은 시스템에서 발생하는 막대한 양의 메트릭을 분석하고 인사이트를 얻을 수 있습니다. AppD...
    Date2019.07.09 ByNeO Reply0 Views43
    Read More
  2. 코드 인스펙션 룰을 작성하는 과정

    훌륭한 Code Inspection 도구가 많고, 도구의 완성도와 빌트인 룰의 효용성이 좋아지고 있지만 여전히 프로젝트에서는 커스텀 룰을 필요로 합니다. 이것은 시큐어코딩이나 보안감사, 데이터 관리평가와 같은 외적 요인에 의한 동기와, 코드의 가독성 향상, 유...
    Date2018.07.31 ByNeO Reply1 Views747
    Read More
  3. 버그는 줄이고 릴리즈는 빠르게 : APM이 Software Development Life Cycle을 개선하는 법

    요약 소프트웨어 개발 라이프사이클(SDLC)에 연관된 모든 사람들의 작업은 어플리케이션과 비즈니스 성능 정보를 쉽게 확보할 수 있도록 함으로써 개선될 수 있다.   시작하며 일련의 상호의존적 절차를 분리된 행동으로 ...
    Date2018.07.25 ByNeO Reply0 Views452
    Read More
  4. 2. Service Endpoint를 활용한 Database 성능 모니터링

    본 문서는 다음 문서를 번역한 글입니다. 총 2개의 글로 이루어진 이번 연재는 AppDynamics Global Services team의 John Aronson이 작성한 글로, Database 성능 개선을 위한 AppDynamics 활용법이 설명되어 있습니다. https://blog.appdynamics.com/p...
    Date2018.06.21 ByNeO Reply0 Views454
    Read More
  5. 1. Business Transaction을 통해 문제가 되는 Database Query 찾아내기

    본 문서는 다음 문서를 번역한 글입니다. 총 2개의 글로 이루어진 이번 연재는 AppDynamics Global Services team의 John Aronson이 작성한 글로, Database 성능 개선을 위한 AppDynamics 활용법이 설명되어 있습니다. 글이 조금 깁니다. https://blog...
    Date2018.05.02 ByNeO Reply0 Views562
    Read More
  6. DevOps 시작을 위한 가이드

    데브옵스(DevOps)의 인기는 몇 년동안 지속되고 있다. 데브옵스는 문화의 변화, 자동화, 변경 관리, 지속적인 배포 등을 설명하는데 사용된다. 본질적으로 데브옵스는 개발(Dev)팀과 운영(Ops)팀이 협업하여, 더 빠른고 신뢰성있는 릴리즈 파이프라인 구축하는...
    Date2018.04.13 ByTom Reply0 Views1004
    Read More
  7. 7. 릴리즈와 시간의 흐름에 따른 모바일 메트릭을 관리하자

    7. 릴리즈와 시간의 흐름에 따른 모바일 메트릭을 관리하자 올바른 메트릭 관리하기 다양한 앱 사용자의 요구사항에 대응하는 성공적인 앱의 공통적인 요소는 바로 데이터를 지속적으로 측정하고 모니터링하는 데에 중점을 두고 있다는 것입니다. 성능메...
    Date2018.03.12 ByNeO Reply0 Views753
    Read More
  8. 6. 배터리 광탈과 데이터 과소비를 막자

    6. 배터리 광탈과 데이터 과소비를 막자 배터리 광탈이나 데이터 과소비는 사용자가 중요시 여기는 항목이지만, 앱을 제공하는 회사에서는 종종 잊어버리기 쉬운 메트릭입니다. 연구조사 업체인 IDC1의 조사에 따르면 대다수의 사용자들이 새로운 핸드폰을 ...
    Date2018.03.08 ByNeO Reply0 Views479
    Read More
  9. 5. 주요 Flow에서 네트워크 호출을 모니터링하자

    5. 주요 Flow에서 네트워크 호출을 모니터링하자 주요 Flow의 속도를 빠르게 하는 3가지 방법 1. 상위 3개의 인터랙션을 측정하라 앱의 속도를 빠르게 하기 위한 첫 걸음은 인터랙션을 완수하는 데 걸리는 시간을 측정하는 것입니다. Userflow 기...
    Date2018.03.06 ByNeO Reply0 Views460
    Read More
  10. 4. 인터랙션 타임을 최적화하여 사용자 경험을 개선하자

    4. 인터랙션 타임을 최적화하여 사용자 경험을 개선하자 우리 앱이 사용자를 당혹스럽게 만들고 있지는 않은지? App load time과 더불어 느린 트랜잭션은 사용자를 당혹스럽게 합니다. Jakob Nielsen의 UI디자인에 관한 powers of 10 연구결과에 의하...
    Date2018.02.27 ByNeO Reply0 Views403
    Read More
Board Pagination Prev 1 2 3 Next
/ 3