|
|
 |
|
| 코드 품질 도우미 - 코드 애널라이저 |
| |
| [ 이병철(IT 테크라이터) 2005/10/21] |
| |
품질 좋은 코드를 만드는 것은 매우 어려운 일이다. 여기서 품질이 좋다는 말의 의미는 단순히 버그가 적은 것만을 말하는 것은 아니다. 코드의 수행 속도도 빨라야 하며, 잘 정리되어 있어 나중에 코드의 수정이 필요 할 때 쉽게 알아 볼 수 있어야 한다.
점차적으로 소프트웨어의 구성이 복잡해져 감에 따라, 코드에 요구되는 사항들은 점차 늘어나고 있다. 그로 인해 퀄리티 높은 코드를 만드는 것은 점점 더 어려워져 간다. 이러한 문제를 해결 하기 위해 많은 개발자들은 코딩시에 적용할 나름의 원칙을 만들기 시작하였고, 코딩 컨벤션이나 약간의 디자인 패턴 적용 등은 이제 상당히 대중화 되어 있다고 할 수 있다.
비주얼 스튜디오 닷넷이 출시 된 이후, 닷넷 프레임워크에 대해서도 다양한 코딩 가이드라인이 제시되었다. MS 사는 이러한 내용들을 모아 "닷넷 프레임워크 디자인 가이드라인"을 만들었고, 이의 사용을 권고하고 있다.
하지만 이러한 가이드라인의 적용을 개발자 개개인이 알아서 하는 것은 쉽지 않은 일이다. 프로젝트의 빠듯한 일정 때문에 꼼꼼히 살피지 못하고 넘어가는 경우도 매우 흔하며, 무엇보다도 개발자의 수준에 따라 적용 여부가 크게 달라지기 때문이다.
경험이 풍부하고 우수한 개발자의 경우 가이드라인의 내용 중 상당 부분이 경험에 의해 체화되어 있다. 그렇기 때문에 굳이 가이드라인을 의식하지 않아도 가이드라인의 내용 중 상당 부분이 적용 된 품질 좋은 코드가 나오는 반면에, 경험이 적은 초급 개발자의 경우는 전혀 다른 결과를 보이게 된다.
이러한 이유로 MS는 gotdotnet.com을 통해, 코드를 분석하고 문제의 소지가 있는 부분을 알려 주는 툴인 FxCop (http://www.gotdotnet.com/team/fxcop/)을 제공 해 왔다.
비주얼 스튜디오 2005에서는 FxCop의 기능을 IDE에 통합하여 제공하고 있다(C/C++ 언어를 위해서는 PREFast를 제공하지만, 이번 연재에서는 FxCop에 대해서만 다루겠다). 코드 애널라이저(코드 분석 기능)로 불리우는 새로운 기능을 살펴 보도록 하자.
코드 분석의 시작 - 코드 분석 옵션 설정
우선 코드 분석 기능을 사용하기 위해서는 코드 분석 기능을 활성화 시켜야 한다. Project ' Properties 메뉴를 선택하고 왼쪽 하단에 위치한 Code Analysis 탭을 선택하면 다음과 같은 화면이 나타난다.
 | | 코드 분석 옵션 설정 |
화면 상단의 Enable Code Analysis 체크 박스를 설정하면, 코드 분석 기능을 사용 할 수 있게 된다. 하단에는 지원하는 규칙들이 나열되어 있으며, 체크박스를 이용하여 해당 규칙을 사용할 것인지를 결정 할 수 있다.
기본적으로 제공 되는 규칙들은 설계, 국제화, 상호운용성, 유지보수성, 이식성, 이름 설정, 성능, 안정성, 보안, 사용성 등의 카테고리로 구성되어 있으며, 전체 규칙의 갯수는 200여개에 이른다.
상세한 분석 결과와 도움말
설정을 마치고 나면 이제 해당 프로젝트에서 코드 분석 기능을 활용 할 수 있다. 솔루션 익스플로러에서 컨텍스트 메뉴를 이용하거나, Build 메뉴에서 Run Code Analysis를 실행 할 수 있으며, 비주얼 스튜디오는 현재 코드를 새로 빌드 하고 코드 분석 결과를 경고(Warning)로 표시 해 준다.
 | | 코드 분석 실행 메뉴 |
 | | 코드 분석 실행 결과 |
위의 그림은 필자가 예전에 작성했던 코드를 분석한 결과이다. 에러는 전혀 없으며, 정상적으로 동작하는 코드였지만 40개의 경고가 나타났다. 명명 규칙 위반, 보안 위험, 다국어 환경 지원 등에 대한 다양한 내용으로 구성 되어 있었으며, 해당 오류를 클릭 한 후 Show Error Help 컨텍스트 메뉴를 이용하여 정확한 내용을 볼 수 있었다.
 | | 경고에 관한 도움말 예 |
도움말은 상당히 잘 구성되어 있었으며(모두 영어라는 점이 아쉽기는 하지만 한글 버전이 나오면 해결 될 것이다), 오류의 원인, 수정 방법, 이 규칙을 제외해도 되는 경우, 예제 등이 자세히 나타나 있었다. 이러한 도움말을 통하여 MS의 가이드라인을 정확히 이해 할 수 있으며, 권고대로 수정해 감에 따라 좀 더 품질 좋은 코드를 작성하는 습관을 몸에 배게 할 수도 있을 것이다.
물론 때에 따라서는 경고의 내용이 너무 자세하며, 불필요하게 많다고 느낄 수도 있을 것이다. 간단한 샘플 프로그램을 작성하는데 국제화를 생각 할 필요는 없지 않은가? 이러한 경우에는 앞서 설명한 대로 옵션에서 해당 규칙을 적용하지 않도록 설정하면 된다(모든 규칙을 사용 할 경우, 비주얼 스튜디오가 자동적으로 생성하는 코드에서도 상당한 경고가 나타난다.).
하지만 때에 따라서 특정 메소드에만 규칙을 적용하고 싶지 않을 때도 있다. 이미 충분히 검증 된 코드라 가이드라인의 내용을 적용 하지 않는 것이 오히려 나은 경우, 경고의 중요도가 낮아 고치지 않기로 결정한 경우 등을 예로 들 수 있다. 그런데 이러한 경우에도 코드 분석 시 계속 경고가 나타난다면, 프로젝트를 함께 수행하는 다른 팀원들에게 혼란을 줄 것이다.
이러한 경우에 코드 내부에 약간의 속성을 기술 하여, 해당 코드에 대해서는 경고를 발생하지 않도록 할 수 있는데 이를 ISS(In Source Suppression)라고 부른다.
SuppressMessage 속성을 부가하여 해당 코드에 대해 경고를 발생 시키지 않게 되는데, 기본적인 사용법은 다음과 같다.
[Scope:SuppressMessage("Rule Category", "Rule Id", "Justification", "MessageId", "Scope", "Target")]
이 속성의 구체적인 사용법을 기술 하는 것은 이 글의 범위를 벗어나는 것이므로, 구체적인 사용법을 알고 싶은 독자는 MSDN(http://msdn2.microsoft.com/en-us/library/ms182068)의 내용을 참고 할 것을 권한다.
팀 시스템 구성 요소와의 연동
코드 분석 기능은 비주얼 스튜디오 팀 시스템의 다른 구성 요소들과 맞물려 동작 할 수 있다. 소스 코드를 체크 인 할 때 항상 코드 분석 기능을 수행하게 할 수 있으며, 팀 빌드 기능과 연동하게 할 수도 있다.
이러한 연동을 지원함으로써, 비주얼 스튜디오 팀 시스템은 품질이 확인 된 코드만을 체크 인 하도록 개발자들에게 강제한다. 또한 자동 빌드시 문제가 발생하지 않을 것을 보증 할 수 있다(최근 일일 빌드(Daily Build)에 대해 많은 논의가 되고 있으며, 그의 장점이 알려져 가고 있는 중이다. 조엘 스폴스키는 그의 블로그에서 일일 빌드에 대해 재미 있게 설명하고 있다. 관심 있으신 분은 참고하시기 바란다.).
이러한 방식이 지나치다고 느껴져 개발자로 하여금 거부감을 느끼게 할 지도 모르겠다. 하지만 복잡한 버그의 경우 종종 무시되는 경향이 있고, 바쁜 일정 때문에 다시 코드를 인스펙션(조사)하지 않는 경우가 많은 현실에서 코드의 품질을 유지하는데 도움이 될 것이라는 것은 확실하다. 물론 과유불급이라는 말도 있으므로 적용할 규칙들은 적절하게 설정해야 할 것이다.
마치며
코드 분석 기능을 리뷰하며 필자는 과거 C 언어로 개발하던 시절의 컴파일러 옵션을 떠올렸다. 경고 수준을 최고 수준까지 올릴 경우 엄청나게 다양한 경고를 뿜어내는 것을 보고 놀랐던 적이 있는데, 그 후 No Error, No Warning을 목표로 열심히 코드를 수정했었다.
물론 비주얼 스튜디오의 코드 분석 기능은 국제화, 코드 보안 등 훨씬 다양한 영역의 경고를 제시한다. 이러한 코드 분석 기능을 활용하는 것은 전체 프로젝트의 코드 품질을 향상시키는 데에 큰 도움이 될 것이다.
또한 개발자마다 개인적 역량과 경험이 다르며 작성하는 코드의 품질도 차이가 나지만, 최소한의 품질 수준은 유지할 수 있게 하는 데에도 도움이 될 것이다. 가이드라인을 적용 한다는 것에는 그러한 목적도 분명히 포함 되어 있다.
한가지 아쉬운 점이라면, 현재 버전(Release Candidate)의 코드 분석 기능에는 고유의 분석 규칙을 작성하는 것이 아직은 불가능하다는 것이다. 코드의 보안성이나 안정성 등에 대한 규칙은 MS의 가이드라인을 그대로 적용한다 하더라도(MS가 닷넷 프레임워크에 대해서는 가장 잘 알고 있다고 인정하자) 명명 규칙등은 기업의 내부 방침등이 얼마든지 반영 될 수 있다. 규모가 큰 개발 조직의 경우 내부적으로 명명법에 관한 확고한 방침을 가지고 있는 경우도 있다. 하지만 최종 버전에서는 고유한 규칙을 반영 할 수 있다고 하니 최종 버전을 기다려 보도록 하자(참고 : Power Guide For Guru FAQ).
그리고 이러한 도구가 추가되고 있다는 것을 개발자가 해야 할 일이 점점 복잡해 지고 있다는 증거로 볼 수도 있다. 즉 현재의 개발자는 과거보다 훨씬 다양한 부분에 대해 고민해야 하며, 자신의 역량을 향상시키는 데에 지속적인 노력을 기울여야 한다는 의미이다. 그러므로 끊임 없이 정진하도록 하자. 당신을 도와 줄 훌륭한 도구들은이미 준비되어 있으니..
필자 이병철님은 IT 분야의 개발자로 개발 툴에 대한 남다른 관심이 높다. 실제 프로젝트에 임해서도 툴에 대한 분석력이 높다는 평가를 받고 있다. |
 |
|
|
 |
 |
|
|
|
