1장 깨끗한 코드
코드가 존재하리라
프로그래밍
- 상세하게 요구사항을 명시하는 작업
- 그 결과가 코드이다.
나쁜 코드
- 안 돌아가는 프로그램보다 돌아가는 쓰레기(대충 짠 프로그램)가 좋다라고 생각하며 나중에 정리하겠다고 다짐한 경우가 있을 것이다. 하지만, 나중은 결코 오지 않는다.
나쁜 코드를 치르는 대가
- 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다.
- 생산성이 떨어지면, 새로운 인력을 추가로 투입한다. 하지만, 시스템 설계에 대한 조예가 깊지 않기 때문에 나쁜 코드를 더 많이 양산한다.
- 기존 프로젝트를 대체하기 위한 새로운 프로젝트를 만들기 시작한다. 하지만, 기존 기능에 가해지는 변경들까지 따라잡기에는 시간이 오래 걸린다. 기존 시스템을 따라잡을 즈음에는 모두 팀을 떠나고 다시 새로운 팀원들이 새 시스템을 설계하고자 한다.
태도
- 좋은 코드를 사수하는 일은 프로그래머들의 책임이다.
설계를 뒤집는 방향으로 요구사항이 변하거나 일정이 촉박해도…
원초적 난제
- 나쁜 코드를 양산하면, 기한을 맞추지 못한다.
- 언제나 코드를 최대한 깨끗하게 유지하는 습관이 빨리 가는 유일한 방법이다.
깨끗한 코드라는 예술?
- ‘코드 감각’이 있으면, 좋은 코드와 나쁜 코드를 구분한다. 또한, 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다.
깨끗한 코드란?
비야네 스트롭스트룹
- 보기에 즐거운 코드
- 논리가 간단해야한다. => 버그가 없다.
- 의존성을 최대한 줄여야 한다. => 유지보수가 쉬워진다.
- 오류는 명백한 전략에 의거해 철저히 처리한다.
- 성능을 최적으로 유지해야 한다.
- 나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다.
- 한가지를 제대로 한다.
그래디 부치
- 단순하고 직접적
- 설계자의 의도를 숨기지 않는다.
- 잘 쓴 문장처럼 읽힌다. = 가독성
- 명쾌한 추상화와 단순한 제어문으로 가득하다.
- 코드는 사실에 기반해야 한다.
- 단호하다는 인상을 줘야 한다.
데이브 토마스
- 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
- 단위 테스트 케이스와 인수 테스트 케이스가 존재한다.
- 의미 있는 이름이 붙는다.
- 특정 목적을 달성하는 방법은 하나만 제공한다.
- 의존성은 최소이며, 각 의존성을 명확히 정의한다.
- 코드가 문학적이어야 한다.
마이클 페더스
- 누군가 주의 깊게 짰다는 느낌을 준다.
- 고치려고 살펴봐도 손 댈 곳이 없다.
론 제프리스
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.
- 초반부터 간단한 추상화 고려하기
- 추상 메서드나 추상 클래스를 만들어 실제 구현을 감싼다.
- 진짜 문제에 신경 쓸 여유가 생긴다.
- 다른 기능을 구현하느라 시간과 노력을 낭비할 필요가 없다.
워드 커닝햄
- 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행하는 경우
- 코드가 그 문제를 풀기 위한 언어처럼 보이는 경우
우리는 저자다
- 코드를 읽는 시간 : 코드를 짜는 시간 = 10 : 1
- 새로운 코드를 짜면서 끊임없이 기존 코드를 읽는다.
- 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다.
보이스카우트 규칙
- 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면, 코드는 절대 나빠지지 않는다.
- ex)
- 변수 이름 하나 개선
- 조금 긴 함수를 분할
- 중복 제거
- 복잡한 if문 하나 정리