Thought on Code Review

기

얼마전 직장인에게 아주 유명한 앱인 B모 앱에서 열심히 시간을 때우고 있었습니다. (대학생에게 에모 앱이 인다면, 직장인 에게는 B모앱!)

사실 저는 여기 직장인 재태크탭을 아주 많이 보는데 오랜만에 IT 엔지니어 탭에 들어갔드랬죠.

아주 힙하고 핫한 글이 있었습니다.

내용인즉,

조직장 쉐리가 코드를 너무 뭐같이 싸내더라.

한번 기회를 엿보다가 차곡차곡 모아서 공개 회의 자리에서 대놓고 이야기 했습니다

'코드를 조금 대국적으로 작성하세요. 이게 무슨 코드입니까'

시원하네요.

내가 이상한가요?

아 물론 각색을 아주 많이 한겁니다. 오해하지 마세요. 진짜 저런글 썼으면 익명이고 뭐고 뚜까맞았을 겁니다. (물론 실제 무수한 댓글 세례가..)

승

이 글을 읽고 물론 저도 약간 좀 기분이 섬칫했습니다.

내가 그리 똥코드를 많이 쌌나.. 정신을 차려보니 저는 어떤 조직을 이끌고 있지 않았습니다!

다행이다. 휴 ㅋㅋㅋㅋ

이 문제는 두 가지의 본질로 나누어서 생각해 볼 필요가 있습니다.

• 코드리뷰를 한 점
• 코드리뷰를 어떠한 컨텍스트에서 진행했냐 하는 점

두가지로 나누어 볼 수 있죠.

전자에 경우에는 무수한 댓글 세례에도 누구도 태클을 걸지 않았죠.

코드리뷰는 어떻게 보면 개발자의 숙명이자 꼭 해야하는 일이라는 것은 누구도 이견이 없었습니다.

문제는 후자죠.

코드리뷰는 (아주 일반적인 회사라면) 코드를 develop branch에 반영해 달라고 요청하면 변경 내역에 대하여 리뷰와 반영을 하는 반복으로 이루어져있습니다.

이를 하는 이유는 코드의 퀄리티를 유지하고, 버그를 먼저 잡아내고, 코드에 컨텍스트가 있는 사람들이 서로 코드를 읽어보고 상호 보완해주는 프로세스라는 것이죠.

리뷰 코멘트에도 물론 사람마다 다르긴 하지만, 많은 경우에 최대한 정중하게, 혹은 문제에만 집중해서 코드 리뷰를 하거나 다른 방법을 제시하면서 이 방법이 더 괜찮을 수 있다 라는 취지로 코멘트를 합니다.

물론 코드를 작성한 사람이 코드 그 자체는 아니지만, 많은 개발자들이 코드 = 자신 이라고 동일시 해서 문제가 생기니 미연에 방지하고자 많은 사람들이 이렇게 합니다.

전

여기에 누가 기름을 부었죠

선비인척들 하지 말라.

돈 받고 코드 짜는 쉐리들이 무슨 말들이 많나.

그딴식으로 정치질 할거면 회사 때려처라.

아… 이건 뭘까요.

네 물론 다들 돈받고 코드 짜는 사람이죠.

저건 읽는 순간, 저 사람이 내 동료가 아니라서 정말 다행이다라는 생각을 먼저 했구요.

저분이 작성한 코드를 먼저 보고 싶었습니다.

물론 리누스 토르발즈 급의 개발자라고 믿어 의심치 않아서요. 궁금합니다. 개인적으로 코드 보여달라고 댓글 달았었는데, 아직도 안보여주시더라구요.. 흑

그렇다면 원래 문제의 상황으로 돌아가서 바람직한 리뷰 방법은 무엇인지 생각해볼까요?

결

사실 바람직한 방법은 사람마다 다르니, 저는 현재 직장인 라인에서 그런 상황이라면 보통 어떻게 하는지 말씀드리는 걸로 마무리 지어보려고 합니다.

1. BTS 티켓을 하나 만든다. (대략적으로 Improve A module performance 같은?)
2. 맘에 들지 않는 코드를 이리 저리 뜯어서 고쳐본다.
3. PR을 올리고 그 코드를 작성한 쉐리를 리뷰어로 지정한다. (난 이렇게 해서 이만큼 성능 올렸는디요? 또는 가독성이 이리 좋아졌는디요?)

자연스럽게 상대방이 더 좋은 코드를 작성할 수 있는 방법을 알 수 있음과 동시에 코드의 품질이 올라갔습니다!

우리 모두 돈 받고 코드 작성하는 개발자임과 동시에 여러사람과 협업을 해야하는 개발자임을 잊지 말아야한다고 생각합니다.

우리는 하나의 프로그램을 같이 만들어가는 개발자이지, 최후의 1인을 뽑는 배틀로얄 참가자가 아니잖아요.