홈앤서비스 SK BROADBAND

코드는 돌아가지만 어딘가 불안한 순간이 있습니다. 조금만 수정해도 문제가 번지고 기능을 추가할수록 속도는 느려집니다. 코드는 AI로도 짤 수 있지만 그대로 쓰기에는 망설여집니다. 이렇게 만든 코드가 프로젝트의 자산이 될지, 갚아야 할 부채가 될지 판단하는 일은 여전히 개발자의 몫입니다.
이 책은 단순히 돌아가는 코드를 넘어 ‘읽기 쉽고 유지보수하기 편하며 튼튼한 코드’를 작성하는 원칙을 다룹니다. 변수 이름을 짓는 아주 기본적인 고민부터, 복잡한 의존 관계를 풀고 아키텍처를 설계하는 방법, 그리고 팀원과 협업하며 품질을 높이는 노하우까지 개발자가 갖춰야 할 기본기를 체계적으로 정리했습니다.
특히 AI가 코드를 대신 짜주는 시대일수록 그 코드가 ‘좋은 코드’인지 판별하고 수정할 수 있는 개발자의 안목은 더욱 중요합니다. 이 책은 베테랑 엔지니어가 과거의 자신처럼 개발에 어려움을 겪는 개발자들을 위해, AI 시대에도 변치 않을 코드의 본질과 원칙을 담았습니다. 코드를 더 많이 짜는 개발자가 아니라 코드를 책임지는 개발자가 되고 싶다면, 이 책이 가장 단단한 출발점이 될 것입니다.

들어가며
1장 왜 좋은 코드를 작성해야 할까?
__1.1 소프트웨어의 가치
__1.2 유지보수성과 속도
__1.3 기술 부채 발생과 소멸
__1.4 좋은 코드를 작성하려면

2장 움직이는 코드에서 뜻을 전하는 코드로
__2.1 의도 표현하기
__2.2 이름으로 전하기
__2.3 주석으로 보충하기
__2.4 코드로 도메인 지식 표현하기

3장 큰 문제는 나누어 생각하기
__3.1 함수와 클래스 나누기
__3.2 자세히 읽지 않아도 사용할 수 있게
__3.3 코드 복잡도 계산하기
__3.4 응집도 높이기

4장 코드 정리하기
__4.1 디렉터리 단위로 정리하기
__4.2 모듈 단위로 정리하기

5장 얽힌 의존 관계 풀기
__5.1 의존 관계 의식하기
__5.2 의존 방향 검토하기
__5.3 추상에 의존하도록 하기
__5.4 결합도 낮추기

6장 좋은 코드 작성 원칙과 교훈
__6.1 KISS 원칙: 간단하게 유지하기
__6.2 YAGNI 원칙: 필요할 때 비로소 구현하기
__6.3 DRY 원칙: 중복 지식 줄이기
__6.4 바퀴 재발명: 같은 것 만들지 않기
__6.5 망치를 든 사람에게는 모든 것이 못처럼 보인다
__6.6 은 탄환은 없다

7장 어이없는 실수를 안 하려면
__7.1 매직 넘버 피하기
__7.2 자료형 제한 활용하기
__7.3 변경할 수 없는 데이터 사용하기
__7.4 데이터는 한곳에서 관리하기
__7.5 상태 변경과 정보 조회 분리하기

8장 코드는 작성보다 변경이 더 어렵다
__8.1 보이 스카우트 규칙: 왔을 때보다 더 깨끗하게
__8.2 백지상태에서 코드 바라보기
__8.3 조금씩 수정하기
__8.4 필요 없어진 코드 삭제하기

9장 아키텍처 고민하기
__9.1 계층 정리하기
__9.2 계층 구성 아이디어
__9.3 기능을 바탕으로 나누기
__9.4 아키텍처를 생각한다는 것

10장 파괴를 막는 자동화 테스트
__10.1 수동 테스트의 한계와 자동화
__10.2 자동화 테스트의 종류
__10.3 단위 테스트 만들기
__10.4 의존 코드를 테스트 대역으로 바꾸기
__10.5 테스트 커버리지 측정하기
__10.6 통합 테스트/E2E 테스트

11장 팀이 만드는 좋은 코드
__11.1 Git으로 버전 관리하기
__11.2 코드 리뷰하기
__11.3 코딩 규약 정하기
__11.4 자동으로 확인하기
__11.5 설계서 만들기

마치며
참고 문헌
찾아보기