스파게티 코드를 만들 것인가? 읽기 쉽고 수정하기 쉬운 코드를 만들 것인가? 코드 네이밍부터 코드 리뷰까지, 가독성을 높이는 코드 작성법 "도대체 무엇을 하는 코드인지 알 수가 없다", "사양을 변경해야 하는데 어디부터 손을 대야 하는 걸까" 개발자라면 이런 경험을 해본 적 있을 것이다. 분명 복잡한 기능을 구현하는 코드가 아닌데 이해하기가 어렵고, 곳곳에 함정이 있어서 조금만 변경해도 쉽게 망가지는 코드와 마주하거나, 코드를 작성할 당시에는 내 코드가 완벽하고 아름답다고 생각했지만 몇 달 후에 다시 봤을 때는 "내가 왜 이런 코드를 썼지?"라고 자책하기도 한다. 그래서 우리는 '코드 가독성'을 놓치지 말아야 한다. 이 책은 저자가 LINE에서 근무하면서 대규모 개발 프로젝트의 코드 리뷰와 리팩터링을 해본 경험을 바탕으로 코드 가독성과 코드 리뷰에 대해 설명한다. 먼저 읽기 쉬운 코드가 필요한 이유와 프로그래밍 원칙에 대해 이야기하고, 코드 네이밍 방법, 주석 작성법, 클래스 내부 구조인 상태와 함수를 설명하고, 클래스 간의 의존 관계도 설명한다. 또한, 팀 내 코드 리뷰 진행 방법과 가이드도 제시한다. 책 전체에 걸쳐 실제 코틀린 코드를 예로 설명하기 때문에 이론으로 배운 내용을 명확하게 이해할 수 있다.

1장 가독성 높은 코드를 작성하는 법 1.1 생산성 개선 __1.1.1 개발 규모와 생산성의 관계 __1.1.2 가독성을 높이기 위한 환경과 평가 체계 1.2 가독성 높은 코드를 작성하기 위한 요건 __1.2.1 가독성과 관련된 지표 __1.2.2 가독성을 높이기 위해 주의할 점 1.3 대표적인 프로그래밍 원칙 __1.3.1 보이스카우트 원칙 __1.3.2 YAGNI __1.3.3 KISS __1.3.4 단일 책임의 원칙 __1.3.5 섣부른 최적화는 만악의 근원 1.4 정리 2장 네이밍 2.1 네이밍에 사용하는 영문법 __2.1.1 명사 또는 명사구 __2.1.2 명령문 __2.1.3 그 외의 영문법 __2.1.4 문법을 무시하고 네이밍하는 이유 2.2 이름에서 알 수 있는 내용 __2.2.1 예: 인수 이름 __2.2.2 예: 함수 이름 __2.2.3 예외: 추상 메서드 2.3 단어 선택 __2.3.1 예: 모호하지 않은 단어 선택하기 __2.3.2 혼란스러운 약어 피하기 __2.3.3 단위나 실체를 나타내는 단어 추가하기 __2.3.4 긍정적인 단어 사용하기 2.4 언어, 플랫폼, 코딩 규약 2.5 정리 3장 주석 3.1 주석의 종류와 목적 3.2 문서화 주석 __3.2.1 안티패턴 __3.2.2 문서화 주석의 구성 __3.2.3 문서화 주석의 요약 __3.2.4 문서화 주석의 상세 3.3 비형식 주석 __3.3.1 규모가 큰 코드 분할하기 __3.3.2 직관적이지 않은 코드 설명하기 3.4 정리 4장 상태 4.1 가변 값이 더 적합한 경우 4.2 변수 간의 관계, 직교 __4.2.1 직교의 정의 __4.2.2 방법: 함수로 대체하기 __4.2.3 방법: 합 타입으로 대체하기 4.3 상태 전이의 설계 __4.3.1 불변성 __4.3.2 멱등성 __4.3.3 비순환 4.4 정리 5장 함수 5.1 함수의 책임 __5.1.1 함수 분할의 기본 방침 __5.1.2 명령과 쿼리의 분리 5.2 함수의 흐름 __5.2.1 정의 기반 프로그래밍 __5.2.2 조기 반환 __5.2.3 조작 대상에 따른 분할 5.3 정리 6장 의존 관계 6.1 의존 관계의 예 6.2 의존의 강도: 결합도 __6.2.1 내용 결합 __6.2.2 공통 결합과 외부 결합 __6.2.3 제어 결합 __6.2.4 스탬프 결합과 데이터 결합 __6.2.5 메시지 결합 6.3 의존 방향 __6.3.1 호출자 → 호출 대상 __6.3.2 구체적 → 추상적 __6.3.3 복잡/가변 → 단순/불변 6.4 의존의 중복 __6.4.1 연결된 의존 관계 __6.4.2 의존 대상 집합의 중복 6.5 의존의 명시성 __6.5.1 안티패턴 1: 과도한 추상화 __6.5.2 안티패턴 2: 암묵적인 값의 범위 6.6 정리 7장 코드 리뷰 7.1 리뷰이의 주의 사항 1: 리뷰하기 쉬운 풀 리퀘스트 만들기 __7.1.1 풀 리퀘스트의 목적 명시하기 __7.1.2 풀 리퀘스트 분할하기 __7.1.3 커밋 구조화하기 7.2 리뷰이의 주의 사항 2: 리뷰 코멘트 적용하기 __7.2.1 잘못된 의견이나 질문이 나온 원인 찾기 __7.2.2 제안 의도 파악하기 __7.2.3 다른 부분에 적용하기 7.3 리뷰어의 주의 사항 1: 리뷰어의 원칙 __7.3.1 요청받은 리뷰를 방치하지 않기 __7.3.2 문제 있는 풀 리퀘스트 거부하기 __7.3.3 기한을 지나치게 의식하지 않기 __7.3.4 ‘제안’이 아닌 ‘의견’ 제시하기 7.4 리뷰어의 주의 사항 2: 코멘트 내용 __7.4.1 사례 분석 7.5 정리 부록 이 책을 읽는 데 필요한 코틀린 문법

오늘만 코딩하는 사람이 아니라면 누구나 코드의 품질을 고민합니다. 소프트웨어 개발은 단순히 제품을 구현하는 것에만 그치지 않고 문제의 원인을 찾고 개선해 나가며, 지속 가능성을 고려한 최적의 결과물을 만들어 나가는 과정이기 때문이죠. 이 책은 높은 품질의 코드를 쓰기 위한 원칙을 배움과 동시에 그 원칙을 언제 어디에 적용할 것인지를 선택하는 데 도움을 줄 것입니다. 특히 마지막 장에서 다루는 코드 리뷰는 이 책의 내용을 활용하기에 완벽한 기회입니다. IT가 세상의 중심이 된 만큼, 우리는 소프트웨어 개발자가 짊어져야 할 책임에 대해서도 고민해야 합니다. 코드는 그 존재만으로도 누군가가 유지보수해야 할 부채가 되므로, 자신의 코드가 누군가에게 잘못 이해되어 제품의 결함을 유발하거나 생산성을 저해하는 요소가 되지 않도록 노력해야 합니다. ‘그냥 돌아가기만 하면 되는 코드’, ‘쓰기에 간편한 코드’가 아닌, 그 코드를 접하게 될 모든 개발자가 쉽게 개선하고 확장할 수 있도록 ‘읽는 사람을 배려한 코드’를 작성해야 합니다. _역자의 말 중에서