chapter1.md

1장 깨끗한 코드

기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다.

이렇게 명시한 결과가 바로 코드다.

나쁜 코드

우리가 짠 쓰레기 코드는 나중에 정리하겠다고 다짐하지만, 나중은 결코 오지 않는다. (르블랑의 법칙)

나쁜 코드로 치르는 대가

• 생산성 저하
• 기술부채를 만들어 수정을 어렵게한다.
• 새로운 시스템을 만들어야 한다.
  • 현시스템을 유지보수하며 대체할 새로운 시스템 개발은 현실적으로 매우 어렵다.

나쁜 코드로 계속 작성하는 경우에 보이는 생산성 대 시간 그래프

태도

나쁜 코드의 책임은 일정을 촉박하게 만든 관리자 때문일까? 하지만 잘못은 전적으로 우리 프로그래머에게 있다.

우리가 먼저 좋은 코드를 작성하기 위해 관리자에게 주장해서 일정을 확보하고, 좋은 코드를 작성해야 한다.

의사의 예처럼 프로그래머도 마찬가지다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

원초적 난제

모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 느낀다.

진짜 전문가는 이 말이 틀렸다는 사실을 잘 안다. 나쁜 코드를 양산하면 기한을 맞추지 못한다.

오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다.

기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

깨끗한 코드란?

비야네 스트롭스트룹

• 논리가 간단해야 한다.
• 의존성을 최대한 줄여야 한다.
• 깨끗한 코드는 한 가지를 제대로 한다.

그래디 부치

• 깨끗한 코드는 잘 쓴 문장처럼 읽힌다.

데이브 토마스

• 깨끗한 코드는 다른 사람이 고치기 쉽다.
• 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다.

마이클 페더스

• 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다.

론 제프리스

• 모든 테스트를 통과한다.
• 중복이 없다.
• 시스템 내 모든 설계 아이디어를 표현한다.
• 클래스, 메소드, 함수 등을 최대한 줄인다.

워드 커닝햄

• 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다.

밥 아저씨는?

• 책을 봐라~
• 이 책의 내용은 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다.

우리는 저자다

코드를 읽는 시간 대 코드를 짜는 시간 비율이 10 대 1을 훌쩍 넘는다.

새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.

따라서 비율이 이렇게 높으므로 읽기 좋은 코드가 매우 중요하다.

깨끗한 코드를 작성하기 위해 노력하자.

보이스카우트 법칙

잘 짠 코드가 전부가 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다.

캠프장은 처음 왔을 때 보다 더 깨끗하게 해놓고 떠나라
=> 코드를 작성하기 이전의 코드보다 좀 더 깨끗한 코드를 작성한다면 코드는 절대 나빠지지 않는다.
한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다.
변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if 문 하나를 정리하면 충분하다(오늘도 리팩토링 해보자).

시간이 지날수록 코드가 좋아지는 프로젝트에서 작업한다고 상상해보라!
전문가라면 너무도 당연하지 않은가!
지속적인 개선이야말로 전문가 정신의 본질이다.

SOLID 원칙

로버트 마틴씨가 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스가 두문자어 기억술로 소개한 것이다.

프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다.

• SRP(The Single Responsibility Principle):
  클래스에는 한 가지, 단 한 가지 변경 이유만 존재해야 한다.

• OCP(The Open Closed Principle):
  클래스는 확장에 열려 있어야 하며 변경에 닫혀 있어야 한다.

• LSP(The Liscov Substitution Principle):
  상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다.

• ISP(The Interface Segregation Principle):
  클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.

• DIP(The Dependency Injection Principle):
  추상화에 의존해야 하며, 구체화에 의존하면 안된다.

결론

• 예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다.
  이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다.
  코드를 많이 읽고 직접 설계하고 코드를 작성하고, 리팩토링해서 더 나은 코드를 만들어봐야 한다. 나머지는 우리에게 달렸다.
• "연습해, 연습!"