『코드 작성 가이드』 - 이시가와 무네토시

 

📖 간단한 책 소개와 후기

 

감사하게도 코드 리뷰 문화가 활발한 팀에서 인턴 생활을 시작할 수 있게 되었다. 하지만 코드 리뷰 경험이 많지 않다 보니 어떤 리뷰를 남겨야 하는지 잘 몰라 어려움을 겪었다.

 

코드 리뷰를 경험하며 알게 된 문제는 ‘어떤 코드가 좋은 코드인가’에 대한 내 기준이 명확하지 않았다는 것. 그러다 보니 리뷰를 남기는 것도, 리뷰 받기 좋은 코드를 작성하기도 쉽지 않았다. 리뷰를 하나둘 받으며 조금씩 감을 잡아가고 있었지만, 이번 기회에 확실히 공부해 보고자 이 책을 읽기 시작했다.

 

내용을 간단히 소개하면, LINE에서 일하는 저자가 ‘가독성 높은 코드를 작성하는 법’이라는 주제를 시작으로 좋은 네이밍 방법, 주석 다는 법, 코드 리뷰 방법 등 개발자라면 한 번쯤 고민해 봤을 주제에 대한 가이드를 소개한 책이다.

 

외국인 저자의 책이라서 번역이 잘 되었을까 걱정도 했지만, 그런 걱정이 무색하게 읽기 쉽게 잘 쓰여있었다. 다만 예제 코드가 주로 Java로 작성되어 있어서 프론트엔드 개발자라면 적용하기 힘들거나 어려운 내용이 종종 있어 아쉬웠다. 그래도 큰 틀에서는 직군 상관없이 도움이 될 만한 내용 위주로 소개하고 있어 큰 무리는 없었다.

 

네이밍 원칙에 대한 소개부터, 좋은 코드의 기준을 여러 사례를 보여주며 쉽고 명확하게 설명해 줘서 좋았다. 책을 읽을 때 목표였던 ‘좋은 코드의 기준’을 세워가는 데 큰 도움이 되었다. 책을 읽고 나서 어려웠던 코드 리뷰를 하기도, 받기도 한층 더 수월해졌다. 주니어 개발자라면 한 번쯤 추천하고 싶은 책이다.

 

✍️ 인상적인 내용 정리

 

가장 기대했던 내용은 2장 네이밍이었다. 모든 개발자가 공감하겠지만, 항상 적절한 네이밍 고민하는 것이 어려워 책에서 뭔가 실마리를 찾을 수 있지 않을까 생각했다. 뿐만 아니라, 네이밍에서라도 팀에 조금이나마 도움이 되는 리뷰를 남기고 싶다는 욕심도 있었다. 책에서 소개된 네이밍의 핵심은 다음과 같이 요약해 보았다.

 

• 가독성 높은 네이밍
  • 정확하고 설명적이어야 함
  • 가장 중요한 기준은 이름만으로도 코드를 이해할 수 있는지 여부
  • 심미성, 통일성, 일관성은 가독성을 위한 수단일 뿐 그 자체가 목적이 되면 안됨.
• 적절한 이름과 부적절한 이름
  • 적절한 이름: 대상이 무엇인지, 무엇을 하는지를 나타내는 이름
  • 부적절한 이름: 언제, 어디서, 어떻게 사용되는지를 나타내는 이름

 

어렴풋이 여기저기서 단편적으로 들어왔던 ‘좋은 네이밍’에 대해 어느 정도 머릿속에서 정리된 느낌이었다. 이외에도 주로 명사를 사용하는 인수, 변수의 네이밍은 중요한 단어를 이름 마지막에 둔다거나, 주로 명령문을 사용하는 함수는 동사 원형을 이름 마지막에 넣기, flag, check, old같은 모호한 단어는 지양하기와 같이 곧바로 적용해 볼만한 원칙도 많아서 꽤 도움이 되었다. 물론 언어, 플랫폼, 프로젝트에서 요구하는 원칙이 최우선이라는 말도 빼놓지 않았다.

 

 

책을 읽고 가장 도움이 되었던 내용은 7장 코드리뷰였다. 7장은 ‘리뷰어의 유의사항’과 ‘리뷰이의 유의사항’으로 나뉘어 있는데, ‘리뷰어의 유의사항’에 도움이 될만한 내용이 많이 있었다. 크게는 리뷰하기 좋은 PR 만드는 법과 리뷰 받은 코멘트 적용하는 과정에서의 유의사항을 소개하는데, 정말 간단히 요약하면 다음과 같다.

 

• 리뷰하기 좋은 PR 만들기
  • 리뷰하기 좋은 PR은 목적이 명확하고, 크기가 작고, 포함된 커밋이 구조적이다.
  • 이번 PR에서 하지 않는 것과 앞으로의 PR 계획을 적어두는 것도 리뷰어에게 도움이 된다.
  • 큰 기능을 개발할 때 PR 분할하는 방식
    • 상향식 방식 : 부품이 되는 코드 먼저 만들고 사용하는 쪽의 코드를 나중에 작성
    • 하향식 방식 : 상세 메서드를 생략 한 스켈레톤 코드 PR을 먼저 올린다 → 구조 리뷰에 용이
• 리뷰 코멘트 적용하기
  • 받은 질문에 곧바로 답변 작성하기 전에 검토해볼만한 점
    • 로직을 변경하여 의문이나 오해 소지 줄이기 → 질문 자체를 피할 수 있는 코드를 만든다.
    • 코드 내에 의문이나 오해를 해소할 설명 추가하기
  • 제안 받은 개선 방법을 다른 부분에도 적용할 수 있는 지 확인
  • 유의미한 피드백을 받았을 때 팀원들과 공유하는 체계를 마련한다면 팀 전체의 기술력 향상에도 도움이 된다.

 

미처 다 요약하진 못했지만, PR 분리하는 방법에 대해 예시까지 보여주며 상세하게 설명하고 있어 회사에서 따라 해보기 좋았다. 리뷰 적용하기에서는 미처 생각해 보지 못한 점에 대해 많이 짚어주어서 많이 배웠다. 이외에도 7장에서 소개하는 내용들이 너무 좋다고 느껴져서 팀원들과 스터디 시간에 내용을 요약해 소개하기까지 했다. 코드 리뷰에 어려움을 겪는 사람들이라면 7장만 골라 읽어도 후회하지 않을거라 생각한다.

 

📝 추가로 기억에 남는 문장 정리

 

개발자 대부분은 사실 코드를 ‘쓰는 것’보다 ‘읽는 것’에 개발 시간을 더 많이 할애합니다. - 18p

더 나은 결론에 더 빨리 도달하려면 혼자서 오랜 시간 고민하는 것보다 다른 개발자와 논의하여 결론을 도출하는 편이 더 생산적입니다. - 27p

달리 표현하면, 거대한 풀 리퀘스트를 만드는 일은 어쩌면 작업이 헛수고가 될지도 모르는 위험한 도박과 같다고도 할 수 있을 것입니다. - 260p

문제를 발견하기 전에 코드에서 이해되지 않는 부분이 있다면 무리하게 해석을 시도하는 것보다 리뷰이에게 질문하는 것이 더 효율적입니다. 리뷰어는 자신이 가진 의문을 다른 개발자들도 가질 것이라고 가정해도 좋습니다. - 281p