읽기 쉽고 이해하기 좋은 코드를 작성하려면 어떻게 해야 할까?
현직 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가 세상의 중심이 된 만큼, 우리는 소프트웨어 개발자가 짊어져야 할 책임에 대해서도 고민해야 합니다. 코드는 그 존재만으로도 누군가가 유지보수해야 할 부채가 되므로, 자신의 코드가 누군가에게 잘못 이해되어 제품의 결함을 유발하거나 생산성을 저해하는 요소가 되지 않도록 노력해야 합니다. ‘그냥 돌아가기만 하면 되는 코드’, ‘쓰기에 간편한 코드’가 아닌, 그 코드를 접하게 될 모든 개발자가 쉽게 개선하고 확장할 수 있도록 ‘읽는 사람을 배려한 코드’를 작성해야 합니다.

_역자의 말 중에서