강력한 Coding Style
주넥
아이디스 허준혁입니다.
어제 오후에 정보통신진흥원(NIPA) 산하 SW공학센터에서 주최하는 conference를 다녀왔습니다.
세션은 2개로 한쪽은 대학 교수님들이 발표를 하는 것이었고, 다른 한쪽은 올해 SW공학센터의 지원을 받아서 SW공학 산업현장 적
용 프로젝트를 수행한 업체들 중 선정된 몇개의 업체에서 사례 발표를 하는 자리 였습니다.
사례 발표 중에 업계 표준적인 강력한 코딩 스타일들이 있음을 알게 되었는데, 공유할까해서 글 올려 봅니다.
강력하다는 것은 "프로그래머의 자유도를 없애서 잠재적인 결함을 없애겠다."는
취지 입니다.
이런 강력한 rule을 적용하게 되면 많이 불편하겠지만,
정착된다면 잠재적인 결함 또한 줄어드는 것은 사실 이겠지요.
이러한 강력한 rule은 SW결함이 치명적인 인명 피해를 일으킬 수 있는
자동차 업계에서 시작하여 전투기 제조 업계에 이르고 있습니다.
C 코딩 스타일로는 자동차 업계에서 만들어진 MISRA가 있습니다.
(MISRA는 Motor Industry Software Reliability Association의 약어)
C++ 코딩 스타일로는 MISRA를 포함하고 발전시킨 전투기 제조 업계에서 만들어진 JSF AV가 있습니다.
(JSF AV는 the Joint Striker Fighter Air Vehicle)
JSF AV C++ 코딩 스타일은 총 220개 가량의 rule이 있는데, should, will, shall 3가지 class
로 분류 되어 있습니다.
should는 지킬 것을 강하게 권고하나, 필수는 아니구요.
will은 필히 지켜야 하나, 검증대상은 아니구요.
shall은 필히 지켜야 하고, 수동이든 자동이든 코드 검증이 반드시 있어야 하구요.
전체적으로 rule을 한번 study 해보고, SW결함 예방에 효과적인 몇몇 rule에 대해서는 IDIS coding style
에 포함시키고 교육하고 지킬 것을 강제시키는 방법을 모색하는 것도 좋을 듯 합니다.
rule어길 시 svn commit을 못 하도록 막든가 하는 방법으로요.
코딩 rule관련 자세한 것은 아래 site에서 word파일로 된 다운 받아 볼 수 있습니다.
http://www.jsf.mil/downloads/down_documentation.htm
Yun Chung Ha
Cheon, Woo-Hyeong
--
===========================
유난히 S/W Architect를 좋아하는 나.
http://www.pozz.net
Min
또 룰을 지나치게 강조하고 그 룰을 지키지 않을경우 비난하는 문화가 발생하면 사람들이 룰을 지키는 것에만 신경을 써 더 생산적인 작업을 할 시간을 뺐을수도 있는것 같습니다.
이동인
힘들게 코딩 스타일을 정의하고 교육했지만 팀원이 충원되고 시간이 지나면서 자연스레 다양한 코딩 스타일로 돌아가더군요.
특히 작업량이 많아지는 시점에서 코딩 스타일을 규제하기란 정말 쉽지 않습니다.
그러던 중에 Resharper와 StyleCop을 이용하여 코드에 대한 강제를 유도하는 툴을 사용한 결과 코딩 스타일을 쉽게 통일할 수 있었습니다.
그리고 Resharper는 유료이지만 무료로 지원되는 오픈소스인 StyleCop만 사용해도 충분한 효과를 누릴수 있을 것 같습니다.
저희 팀은 닷넷 기반에서 사용하기 때문에 위에 툴들을 사용했지만 언어마다 지원되는 오픈 소스가 있을 거라 생각합니다.
From: min...@gmail.com
To: xp...@googlegroups.com
Subject: Re: 강력한 Coding Style
Date: Fri, 11 Dec 2009 00:55:10 +0900
Lee Chang Woo
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
페이지가 나오는 군요.. :-)
제가 처음에 언급된 "MISRA"에 대해서 사내에서 업체를 통한 소개를 받았었다고 이야기를 들은적이 있습니다.
그런데 MISRA라는 것이 꼭 코딩 스타일을 지키는 것에만 있는 것이 아니라.
사람의 목숨이 걸려 잇는 product에서 code의 safety를 보장하기 위해서 제정된 측면도 있다더군요.
제가 이 부분을 공부해 보지는 않았습니다만 MISRA의 requirement중에 어떤 level은 아예 heap을 사용하면 안되는 requirement level도 존재하더군요. :-(.
그래서 MISRA의 일부 requirement를 도입 시도가 너무 강한 requirement등으로 인해서 도입이 저지당한 적이 있습니다. :-)..
현재 제가 다니는 곳에서는 대안으로 아래와 같은 tool을 사용합니다.
http://www.coverity.com/products/coverity-integrity-center.html
-> static code analysis tool
http://www.mathworks.com/products/polyspace/
-> dynamic code analysis tool
동적 tool은 너무 비싸고 분석하는시간이 너무 오래 걸려서 아마 중단했다는 알고 있고.
요즘에 Coverity Prevent라는 tool의 도입을 다시 시도하는 것 같습니다.
이러한 류의 코드 체킹이나 Codeing Style강제는 Source control하는 팀이 존재하여 전문적으로 이러한 일만 하는 분들이 존재해야 한다는 느낌을 지울수가 없네요.
L사와 S사에서는 이런 업무를 하는 팀이 존재하다고 들은 것 같네요.
June Kim
항상 문제는 사람들이 이걸 어떻게 "현명하게" "지키게" 할 것인가가 되겠지요:
* 지키게 : 표준을 정하는 것과 사람들이 그걸 지키게 하는 것은 다른 문제이지요. 전자에 비해 후자가 10배, 100배
노력이 더 들어가는 것 같습니다. 사람들의 의식적, 무의식적 저항이 있을 수 있죠.
* 현명하게 : 사람들은 서로 다르게 해석할 수도 있고, 규칙을 역이용할 수도 있습니다. 시늉만 낼 수도 있고요. 수천개의
코딩 표준을 하나도 어기지 않으면서도 가독성 낮고, 테스트 가능성 높고, 복잡성 높은 코드를 작성할 수 있습니다.
다음과 같은 방법을 쓰면 투자 대비 효과가 높지 않을까 싶네요(비슷한 방법을 써봤습니다):
* 팀원들이 각자 독립적으로 코딩 가이드 라인의 목록을 읽으면서 우리가 1) 이건 당연한건데 이걸 못지키면 매우 큰 문제가
생길 수 있다라고 생각되는 것과, 2) 이걸 지키면 정말 나아지겠다, 좋겠다를 체크해서 뽑습니다.
* 1)의 응답에서 사람들간의 차이를 봅니다. 갑은 3번 표준을 1)로 선택했으나 을은 선택 안했다면 이야기해볼 필요가 있는 것이죠.
* 위의 토론을 통해 선정된 것들에 대해 1), 2)에서 사람들이 많이 뽑은 걸(득표수가 많은 표준) 추려서 같이 논의해 봅니다.
* 이때 특히 1)에서 팀원들이 말 안해도 잘 지키고 있는 것은 논의해서 뺍니다.
* 나머지 목록을 추려낸 다음 우선순위를 매겨서 이번에 적용가능할만하고, ROI가 클 것(이번 기간에 특히 포커스를 둘
것)을 소수 선택합니다.
* 정해둔 기간 중 코드리뷰 시에 우리가 선택한 리스트를 중점적으로 체크합니다. (자동화하는 비용이 크지 않다면 자동화도 괜찮습니다)
* 일정 기간이 지나고 익숙해졌다 싶으면 다시 처음부터 이 프로세스를 다시 시작합니다.
2009/12/10 주넥 <jun...@gmail.com>:
Kay Kim(김기웅)
Yun Chung Ha
--~--~---------~--~----~------------~-------~--~----~
한국 XP 사용자 모임(http://xper.org) 메일링 리스트에 가입하셨기에 이 메시지를 보내드립니다. Google 그룹스 "xper" 그룹
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
xp...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
xper+uns...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/xper?hl=ko?hl=ko의 그
룹을 방문하십시오.
-~----------~----~----~----~------~----~------~--~---
Lee Hyun Chang
저도 코딩스타일을 통일하는데 실패한 경험이 있는데요,
착한 개발자들이 그렇게 흥분하면서 자기스타일을 옹호하는 걸 보고
조금 놀란 면도 있었습니다.
(저는 나쁜 개발자라서 역시 흥분을 -_-;; )
이 코딩스타일은 "이러이러해서" 좋다. 라고 말을 할때
그 "이러이러해서"라는 이유가 누가 보더라도 객관적인 경우가 의외로 많지 않은 것 같습니다.
위에서 말씀하신대로 팀원은 몇 년에 걸쳐서라도 계속 바뀌게 되고
사람마다 경험과 취향이 틀려서 "가치판단"의 문제가 되어버리기도 하구요.
같이 일하시는 일본 개발자분은 함수나 클래스의 이름을 짓는 센스도
한국사람들이랑은 또 많이 틀린 것 같구요.
어쨌든, 좋은 자료 감사합니다~
Cheon, Woo-Hyeong
--
한국 XP 사용자 모임(http://xper.org) 메일링 리스트에 가입하셨기에 이 메시지를 보내드립니다. Google 그룹스 "xper" 그룹
이 그룹에 게시하려면 다음 주소로 이메일을 보내주십시오.
xp...@googlegroups.com
이 그룹에서 탈퇴하시려면 다음으로 이메일을 보내주십시오.
xper+uns...@googlegroups.com
추가 옵션을 보려면 http://groups.google.com/group/xper?hl=ko?hl=ko의 그
룹을 방문하십시오.
강석천
도 있습니다. (ex : 변수 초기화, 메모리 사용 전 NULL에 대한 체크, ASSERTION 을 통한 방어적인 코드)
단점으로는.. 엄청나게 많은 ASSERT구문이 추가된다는 점도 있긴 합니다.;;
강석천
'스타일' 이라고 사람들이 인식하면 '이것도 돼' '저것도 돼' 가 됩니다. 하지만 '버그' 라고 인식되면 '올바른 것은?' 이
란 질문과 몇몇 제한된 답 & 규칙들이 있습니다.