[아이티데일리] 안녕하세요, 파수 정적분석팀입니다. 이번 포스팅은 정적분석에 관한 두 번째 글입니다.
이번 포스팅은 정적분석 툴인 C++ Test, JTest 등의 개발사인 ‘Parasoft’의 블로그 글을 간략하게 번역한 글입니다.
소스코드 정적분석 최적화 팁 : 규칙(Rule Set) 잘 다듬기
(Static Analysis Optimization Tip: Scrub Your Rule Set)
여러분의 개발팀이 어디서부터 어떻게 ‘진짜 문제’를 붙잡고 씨름해야 할 지 모를 만큼 많은 정적분석 규칙 위반의 숫자에 압도된 적이 있나요?
여러분의 정적 분석 최적화의 첫걸음은 너무 많은 것이 어수선하게 채워져 있는 규칙을 깔끔하게 정리하는 것입니다. 너무 많은 규칙들은 진짜 관심을 가져야할 이슈에 집중하기 어렵게 만들지요. 두 번째는 여러분의 시야를 넓혀서 조직에 가치를 증대시키는 길로 여러분의 진취성을 발휘하는 것입니다.
여러분의 정적 분석 구현을 다시 한 번 환기시키는 길을 찾아보고자 합니다. 정적분석 규칙을 다듬는 2가지 방법을 보시죠.
당장 강행하지 않을 정적분석 규칙은 비활성화 시켜라.
(Disable static analysis rules you're not committed to enforcing right now)
많은 규칙을 체크하는 것은 정적분석으로 얻을 수 있는 최고의 ROI를 달성하는 열쇠가 아닙니다. 사실, 많은 사례에서는 그 반대의 경우가 정답입니다. 정적분석은 실제로 여러분이 적지만 의미 있는 규칙에 포커스를 맞출 때 더 좋은 결과를 얻을 수 있습니다.
여러분이 정적분석을 수행하는 것은 경험이 적은 개발자 어깨 너머에 경험 있는 개발자가 서있고 경험이 적은 개발자에게 코딩할 때 팁을 알려주는 것과 같습니다.
만약 경험 있는 개발자가 소스코드 한 줄 한 줄마다 하찮은 이슈로 끊임없이 잔소리 타령을 한다고 가정합시다. 새내기 개발자는 곧 그에게 압도되고, 좋은 조언이건 나쁜 조언이건 간에 모든 조언을 무시하기 시작할 것입니다.
그러나 경험 있는 개발자가 심각한 문제를 일으킬 수 있는 한 두 개의 이슈에 초점을 맞춘다면, 새내기 개발자는 그가 준 조언을 더 기억하고 더 좋은 코드를 작성하기 시작할 것이며, 실제로 이런 종류의 피드백에 감사하게 될 것입니다.
이는 정적분석에서도 동일합니다. 만약 여러분이 정적분석 규칙을 관리 가능하고 의미 있게 유지한다면, 개발자에게 많은 것을 가르칠 수 있고, 개발자들이 프로세스에 대해서 덜 분노하게 만들 수 있습니다. 모두가 따르는 적은 수의 규칙이 좋을까요? 아니면 모두가 따르지 않는 모든 규칙을 유지하는 것이 좋을까요?
여러분이 개발자에게 규칙 위반이 보고되자마자 문제를 해결할 것 같지 않으면, 심각하게 해당 규칙을 비활성화 시키는 것을 고려해보십시오.
너무 많은 위반을 야기시키는 규칙을 비활성화 시켜라.
(Disable static analysis rules causing too many violations)
어떤 특정 정적분석 규칙이 되풀이 되서 위반된다면, 지금이 여러분이 이 규칙을 계속해서 체크할 것인지 말지를 재평가해야할 좋은 기회입니다. 과도하게 많은 수의 규칙 위반은 개발자가 규칙이 요구는 방식으로 코딩하고 있지 않음을 알려주는 것입니다. 개발자들의 코딩 습관을 개선시키고자 설득하는 것은 개발자들의 만만찮은 저항에 직면할 수 있습니다.
여러분들은 이 이슈를 계속 밀고 나가는 것이 과연 가치가 있는지 없는지 어떻게 결정하시나요? 첫 번째, 왜 여러분이 우선 이 문제를 체크하기 시작했는지에 대해서 기억해보십시오. 당신이 실전에서 경험했던 이슈를 검출하는데 좋은 방법이기 때문에 선택했나요? 각종 인증 준수를 위한 노력의 일부?(역자 주 : FDA, MISRA-C 혹은 DO-178B/C와 같은 소프트웨어 규격 준수를 위한 노력을 말한다.)
아니면 그냥 벤더에서 제공해준 기본값이기 때문에? 벤더들은 전형적으로 각각의 규칙에 대해서 설명을 함께 제공합니다. 이 규칙이 진정으로 여러분의 프로젝트의 목표에 합당한지 결정하는데 도움이 되려면 규칙에 대한 설명을 읽는 것이 도움이 됩니다.
다음으로, 원하는 결과를 달성하기 위해 다른 방법이 있는지 봅니다. 만약 보다 구체적인 대체가능한 규칙이 있나요? 이슈가 너무 자주 발생하지 않게 규칙 파라미터를 수정할 수 있는 방법이 있나요?
만약 당신이 이 규칙이 주는 이득과 다른 방법을 재검토후에도 이 규칙을 적용하고 싶다면, 이 규칙을 따를 때 어떤 일이 필연적으로 수반될지 개발팀으로부터 피드백을 얻으세요. 이 피드백을 사용하여 개발자들에게 이 규칙을 따를 것을 요구할만한지 결정할 수 있습니다. 만약 이 규칙을 적용해서 얻는 이득인 적고 할 일만 많아진다면, 과감하게 이 규칙을 비활성화하세요.
해당 글은 파수닷컴에서 아이티데일리 블로그 게재용으로 제공한 콘텐츠입니다.
저작권은 파수닷컴 측에 있으며, 무단전제 및 복제를 금합니다.
원문출처 : http://blog.fasoo.com/80197344567