블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (41)
Agile Experience (22)
My Family (0)
Life Style (7)
Programming (8)
Android (2)
Total
Today
Yesterday

달력

« » 2024.3
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

최근에 올라온 글

최근에 달린 댓글

'코드리뷰'에 해당되는 글 2건

  1. 2010.07.05 코드리뷰는 진짜로 해야 효과가 있다. 4
  2. 2010.02.26 이메일로 코드 리뷰 하기 12
새로운 개발팀

이전 개발팀에서 이메일을 이용한 코드리뷰를 시행한 적이 있습니다. (2010/02/26 - [Programming] - 이메일로 코드 리뷰 하기)
혹시나 해서 요즘에도 잘 되고 있나 여쭤보았지만 아직은 형식적인 단계라는 답변을 들었습니다.
이직을 하고 나서 저는 변화된 환경에 적응하기 위해 애자일 프랙티스를 언급하거나 제안하지 않았습니다. 
단지, 이전 업무에 대한 소개를 할 때 개발 프로세스 개선 활동에 대해 짧게 소개만 했습니다. 
(다행히도 입사 4개월 만에 애자일에 관심을 보이시는 관리자 분이 계십니다!^^~~ 이번에 애자일 세미나를 같이 들으러 감~)

프로세스에 녹아든 코드리뷰

경력으로 입사하였기에 빠르게 프로젝트에 투입되었습니다. 현재 개발팀의 소스코드는 svn으로 관리됩니다. (git로 넘어가는 추세..)
그런데 특이했던 점이, 자신의 home directory에 check-out된 소스에서 직접 작업하지 않고 export된 다른 복사본(working source)에서 작업을 하는 것이었습니다. 즉, commit과 update 절차는 다음과 같이 진행되었습니다.
  • commit 절차 : 복사본에서 작업 => svn 소스와 diff를 통한 merge => svn commit
  • update 절차 : svn update => 복사본 소스와 diff를 통한 merge => 복사본에서 검증
즉, 개인 작업물에 대해서 철저하게 분리하는 형태 입니다. 어찌보면 번거로워 보일수 있는 소스관리 프로세스 였습니다.
그런데, 작업이 진행되면 될수록 소스코드가 잘 정리되었으며, 믿음직하고 든든해 졌습니다. 
그것은 merge 과정에서 자신의 코드와 타인의 코드에 대해서 source code inspection이 암시적으로 행해졌기 때문입니다.
복사본에서 작업하기 때문에 개인용 테스트 로그가 svn 소스 트리에 등록되지 않은 것도 한 몫 했습니다.

프로세스(혹은 도구) 개선이 정답?

김창준님이 한국 developerWorks의 dW Column에 기고하신 "소프트웨어 관리자의 개선 우선순위"라는 글을 보면 다음과 같은 재미있는 연구 결과를볼 수 있습니다.

쉽게 말해, 도구 부분에서 상당한 개선을 이뤄내면 비용적으로 세 배 정도 개선을 얻을 수 있다. 이에 비해 관리 부분에서 상당한 개선을 이뤄내면 비용적으로 64배 정도의 개선을 얻을 수 있다는 뜻이다.

관리자들이 선호하는 개선 노력은 어떤 순서일까? 정확히 역순이다. 일단 도구 개선부터 시작한다. 자기 자신(관리)을 바꾸는 것은 맨 나중이다. 그러나 실제 효과로 보면 우선순위는 관리가 맨 처음에 온다


제 경험을 보면 마치 프로세스(혹은 도구) 덕분에 큰 효과를 본것 처럼 보입니다. 하지만 근본적인 원인은 따로 있었습니다.

내 코드가 아닌 우리 팀의 코드

개발과정에서 개발팀의 관리자 분(개발에도 참여하심)과 개발 리더분은 지속적으로 소스코드를 리뷰하고 있었습니다.
라인단위로 의미없거나 논리적이지 못한 코드가 있다면 명확하게 해명을 해야 svn 소스 트리에 남을수 있었습니다.
로직이 불분명하다면 버그가 생길만한 케이스를 분석하거나 테스트 케이스를 만들어서 알려주십니다.
우리에게 누가 문제를 해결했고 누구의 소스에서 버그가 있었다는 것은 중요하지 않았습니다.
중요한건 우리 팀의 코드가 품질이 높아야 한다는 것이지요. (물론 납기일을 만족하면서...)
코드리뷰는 진짜로 해야 효과가 있는 것 같습니다.
Posted by 윤청하
, |
저희 회사에서 제품의 품질을 높이기 위해 지난 1년간 코드리뷰를 전사적으로 진행했습니다.
하지만 리포트 형식만 던져주고 어떠한 교육이나 코칭이 없는 상태에서 진행되다 보니 업무에 부담만 되었습니다.
소스코드 출력해서 수정된 부분 체크하고 이전 버전도 체크하고..등등..ㅠㅠ

몇달전에 박형근님 블로그(코드리뷰, 좀 쉬운 방법은 없을까?)에서 공짜로 책을 준다는 글을 읽고 바로 신청했습니다.
지금도 공짜로 보내주고 있네요^^

책을 읽어보니 이메일로 코드리뷰를 하는 방법이 소개되어 있었습니다. 그래서 가장 간단한 형태로 적용해보기로 했습니다
그 형태는 체크아웃된 소스코드를 작업하고 체크인할 때 수정내용을 입력하도록 하고 이전 버전과의 차이점을 이쁘게!!! 팀원 전체에게 이메일로 보내는 것이었습니다. 이렇게 하면
  1. 팀원들이 쉽게 볼수 있기 때문에 코드 정리에 더 신경쓰게 된다.
  2. 어떤 내용을 수정했는지 히스토리가 명확하게 남을 수 있다. (모두가 보고 있음..ㅋㅋ)
살짝 이 정도의 장점이 생기는것 같습니다.
물론 반발을 최소화 하기 위해 저 방법을 안써도 체크인 할 수 있도록 했습니다. 
하지만 요즘은 팀장님이 리뷰할 수 있게 체크인 해달라고 요구하십니다.ㅋㅋ 팀장님은 상시 리뷰어로써의 역활을 하고 계시죠..
굉장히 단순한 형태이긴 하지만 그 효과는 괜찮은것 같습니다.

저희 코드리뷰 이메일은 다음과 같이 vim에서 보는 것과 동일한 형태로 보내집니다.
  • vim에서 C syntax highlight에 diff highlight를 추가하였습니다.
  • vim에서 :runtime! syntax/2html.vim 을 실행하면 highlight 된 형태를 html 포멧으로 저장해줍니다.
Posted by 윤청하
, |