2015. 3. 24. 11:42ㆍIT/IT 이야기
By Jason Cohen
Founder and CEO
Smart Bear Inc.
E-mail: jason.cohen@smartbearsoftware.com
코드 리뷰 체크리스트는 보통 고통스럽다. 이것들은 그 길이나 내용이 터무니없는 경우가 많다. 게다가 체크리스트를 사용하는 일은 재미가 없다. 분명 우리는 우리들의 코드에서 결함들을 찾아내기를 원하지만 상사가 어떤 웹사이트에서 다운로드 받은 “C언어용 체크리스트”보다는 더 나은 방법이 있어야 한다. 체크리스트들은 개발 과정에서 결함을 일찍 찾아내는데 뛰어난 방법이지만, 대부분의 체크리스트들은 너무 비실용적이어서 도움이 되기 보다는 장애물에 가깝다.
그러면 무슨 일이 실지로 일어나는 것일까? 사람들은 이 리스트를 일반적인 지침으로 이용한다. 이들은 모든 파일에서 모든 항목들을 고려하지는 않는다. 이들은 코드를 살피면서 어떤 항목들을 기억할까? 그 항목들은 가장 중요한 항목들일까?
마법의 수
1956년에 George Miller 씨는 현재 유명해진 “마법의 수는 7 ± 2”라는 논문을 내놓았다. 그는 정보에 대한 사람의 단기 기억 용량을 측정했다. 예를 한 가지 들자면, 대부분의 사람들은 일곱 자리 수의 전화번호는 기억하면서도 10자리 수의 장거리 전화번호를 다이얼 할 때는 번호를 적어도 두 번은 다시 쳐다본다.
Miller 씨의 결과는 심리학의 다양한 측면에 적용되었으며, 심지어 컴퓨터 사이언스에도 적용되었다. 예를 들어, Miller 씨의 작업은 한 기능의 순환적 복잡도(cyclomatic complexity)를 9로 제한하는 이유로 자주 인용되었다.
검토자가 파일을 리뷰할 때 전체 체크리스트에 대해서 생각해볼 것을 기대한다면 우리는 체크리스트를 짧게 만들어야 한다. 다섯 항목 정도면 좋다. 10개가 될 수도 있을 것이다. 따라서 첫 번째 규칙은 “10개 이상의 항목을 나열하지 말라”이다.
소수의 체크리스트 항목들을 가지고 우리는 어떻게 동일한 수의 에러들을 잡아낼 수 있을까? 내 경험으로는, 긴 체크리스트들은 대부분 간단한 프로그래밍 규칙들 또는 코딩 스타일 확인 사항들을 포함하고 있다.
스타일과 기본적 프로그래밍 에러들을 확인해주는 10여 가지의 툴들이 무료툴 혹은 상용툴로 나오고 있는데, 이 툴들은 두 개의 가장 인기있는 소프트웨어 언어인 C와 자바로 되어있다. 개발자들은 코드 정확성과 유지 능력의 확인, 문서화 등 사람이 할 수 있는 일만 하면 된다.
두 번째 규칙은 “자동화될 수 있는 항목을 나열하지 말라”이다.
체크리스트 항목들은 귀중하다. 이들을 낭비하지 말라. 각각의 항목마다 검토자가 정말로 이것을 생각할 필요가 있을까를 물어보아야 한다. 세 번째 규칙은 “명백한 항목들을 나열하지 말라”이다.
작성한 사람이 쉽게 잊어버리게 되는 것들은 검토자도 잊어버리기 쉽다. 이 때는 체크리스트가 올바른 수단이 된다. 그러므로 네 번째 규칙은 “보통 잊게 되는 항목들을 나열하라”이다.
리스트의 구축
내가 체크리스트에 관하여 제일 많이 듣는 질문은 “우리가 사용할 수 있는 샘플 체크리스트가 있는가?”이다. 정치가라면 이는 잘못된 질문이라고 말할 것이다. 제대로 된 질문이라면 다음과 같아야 할 것이다. “우리 소프트웨어 개발 그룹에 어떻게 적절한 체크리스트를 만들 수 있는가? 시간이 지남에 따라 이 리스트를 어떻게 수정해야 하는가?”
여기, 이상한 실험이 있다. 한 주 동안은 실수를 할 때마다 아무리 사소한 실수라도 그것을 기록하라. 모든 것을 말이다. 이메일을 쓰는 동안 단어 철자를 틀렸다면? 그것도 기록하라. 윈도우 하나만 닫으려고 했는데 어플리케이션이 종결됐다면? 그것도 기록하라. gcc를 실행시킬 때 질질끄는 컴파일러 에러가 있었다면? 그것도 기록하라. 이러한 기록을 한 주 내내 계속하는 것이다.
이것은 우리를 화나게 한다. 한 주 내내 이런 고통스러운 일을 한 사람이 있을 지 모르겠다. 당신은 많은 실수들을 했을 것이고 이것들을 기록하는 것은 넌더리 나는 작업이었을 것이다. 그러나 당신은 뭔가 흥미로운 것을 발견할 것이다. 그것은 당신이 같은 종류의 실수를 계속 되풀이하고 있다는 것이다.
물론, 다음 과정은 문제를 고치는 것이다. 많은 이들은 문제를 의식하게 됨으로 해서 이를 스스로 고칠 것이다. 다른 에러들은 자동화로 고칠 수 있다.
소프트웨어 체크리스트들은 정확하게 동일한 방식으로 만들어져야 한다. 마지막 것을 보라, 아니면 코드 리뷰에서 발견된 200개의 결함들을 보라. 그러면 패턴을 찾아낼 수 있을 것이다.
출처 : http://www.eetkorea.com/ART_8800543503_839585_NT_b28b8e10.HTM
'IT > IT 이야기' 카테고리의 다른 글
| 이미지 무료업로드 주소 (0) | 2015.04.13 | 
|---|---|
| 구글 이스터 에그 (0) | 2015.03.24 | 
| sk 컬러링 변경 스마트폰 (0) | 2015.03.24 | 
| Sir 냑에서 퍼옴... 디자이너, 개발자, 기획자, 퍼블리셔를 위한 북마크 (0) | 2015.03.24 | 
| PG신청시 하단 필수 회사정보들.. (0) | 2015.03.24 |