코드리뷰는 필요하다.
이런 당연한 이야기를 왜 하나 싶겠지만, 충격적이게도 나의 첫 회사는 코드리뷰가 없는 회사였다.
커밋을 하면 단번에 푸시가 되고, 테스트용 서버에 올려서 테스트를 해보다가, 안되면 피드백을 받고 다시 커밋하고...와웅
코드리뷰가 없으면 무섭다.
Q. 온보딩 없이 받은 업무에서 처음 써보는 svn에 코드리뷰없이 40페이지 짜리 코드 컨벤션을 읽고 커밋을 해야되는 주니어의 심정은..?
A. 아주 ...아주 무서웠다. 내 코드 한줄로 서버가 터질수도, 페이지 접속이 안될 수도 있는거니까.
이런 상황을 방지하기 위해 코드리뷰는 필요하다.
42서울을 다니면서 나는 코드리뷰에 익숙해져 있었고, 리뷰 과정에서 받게 되는 피드백을 통해 코드 품질이 향상되는 것도 알고 있었다.
코드리뷰가 있다는 것만으로도 코드 작성자는 내 코드의 가독성을 고민하고, 자연스럽게 컨벤션 문화에 익숙해진다.
좋은 코드리뷰 태도 란 아직도 어려운 주제라고 생각하지만, 이제 어느정도 기준이 잡힌 것도 같다. 내 기준은 다음과 같다.
1. 개발자와 개발자의 코드를 동일선상에 두지 말자.
내 코드가 지적받았다고, 수정사항이 생겼다고 내가 지적받거나 수정해야되는 것이 아니다. 나는 주니어고, 모르는게 당연하고, 수정사항이 안 생기면 이상한거다. 오히려 다른 사람의 눈에 내 코드가 괜찮아 보였다면 나는 무서워한다. 내가 생각지도 못한 곳에서 에러가 발생할 가능성이 높아진거니까...!
2. 개선이 필요한 이유를 명확하게 전달하자.
단순히 A을 개선하면 어떨까요? (q1) 보다는 저는 B가 걱정되니 A을 개선하면 어떨까요? (q2) 라는 피드백을 남기면 코드 작성자는 혼자서 B에 대한 충분한 고민을 진행한 후 A를 개선할지 말지를 결정할 수 있다. 내가 q1처럼 질문했다면, 코드작성자는 왜?라는 의문을 갖게 되고, 그에 대해서 나와 한번 더 대화를 나누어야 하지만 q2처럼 질문한다면 그 과정이 없어질 수 있다. 프로세스가 단축되는거다!
3. 긍정적인 피드백을 꼭 남기기
사람이라는 동물은 늘 칭찬을 갈구하고, 인정받고 싶어한다.
아무것도 아닌 긍정적인 한마디, 칭찬이 오히려 성장에 대한 욕구를 불러 일으킨다는 것을 나는 개인적으로 경험했기 때문에 꼭 처음이든 마지막이든 수고했다거나 이전보다 성장했다거나, 코드가 깔끔하다거나 가독성이 좋다는 등의 칭찬을 포함하려고 노력한다.
4. 이건 정말 중요한데, 물어보자
모르는게 있다? 축하한다. 당신에게 축복인 사람을 만난거다.
코드나, 리뷰에서 모르는 걸 발견했다면 수줍어말고 물어보자.
그건 주니어의 특권이나 마찬가지니까.
언제나 아낌없이 물음표를 날려보자. 얍????얍???
5. 코드 그 너머의 사람을 보자
아무리 코드가 거지같다고 해도, 가독성이 떨어진다고 해도, 왜 이런방식으로 구현했는지 모르겠다고 해도, 리뷰는 부드럽게 작성하자.
내가 코드와 나를 분리한다고 해서, 상대방도 그럴 거라는 보장은 없다.
내가 리뷰하는 대상이 코드라고 해서 그 글을 읽는 것도 코드는 아니니까. 늘 사람의 기분을 신경쓰고 리뷰를 하자.
문자로 전달되는 글은 그 글을 쓰는 사람의 감정을 100% 전달해주지 못하니까 잘못 전달될 수도 있다는 걸 잊지말자.
6. 문제 해결 방식과, 리소스를 전달하자
이건 사소하다고 생각할 수 있지만 생각보다 코드 작성자에게 도움이 되는 정보다.
내가 알고 있다고 상대도 알고 있는건 아니니까. 상대가 충분히 고민을 해서 이 방식을 선택했다고 해도 나는 그걸 아는 건 아니니까.
내가 아는 방식, 그 방식에 대한 리소스를 전달하면 그에 대한 피드백으로 내가 알고 있었는데 이 방식을 선택한 이유라던가, 아니면 몰랐는데 이런걸 시도해보겠다는 피드백이 돌아올거다.
그러니까 일단 말해보자. 이게 지식공유의 아주 작은 시작이 될거다.
마지막으로 당연하겠지만, 이건 나의 기준이므로, 절대적으로 적용하려 하지 않으면 좋겠다..( by. 쭈구리 주니어)
앞으로 모든 회사들이 코드 리뷰에 진심이 되기를 바라며 🙏
짧은 제 견해를 읽어주셔서 감사합니다. :)
