https://okky.kr/article/1135478

회사에서 지원해줘서 백명석님의 강연을 회사 돈으로 들었습니다.
좋은 내용이라 들으면서 인상깊었던 내용을 캡쳐하면서 팀원들에게 공유했던 내용을 올립니다.

코드리뷰를 해야 하는 이유

하... 너무 공감합니다 ㅠㅠ
'새 프로젝트를 처음 시작할 때' 는 못느끼는데, 하루가 지나고 이틀이 지나고 점점 시간이 갈 수록 새로 만든 프로젝트임에도 어제 작성한 코드와의 화합과 그에 의한 유지보수가 필요해져요.

빨리 만든다 != 프로젝트의 진행 속도가 빠르다

코드리뷰를 통해 품질을 높이면

지금 시간을 조금 더 써서 코드리뷰를 하고 품질을 올리면 그 시간을 프로젝트가 진행됨에 따라 조금씩 보상받습니다.
다만 느낄 수 없죠. 어떤 사람은 시간낭비 한다고 느끼는 사람도 있을거에요.

코드리뷰는 시간이 아깝다 생각하며

지금 빠르게 만드는데에만 신경쓰고 코드 품질에 신경쓰지 않으면 프로젝트가 진행됨에 따라 알게 모르게 쌓여서 이자까지 돌려받습니다.
격하게 실감하게 됩니다. 대체 뭐하는거냐며 질책을 당하고 정치질에 휘말리기 하기 시작할겁니다.

과연 뭐가 시간낭비일까요?

코드리뷰를 하며 품질을 높이는데 쏟는 시간이 낭비일까요?
빨리빨리 만들었는데 며칠 지나니 문제 투성이가 되서 매일매일 고치는데 거의 모든 시간을 쓰는데도 계속 문제가 생기는 상황이 시간낭비일까요?

좀 더 극단적으로 말하자면, 새로 시작하는 프로젝트인데 어제 작성한 코드가 새로운 코드와 충돌해 문제를 일으켜 수정하느라 많은 시간을 보내는 경우도 있을겁니다. 매일매일요.

소프트웨어 장인

그러면서 '소프트웨어 장인' 책에 대한 소개가 나왔습니다.
저는 재밌게 읽었는데 추천할 수 있냐고 물으면

"서문은 굉장히 재밌어요."
팀장놈이 내 코드를 다 지워버렸다

라고 대답합니다.
서문에서 하고싶은 말을 함축적으로 다 전달합니다.
그 외에는 사람에 따라 지루할수도 있어요. (그런 피드백을 받은적이 있어서)

하지만 저는 굉장히 좋아하는 책입니다.

코드리뷰란?

저는 회사의 깃허브 가이드에 코드리뷰에 관한것도 썼는데 아래 내용입니다.

백명석님의 의견과 저의 생각이 일치하는 부분이라 인상깊어서 언급했습니다.

"시니어가 주니어한테 주는건 되는데, 주니어끼리나 주니어가 시니어한테 뭘 줄 수 있냐? 하는데... 서로 주고받는거에요."
"자기 팀이 아니어도, 다른 팀 코드리뷰도 볼 수 있는거에요. 그러면서 자극을 받고..."

코드리뷰를 잘 하려면/받으려면

"저자가 바쁘다고 커밋 메시지 대충 쓰고 코멘트 대충 쓰면... 리뷰어가..."

이거 정말 백번 공감하는게, 아직 저희 팀원들은 Pull Request에 익숙하지 않다보니 코멘트를 자세하게 써주질 않습니다. ㅠㅠ
제가 처음 가르쳐줘서 이제 시작하다보니 Pull Request의 양도 잘 조절이 안되서 아직은 제가 좀 고생을 합니다.

(너무 양이 많아서 못보겠으면 LGTM 짤을 쓰는건 안비밀)

이 부분은... '소프트웨어 장인' 서문?
서문: 팀장놈이 내 코드를 다 지웠다

Github를 안쓰던 시절에는...

이 부분이 꽤나 재밌었는데, SVN을 많이 쓰던 시대에는 꼭 금요일 오후에 불러서 비난 대잔치를 열고 퇴근을 못하게 하는 이상한 문화가 여기저기 있었습니다...ㄷㄷ

깃허브의 Pull Request가 생기면서 이런 꼰대문화가 사라졌죠. 깃허브 만세!

효율적인 PR 방법

저도 위의 의견과 같은 생각입니다.
회사에 들어와서 깃허브를 활용하도록 교육시키며 이런저런 시스템을 만들고 있어요.

• 커밋 메시지를 의미있게 쓰기
• PR 올리기. 설명 쓰기.
• 테스트 자동화
• 배포 자동화

코드리뷰를 하는 문화가 정착되지 않는건

"자기가 만든것만 일로 보고 코드리뷰같은 남을 돕는 일은 '낭비' 라고 보는 기업 문화가 있으면 시간이 없다고 느낄 수 있어요."

저도 참 공감합니다.
저런 분위기라면 코드리뷰를 하더라도 하는 시늉만 하게 돼요.

이게 짤이 아니라 실제 상황이 되죠.
코드의 품질이 어떤지, 고칠 부분이 있는지 이런거 안보게 됩니다.
올라오자마자 내용도 제대로 안보고 Approve 누르기 바빠요.

PR이 Approve되지 않는 상황

정합성에 확신이 없는 상태가 굉장히 인상깊었습니다.
제가 저의 팀원들에게 '테스트 코드를 작성해야 하는 이유'를 설명할 때 저 말을 똑같이 썼었거든요.

"작성하신 코드가 문제를 일으키지 않고 잘 동작할거라는 자신이 있으신가요?"

재미있는(?) 코드리뷰 방법

이 부분을 보면서 장난으로 아래 채팅을 올렸는데

장난이 아닐지도

질문 답변 시간

저도 마찬가지입니다.
고졸. 비전공자. 국비지원 출신.
그렇지만 지상 최강의 개발자라고 말하며, 그것이 거짓말이 아니도록 굉장히 노력합니다.

저도 팀원들에게 종종 하는 말이에요.
"알고 있는것만 해도 좋은거에요. 곧 잘 하실거에요."

"한번에 깔끔하게는 못한다. 일단 돌아가게 만들고 고치는거다. 그런 방법이 있으면 알려달라."
ㅋㅋㅋㅋㅋㅋ
저도 처음 개발자가 됐을 땐 처음부터 깔끔하게 코딩해야 좋은 줄 알았었죠.

그리고 끝나고 질문도 했는데 답변을 해주셨습니다.
씁쓸하긴 했지만 페이스북에 올리니 좋은 의견들을 얻을 수 있었습니다.

지상 최강의 개발자 쥬니니가 섬기는 코딩의 신 아샬

박진우님과 박진우님이 불러주신 명우식님, 김지윤님, 김경환님.
모두 감사합니다.