코드리뷰? 코드커뮤니케이션이 맞다.

(사진 @Pixabay)

코드리뷰. Code Review.

코드리뷰, 혼자일 땐 딱히 할 일이 없지만, 둘만 되어도 코드를 오픈해둘 필요가 있다.

그런데, 코드리뷰를 이렇게 이해하면 좀 난감하다.

코드 검토 = 코드 후기 = 코드 평가 = 코드 감시

그건 이런 뜻이다.

(1) 함께 일하는 개발자의 코드품질을 믿을 수 없다.

(2) 우리팀은 코드가 더럽게 관리된다.

뭐, 경력사원이 새로 들어왔다면 검증 차원에서 한 번쯤 해볼 수도 있겠다.

신입사원이라면 케어차원에서 해볼 수도 있겠다.

하지만, 365일 보는 팀인데 저런 식이라면 팀이 깨진다.

협업관계를 불신으로 시작하라는 뜻이니까.

함께 고생하는 팀이라면 이렇게 하면 안된다.

위에서 시킨다고 하면 대충하다가 만다.

혹시라도 싸움이 나면 협업은 개뿔, 그날로 개발 생산성은 물건너가는거다.

이렇게 안하면 좋겠는데, 많은 기업들이 그렇게 한다.

안타깝다.

코드커뮤니케이션

그런데 코드리뷰를 이렇게 이해하면 쉽다.

에러체크 = 공동작업 = 진행참조 = 분업 = 코드커뮤니케이션

이건 이런 뜻이다.

(1) 한 번 장애가 나면 수습하기 힘든 시스템이다.

(2) 운영팀이 따로 없어서 개발팀이 조심해야 한다.

(3) 별도 문서작업 없이 서로 코드를 보면서 맞추어서 개발한다. 

(4) 대형시스템을 모듈별로 나누어서 개발하는 경우 개발관리자가 코드검토 후 통합한다.

(5) 다른 사람이 2.0을 만드는 경우 서로의 코드를 참조해서 투트랙으로 개발한다.

즉, 코드리뷰는 두가지 관점에서 활용할 수 있다.

(1) 개발이후 : 최종반영 이전 위험방지의 "검토 도구"로 사용하는 것.

(2) 개발중 : 불필요한 커뮤니케이션을 줄이기 위한 "소통기술"로서 사용하는 것.

(1) 번 케이스는 "페이스북"이나 "구글"이 한다.

개발소스 배포전에 운영팀이 함께 검토한다.

위험하거나 더 나은 안이 있다면 개발자에게 제안한다.

토의 끝에 그대로 진행하기도 하고, 고치기도 한다.

(2) 번 케이스는 베테랑들끼리 프로젝트 할 때 자주 본다.

베테랑들은 굳이 코드리뷰 회의를 하지 않는다.

필요할 땐 모니터 앞에 서서 코드 이야기 나눌 뿐이다.

시스템 그림도 그린다.

연동모듈을 개발해야 할 땐 다른 사람 코드를 열어 놓고 참조한다.

실리콘밸리에서 흔한 풍경이지만 우리나라에선 보기 힘들다.

하지만, 스타트업에서 종종 본다.

이런걸 "코드 커뮤니케이션" 이라고 한다.

※ Communication Through Code, (Puneet Sapra, 2017.12.3)

먼저 왜 코드를 보는지 명확히 하자.

개발자끼리는 코드보고 말하는 게 편하다.

비잉 둘러서 이야기하지 않아도 된다.

그러려면 몇가지 원칙이 존재한다.

(1) 코드보고 말하자.

(2) 먼저 보고 나서 말하자.

(3) 가능하면 읽기 쉽게 코드를 짜자.

(4) 유지보수하기 쉽게 코드를 짜자.

(5) 가능하면 단순하게 코드를 짜자.

(6) 꼭 100점에 집착하지 말자.

코드보기는 불확실성을 낮춰주고, 

유지보수를 쉽게 만들어주고, 

다른 사람이 이어서 개발하게 해주고, 

자연스럽게 분업할 수 있게 도와주는거다.

감시하려고 보는 거라면 그것도 일이다.

오히려 별도팀을 만들어서 프로세스로 정착시키는 게 낫다.

그런데 소규모 팀이라면 그럴 여유도 없다.

아직 성공경험을 해보지 못했다면, 

친한 개발자랑 한달짜리 토이프로젝트를 해보자.

어떻게 일해야 하는지 알게 될것이다.

물론 서로 쳐다보지도 않고, 협업도 안했다면 그건 함께 일한 게 아니다.

FIN.