코드 리뷰... 어떻게 하세요?

권순선의 이미지

팀에서 뭔가 함께 개발할 때 코드리뷰는 어떤 방식으로 하시나요?

저희팀은 diff를 메일로 보내고 누군가가 동의한다는 답장을 하면 그때 가서 svn 트렁크에 커밋하는 형태로 진행중인데 다른 분들은 어떻게 하는지 궁금합니다. ^^

onion의 이미지

개발자 코드 전담제의 형식으로..
기능상 별 이상 없으면 크게 뭐라고 하지 않는편입니다.
문제가 있거나 하나의 코드를 협업해야되는 경우가 있다면
두명이 붙어서 코드를 지원해 나가는편이죠.

일반적으로는 고급(?)이 초급(?)에게 guideline을 제시만하고
왔다갔다하면서 수시로 점검하는 편입니다.
(뭐.. 일반적인 개발상황이라 더 그렇겠죠..-.-)

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

neogeo의 이미지

메일로 소스가 왔다갔다해도 안전하다면 괜찮겠지요. ( naver 사내 메일이면 안전하겠네요. )

조엘의 책에 쓰여있는 방식도 나쁘진 않을것같습니다. 아주 이상적인 상황이라면 말이죠.

우선 개인이 test case 를 모두 작성하여 통과시킨뒤에,

코드를 commit 하고

컴파일이 안되거나 버그가 생겼거나 코딩 스타일의 룰을 지키지 않았거나 하게되면, commit 한 사람이 svn 의 무결성을 관리하는식의 술래잡기(?) 방법이 괜찮을듯 합니다.

인간인 이상 실수는 하는거고, 실수를 했을때 제법 귀찮은 코드관리를 떠맡아야한다면 모두 신경써서 하게 되겠지요.

코드 자체의 무결성은 일단 test case 로 '모두 보장이 되는' 그러한 이상적인 상황이 좋다고 생각합니다.

pair 코딩이 아닌이상 다른사람의 코드를 눈으로 검출해보거나 컴파일해보는 것은 일종의 시간을 빼앗는 행동 같아서 망설여지는군요.

test driven 으로 제대로 개발된다면, 이상적으로는 아마 code commit 시에 coding convention 만 주의하면 될 것 같습니다.

Neogeo - Future is Now.

Neogeo - Future is Now.

johan의 이미지

페어 프로그래밍 하면 코드리뷰를 실시간으로 하는 것이 되어서 따로 코드리뷰 안합니다. 다른 개발자가 새 change set 커밋하면 가끔 diff 보기도 하고 문제를 발견하기도 합니다(다른 이들도 비슷한 일 합니다).

제 세번째 직장(현재 다섯인가 여섯번째 직장입니다)에서는 코드 라인에 따라 몇명의 시니어가 참석하고 시간은 얼마를 해야된다는 가이드 라인이 있었습니다(외국 통신회사였습니다). 프리젠테이션 하는 스타일로 아이디어 설명, 함수별 설명등을 하고 나면 각자 질문하고 커멘트 남기고 시니어들이 ok하면 다음 릴리즈에 반영되었었죠. 대개의 경우 20분 전후로 끝나고 한 30분 차마시면서 잡담하고 돌아와서 다시 일했었죠(갑자기 그때 같이 일했던 외국 동료들 얼굴과 이름이 생각나네요. 벌써 8년전 이야기네요!).

참, change set 커밋은 버전컨트롤 정책에 따라 다르겠지만, 저희 경우는 리뷰 없이도 커밋 합니다. 단지 stable branch에 merge하지 않을 뿐이죠. 즉, 변경이 매우 중요하면 모두에게 change set ID를 알려서 한번 리뷰해줄 것을 요구하기도 합니다. 그 후, ok되면 stable 에 merge, 아니면 다시 수정한 후 다시 리뷰 요청, etc. 저희는 mercurial (cvs에서 mercurial로 전환한지 한 7-8개월 되는 것 같네요) 사용하는데, change set은 로컬 혹은 main repo에 백업 개념으로 항상 duplication 만들어 놉니다.

아참, 테스트 케이스 모두 통과해야 stable에 merge 합니다. 테스트 케이스 한 500여개 되나? 요즘 테스트 프레임워크 통합일을 좀 손보고 있는데, 골치아프네요.

개인적으로는 페어 프로그래밍이 명시적 리뷰보다 낫다고 봅니다.

lawch의 이미지

예전에 있던 회사에서는 코드리뷰를 다음과 같이 했답니다.

- 코드 작업이 어느 정도 되었으면

- 일종의 diff 류의 툴로 수정된 부분을 만들어서 리뷰어들에게 몇 일간의 시간을 주고 보낸 후

- 필요하면 간단한 설명을 담은 문서도 함께 보냈던 것으로 기억합니다만
거의 모든 코드 수정에 이에 관련한 요구사항 문서, 설계 문서, 테스트 문서가 함께 공존하기때문에
참고할 문서 번호를 함께 넘겨 주는 정도였습니다.

- 많은 경우 설계 문서에 대강의 코드 수정 계획이 들어가기 때문에 정말 큰 프로젝트가 아니면
설계 문서에서 한번은 걸러진 상태였습니다.

- 리뷰어들은 수정된 코드를 확인 후에 코멘트를 줍니다. 코멘트에는 리뷰하는 데 들어간 시간도 적게 되어 있습니다.
대개 error에 대해서 critical 수준를 정하고 다음 단계로 넘어가는 것을 허가할지 여부를 결정해야합니다.
코드스타일도 리뷰를 하는데 이에 대한 참고자료가 따로 있었습니다.

- 리뷰어 중에 모더레이터(moderator)를 정해서 이 사람이 ok하면 코드리뷰가 끝난 것으로 간주 다음 단계로 넘어갑니다.

- 모더레이터는 코드리뷰에 관련된 데이타 (발견된 error수, 들어간 총 시간, 총 리뷰된 코드수)를 모아서 품질팀에 보냅니다.

- 리뷰할 코드수가 많으면 오프라인에서 모임을 갖아야 하지만 많은 경우 온라인으로 대신합니다.

- 리뷰를 거치지 않으면 commit할 수 없습니다.

wkpark의 이미지

일단 회사라면 각 구성원의 능력이 비슷했을때를 가정하고..
1. 대규모 프로젝트가 아니라 소수라면 그냥 커밋 (대규모 소규모는 정하기 나름)
1. 유닛 테스트 병행
1. 주기적으로 코드 리뷰
1. 커밋되는 량이 일정수준 이상이면 리뷰 주기 단축시키고
1. 문제가 발생하면 테스트 케이스 추가 및 리뷰

원래 버전 콘트롤시스템이 나온것이 개발을 위한 임시저장소의 성격도 가지고 있는것인데, 완벽하지 않으면 커밋하지 않게 해버리면 그 효용성을 절반이상
잃어버리게 되죠. 그런 경우라면 차라리 cvs/svn 말고 git/bazzar 계열의 분산형으로 옮기는게 낫겠고요.

개발 (혹은 초기개발단계) 성향의 프로젝트인지, 이미 성숙하고 안정된 프로젝트에 대한 개발인지에 대해서도 조금씩 다를 것이고 등등등

온갖 참된 삶은 만남이다 --Martin Buber

이충우의 이미지

우리 회사에서는 리뷰 시스템을 사용합니다.

얼마 전까지는 리뷰 룸에 리뷰어들이 모여서 리뷰를 진행하고 합의가 되면 커밋을 했는데,
이게 비용이 많이 들어서 인트라넷으로 리뷰 시스템을 구축했습니다.

diff를 뜨고 리뷰 시스템에 올리고 디스크립션을 달면,
리뷰어들에게 메일이 갑니다.
그러면, 리뷰어들이 리뷰 시스템을 열어보고 (tkdiff 형태로 브라우저에 나옵니다.)
커맨트를 달게 됩니다. 이렇게 모두 확인이 되면 커밋을 합니다.

Real Alternative DBMS, ALTIBASE 5

-------------------------------------------------
Real Alternative DBMS, ALTIBASE 5

MasterQ의 이미지

기본적으로 Perforce를 사용하고 그 위에 자체 플러그인을 이용해서 review를 쉽게 할수 있도록 도와줍니다. 현재 pending중인 changelist들의 파일들의 diff를 묶어서 압축한 후, 공유폴더에 자동으로 복사가 되고, code review때는 그 링크만 보냅니다. reviewer가 그 링크를 클릭하면 자체 플러그인은 하나씩 merge된 파일과 merge전의 file을 양쪽에 보여주고 (windiff 같은 화면) 리뷰를 하게 됩니다. 하지만 code review가 꼭 필요하기 때문에 code review요청 이멜이 너무 많아짐에 따라 분야별로 주 reviewer를 따로 두고 있습니다. 하지만 이렇게 해도 나중에 어떤 리뷰어가 뭐라고 했는지 효과적으로 기록을 남겨놓을수 없기 때문에 현재는 Google의 Mondrian의 영향을 받아 비슷한 시스템을 개발중입니다.

kane의 이미지

안해요. ㅡ_ㅡ;

hey의 이미지

저희도 코드 리뷰를 안 해서 새로운 정보를 드릴 수는 없지만, 지금 하시는 방법과 크게 다르지 않으면서 툴의 도움을 받을 수 있는 괜찮은 솔루션이 있습니다.

설치 방법도 어렵지 않더라구요.

reviewboard입니다.
http://www.review-board.org/
----------------------------
May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


phg98의 이미지

저희는 Code Collaborator라는 상용툴을 사용중인데 이게 가격이 만만치 않아서요..
reviewe-board 홈페이지를 보기는 했는데 아직 설치할 엄두를 못내고 있습니다.
혹시 설치해서 사용중이시라면 주의사항이랄까 그런게 궁금합니다.
일단은 저희 환경에서 잘 동작할지가 궁금하구요. (혹시 Java만 지원되는것은 아닌지.. 등등)
조언을 부탁드립니다.

hey의 이미지

아이쿠. 제가 이 쓰레드에 답글이 안 달리기에 안 보고 있었는데 그 사이..
저도 한 번 깔아보고 제 생각과는 달라서 안 쓰고 있는데 제가 아는 것만 말씀드리죠.

리뷰보드는 파이썬으로 만들어져 있고요, 저는 C++ 프로젝트를 물려봤는데 잘 작동합니다.
기본 프로세스는 커밋 전 리뷰를 기준으로 되어 있습니다.
구성 등이 깔끔하구요.

커밋 후 리뷰 프로세스에서 사용하려면 별도의 기능을 사용해야 하는데 커맨드 라인 명령이라
저희 팀 대부분 프로그래머가 윈도우만 익숙한지라 도입의 어려움을 느끼고 포기했었습니다.

저는 작년에 돌려보았는데, svn 로그와 소스 코드가 함께 출력되는 부분에서 캐릭터셋 문제로 한글이 깨지는 문제가
발생했었습니다.
지금은 괜찮을지 모르겠네요.

첫인상은 굉장히 좋았습니다.
----------------------------
May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


phg98의 이미지

답변 감사드립니다.
저희는 StarTeam이라는 버전툴을 사용중인데 이것도 diff시 한글깨짐때문에 많이 고생을 했었지요...
svn의 diff에서 한글이 깨지는 문제는 최근 버전에서 수정이 된것 같으니 한번 ReviewBoard를 시도해 봐야겠군요.
지금 쓰고 있는 툴은 값이 넘 비싸서, 왠만하면 써봐야겠습니다.
좋은 정보 감사합니다.

phg98의 이미지

용기내서 ReviewBoard를 함 설치해 보려고 했는데, 다운로드부터 일단 막혔습니다...
윈도우 바이너리 파일이 있을거라 예상했는데, 뭔가 알수없는 *.py 파일들 (아마도 파이선 파일?)만 있고...
문서를 봐도 'sudo '로 시작하는 유닉스용 커맨드만 나와있군요. 흑~
혹시 윈도우즈에서 설치하셨다면 방법을 좀 알려주시면 안될까요?

hey의 이미지

아이고... 저는 리눅스에 설치했었고요, 아파치에 물려서 돌렸습니다.
내일 출근하면 한 번 찾아보죠. ;;
----------------------------
May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


burnbrain의 이미지

저도 reviewboard 를 설치해서 테스트 중인데..

view diff 시에 한글이 깨지는 문제가 있어서 삽질중입니다.. ㅠㅠ

혹시 해결하신분 없으신가요??

송효진의 이미지

이제 nFORGE 에 코드리뷰 기능이 들어가려나보군요.:)

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

권순선의 이미지

네 :-)

nimeaz의 이미지

리뷰 시스템이 따로 있습니다.

patch를 만들어 리뷰시스템에 리뷰를 생성하고 업로드한 뒤, 오토 테스트를 돌립니다. 서너시간 걸리는데, 모든 테스트가 성공적으로 끝나면 리뷰어가 리뷰를 합니다. 원본 소스와 패치가 적용된 소스를 비교하기 쉽게 되어 있습니다.

몇 번의 코멘트가 오가고 patch의 잘못된 부분들을 여러 차례 수정하여 완벽하게 되면 리뷰어가 승인을 합니다.

최종 commit 은 소수의 commit 담당자가 하게 되는데 이들이 다시 최종적으로 코드를 리뷰합니다.

마지막 리뷰까지 마치면 코드가 commit 됩니다.

gurugio의 이미지

우리 회사에 코드 리뷰하는 부서가 있을라나 모르겠습니다.
일단 저희 부서는 안합니다만..

kldp.net에 nFORGE 시스템 적용되길 기다리고 있습니다.
제 개인 프로젝트나 어셈러브 모임 프로젝트를 준비하고 있거든요.
화이팅~

----
섬기며 사랑하면 더 행복해집니다.
개인 홈페이지가 생겼습니다 http://caoskernel.org
어셈러브를 개편중입니다 http://www.asmlove.co.kr

권순선의 이미지

지난주 금요일에 nforge 0.7.0이 나왔습니다. mysql 지원되구요... vmware 이미지도 있으니 테스트해 보시고 버그 있으면 좀 올려주세요~ 이 버전에서 좀 안정화가 되면 kldp에 적용하려구 합니다. ^^

http://dev.naver.com/projects/nforge 에서 받으실 수 있습니다.

bluesky.big의 이미지

보통은 한번 리뷰를 진행할때 7~8명 이내의 인원이 1시간을 넘지 않도록 해야한다고 나와있습니다.
이렇게 했을 경우(NASA에서 실험한 결과) 약 90% 이상의 bug를 사전에 찾을 수 있다고 합니다.
이렇게 좋은 것이 실제 현업에서 많이 사용되고 있지 않는 이유는
첫째로 비용이 만만치 않습니다.
둘째로 제대로된 리뷰를 하지 않을 경우 결과가 좋지 않습니다.

일단 코드리뷰를 진행하기로 했다면 두번째 문제가 생길 가능성이 큽니다.
어떻게 코드리뷰의 결과를 좋게 만들것인가를 고민해야합니다. 그렇지 않으면 시간(비용)은 시간대로 허비하게 되고, 단지 우리는 코드리뷰를 했다라는 허울뿐인 명예만 남습니다.
윗분들 중에 코드리뷰 후 테스트를 진행한 후 문제가 없으면 commit을 한다고 하셨는데 이것 또한 생각해 보아야할 문제 입니다.
코드리뷰를 테스팅과 연관을 가지고 갈것인지 아니면 별개로 가지고 갈 것인지도 결정해야 합니다.
테스터가 따로 있는 경우는 별개의 프로세스로 가지고 가는것을 추천합니다만 각 회사의 사정에 맞게 프로세스를 구성해야합니다.
보통 코드리뷰는 개발자가 해야하는 몫이고, 테스트는 테스터가 해야할 몫이기 때문입니다.(단위 테스트는 물로 개발자가 합니다.)
분명히 말씀드리는 부분은 코드리뷰와 테스트가 커버하는 bug의 범위가 다르기 때문에 단지 테스트를 통해서 발견된 버그가 모든 버그라고 생각하면 안됩니다.

요새는 보통 코드리뷰를 툴로 돌리는 경우가 많은데(비용문제상) 이것도 장단점이 있으므로 고민을 해보셔야 할 듯 합니다.

creativeidler의 이미지

코드 리뷰가 좋은 효과를 보기 위한 조건으로 제가 생각하는 것이 몇 가지 있습니다. 코드 리뷰 현장에서는 실력자 중심의 합리적인 토론이 보장되어야 한다는 것입니다. 간혹 경력 많은 사람이나 팀장이 권위를 가지는 경우가 있는데 이런 경우는 잘못된 프랙티스가 대폭 확산되어 안 하느니만 못한 결과가 나올 때가 많습니다.

그리고 코드 리뷰가 그냥 끝나는 게 아니라 clean code that works 차원에서 성과를 내도록 노력해보는 것도 효과가 있습니다. 이를테면, 코드 리뷰가 끝나면 더 깔끔한 코드가 남든지(clean code), 아니면 버그가 수정되든지(that works) 해야 한다는 것입니다. 그냥 "아, 아무 문제 없네" 하고 끝나서는 안된다는 것이죠. 많은 사람이 모여서 시간을 쓰는 일인 만큼 그만큼의 성과를 내야 합니다. 일반적으로 코드 리뷰를 할 때 리팩토링해야 할 코드가 전혀 없는 경우는 절대로 없을 겁니다. 무언가는 성과를 뽑아내고 가급적이면 그 성과가 얼마만큼인지 측정까지 시도해보는 것도 좋습니다.

평소에 개발할 때도 리뷰용 태그를 코드에 남겨두면 도움이 됩니다. 이를테면 남의 코드를 보다가 이해가 안되는 부분이 있으면 // REVIEW 설명해주세요. // REVIEW 이 코드 잘못된 것 같은데? 등으로 주석을 남겨두는 것이죠. 그러면 나중에 코드 리뷰할 때 그런 부분을 찾아서 하나씩 보기 좋습니다(요즘 웬만한 IDE엔 다 이런 Task tagging 기능이 있죠).

아, 물론 이건 전부 한 자리에 팀원들이 다 모여서 코드 리뷰를 하는 방식을 가정한 것입니다. 메일이나 기타 온라인 시스템을 통한 리뷰는 해본 적이 없어서요.

페어프로그래밍 이야기도 흔히 코드 리뷰에 따라 나오는데, 저도 예전에는 페어를 하면 코드 리뷰는 필요 없지 않을까 했었습니다만 이제 생각이 좀 바뀌었습니다. 페어를 하더라도 모든 팀원과 모든 경험을 나눌 수 있는 것은 아니기 때문에 코드 리뷰가 가치가 있습니다. 또 팀 내에 어떤 프랙티스에서 이견이 있는 팀원이 둘 있다면, 이 둘은 프로젝트 내내 한 명은 정방향으로, 한 명은 역방향으로 주행하게 됩니다. 두 사람이 페어로 만나는 순간만 빼면 계속 역주행과 정주행이 한 프로젝트 안에서 일어나는 셈입니다. 또, 그 두 팀원이 만나면 전쟁이 벌어질 꺼구요. 이런 건 코드 리뷰를 통해서 조율할 수 있습니다.

그리고, 그냥 좀 지엽적인 부분에 대한 딴지인데, SCM의 본래 목적을 생각할 때 뭔가를 거쳐야 커밋이 되는 것은 좋지 않은 듯 합니다. 원활한 cowork을 위해서는 불완전한 코드라도 공유해야 할 필요가 많이 생기거든요. 만약 제약을 꼭 걸고 싶다면 릴리스 브랜치를 따로 유지하면서 트렁크에서 릴리스 브랜치로 머지할 때 제약을 거는 방법이 있고, 또, 브랜치 없이 그냥 릴리스를 할 때 제약을 거는 방법이 있습니다. 어쨋든 모든 개발자는 자신이 원할 때 소스코드를 커밋할 수 있어야 SCM이 본연의 역할을 다할 수 있습니다.

오호라의 이미지

저는 조금 다른 관점에서 의견을 말씀드리자면...

-> 1. 좋은 코드리뷰를 위해서는 좋은 기획과 설계가 밑바탕되어야 한다.
-> 2. 1번 항목에 대해서 팀원 및 코드리뷰에 참석하는 개발자들이 정보를 공유하고 있어야 하고, 어느 정도의 사전지식이 필요하다.
-> 3. 코드리뷰에서 syntax error, memory leak, array boudary, side effect.. 등과 같은 문제를 찾을려고 하면 안된다. 코드리뷰는 unit test 와 integrity test 사이에 하는 것이 바람직하다.
-> 4. 코드리뷰의 양 또는 모듈은 제한적이어야 한다.
-> 5. 기타등등

<- 1. 기획과 설계없이 개발자 혼자 작성한 코드를 리뷰를 하게되면 코드작성자외에는 아무도 관심을 갖지 않을 겁니다.
<- 2. 코드리뷰할 코드에 대한 정보공유와 사전지식이 없다면 회의시간에 그 코드의 오류와 버그를 찾을려고 생트집을 잡던지 그냥 빨리 끝나기만을 바랄 뿐입니다. 혹은 메일내용을 by pass 할지도 모릅니다.
<- 3. 최소한 코드리뷰시간이 syntax error와 debuging 시간이 되지는 말아야 합니다. 유닛테스트는 이제 기본입니다.
<- 4. 빔프로젝트로 생전 처음보는 수천라인의 소스코드는 그리 눈에 잘 들어오지 않습니다. 인간의 뇌 buffer 는 8K 가 안될지 모릅니다.
<- 5. 개발자들의 귀차니즘과 빡빡한 일정은 어떤 좋은 인터페이스, 어떤 좋은 소프트웨어라도 by pass 마스터키가 된다.

Hello World.

poplinux의 이미지

저희 같은 경우는

"커밋했습니다"

라고 한 마디 하고 끝내더군요.

충격적인 건,, 커밋 로그나 소스에 주석 처리가 전혀 안 되어 있다는 것이지요. 게다가 커밋한 사람이 그 소스의 개발자 허락도 없이 수정해서 올린 상황이 대부분이라는 것.

쓰러지지요.

========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux

임베디드 리눅스 관련 프리렌서 지향

phg98의 이미지

저희는 Code Collaborator 라는 툴을 도입해서 4달정도 사용중입니다.

진행하다 보니 나름 우리 팀의 환경에 맞는 프로세스가 구축이 되었는데, 다음과 같습니다.

1. 작성자는 소스코드를 수정후 체크인 하기 바로 직전에 코드 리뷰 등록을 한다.
2. 이때 다른 팀원중 1명을 Reviewer로, 나머지 팀원들은 Observer로 등록한다.
(Observer도 리뷰 내용을 볼 수 있고, 커멘트 할 수 있지만, Reviewer만이 완료처리할수 있다)
3. 작성자는 코드 diff를 올린 다음 중요한 내용들은 스스로 설명하는 커멘트를 추가한다.
4. 작성자는 코드 리뷰 등록을 완료하면 체크인(커밋)한다.
5. 리뷰어는 하루 1시간 정도를 할애하여 리뷰한다.
6. Observer는 반드시 리뷰해야하는 의무는 없다.

이정도 이군요.
코드 리뷰가 완료되어야만 체크인하는 팀들도 있다고 하고, 2명이상 리뷰어를 지정하는 팀들도 있다고 하는데, 우리 팀한테는 좀 헤비하다고 느껴져서 위와 같이 진행하고 있습니다.

좀 더 자세한 내용은 블로그 참조 ( www.codereview.co.kr )

페어 프로그래밍을 시도한적이 있으나 실패했었구요, 페어프로그래밍을 한다면 굳이 코드리뷰를 따로 할 필요는 없을거라 생각됩니다.
리뷰어가 2명을 넘어가면 별로 추가이득이 없다는 생각입니다.
그리고, 유닛테스트/정적분석툴 등과 코드리뷰는 서로 보완적이라고 생각됩니다. 코드리뷰의 가장 큰 미덕은 에러의 검출보다 오히려
지식의 공유(또는 교육)와 이해하기 쉬운 코드 만들기라고 생각됩니다.

magingax의 이미지

리뷰는 커녕..버그리포트도 제대로 안합니다..
결국엔..나혼자 다 하게 돼버리고..나머지분들은..문서작업 합니다.
이런..XX 같은..

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

phonon의 이미지

리뷰 당일에 갑과 을의 담당자들이 많은 경우에 10명정도로 5~6시간 휴식없이 한적도 있습니다.
코딩보다 준비 문서량이 5배이상인 경우가 많으며, 끝나고 나면 버그 수정 내용과 수정날짜까지 정해서 회람을 할 것인지, 다시 리뷰를 할 것인지를 정합니다.
버그나 개선 사항에 따라 클레임도 있기에 상당히 긴장감 속에서 여러번 소스나 주석등을 확인하지만, 어김없이 버그가 둘이상 발견되거나 설계 문서의 오류등이 발견되더군요.(주석이나 들여쓰기가 잘못되어도 버그!)

그런 지적 사항들이 개발자들에게는 좋은 도움이 된다고 생각합니다. 보다 높은 경지에 있는 분들의 경험이나 몰랐던 내용들을 들을 수 있는 세미나라고 생각하면 한결 마음은 가벼워집니다만, 으~ 누군가 저의 소스를 보는 것은 웬지 숨기고 싶은 치부를 들키는 느낌이라.

저의 의견은, 꼭 소스 리뷰를 스케쥴에 넣는 것이 버그 발생의 줄임, 책임 분담, 수정 사항을 줄일 수 있는 확실한 방안이므로 실시를 하는 것이 좋다고 봅니다. 다만, 준비 문서를 줄이고 책임자들이 꼭 참석하길 바랍니다.

pinebud의 이미지

저는 소규모/개인으로 일하고 코딩도 별로 안해서 리뷰도 혼자해야합니다 -_-;
그래서 보통 다음과 같이 일하려고 노력합니다.
1. 그냥 프로그램을 짜고 돌려봅니다.
2. 하루쯤 있다가 리펙토링하면서 코멘트를 달기 시작합니다.

A rose is a rose is a rose..