<< [번역] Java에서 String 클래스가 왜 final 혹은 Immutable인가? | Home | 스타트업에 필요한 코드 품질 관리 >>

코드 리뷰의 기본 원칙들

1. 리뷰도 프로젝트의 공식일정과 자원에 포함시킨다.
2. 목표는 사람(사람에 대한 선입견 포함)이 아니라 산출물(프로그램 등)을 검토한다.
3. 문제를 명확하게 할 순 있어도 모두 해결하려고 하지 않는다.
4. 성능과 이해도에 영향을 주지 않는 한 그 사람의 스타일을 문제제기하지 않는다.
5. 리뷰는 2시간을 넘지 않는다.
6. 초기에는 비공식 리뷰나 교육을 자주하고 일정 시간이 지나면 공식 리뷰로 전환한다.
7. 필요하면 체크리스트를 만들어서 리뷰에 임한다.
8. 토론을 장려하고 반론은 대다수가 동의하면 진행하자.


Avatar: ruri

Re: 코드 리뷰의 기본 원칙들

<span style="font-family: "Trebuchet MS", "Lucida Grande", Tahoma, Verdana, Arial, sans-serif;">4. 성능과 이해도에 영향을 주지 않는 한 그 사람의 스타일을 문제제기하지 않는다.</span><br style="font-family: "Trebuchet MS", "Lucida Grande", Tahoma, Verdana, Arial, sans-serif;" /> <span style="font-family: "Trebuchet MS", "Lucida Grande", Tahoma, Verdana, Arial, sans-serif;">5. 리뷰는 2시간을 넘지 않는다.</span>

우연히 들렀다 코멘트 남겨봅니다.

제가 다니는 회사도 모든 소스코드에 대해서 리뷰를 진행하는데요

어떻게 해도 이 두가지가 죽어도 안되네요^^;

4번같은 경우는 사용하는 언어의 문제일 수도 있다고 생각하는데(ruby on rails)

각자 좋다고 생각하는 스타일이 다르고 그렇다고 코딩규약을 정해놓고 일하는 것도 아니라서 참 리뷰받으면서 난감할 때가 있습니다. 

당신의 소스코드로도 동작하는데 문제는 없지만 @#$^$@%@$#%한 이유(리스트일지도 모름)가 있으니 요렇게 하는게 좋지 않을까요?

이런 리뷰를 받으면 이거 뭐 고치라는건지 말라는건지 혼란스럽고 그렇네요.

5번같은 경우는 단건의 Pull Request에 어디까지의 커밋을 담을까에 달린 것 같기도 한데 간혹보면 파일수정이 50여개있고 이걸 리뷰해달라고 대뜸 요청받으면 2시간은무슨 하루종일 리뷰를 하기도 하구요 ㅋㅋ;

 

 

 

 

 

 

 

 

 

 


Add a comment Send a TrackBack