본문 바로가기

책/CleanCode

✨ Clean Code 1장: 깨끗한 코드

😡 나쁜 코드로 인한 문제점

  • 출시에 바빠 코드를 짜다보면, 기능을 추가할수록 코드는 엉망이 되어간다. 결국엔 감당하지 못하는 수준에 이른다.
  • 나쁜 코드는 개발 속도를 크게 떨어뜨린다. (프로젝트 초기에는 번개처럼 나가다가 결국 굼벵이처럼 기어간다)
  • 팀 생산성은 떨어진다.
  • 르블랑의 법칙 - 나중은 결코 오지 않는다. 즉, 나중에 손보겠다고 생각한 코드는 결코 오지 않는다는 의미이다.

👨🏻‍💻 프로그래머들의 책임

  • 좋은 코드를 사수하는 일은 프로그래머의 책임이다.
  • 관리자가 일정과 요구사항을 강력하게 밀어붙이는 것도 그들의 책임이기 때문이다.
  • 가장 좋은 방법은 언제나 코드를 깨끗하게 유지하는 습관을 가져야 한다.

🛀🏻 깨끗한 코드란?

  • 그림을 그리는 행위와 비슷하다. (빈 캔퍼스를 우아한 작품으로 바꿔가는 화가와 같다)
  • 보기에 즐거운 코드를 의미한다.
  • 깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 것은 아니다.
  • 코드 감각을 가진다면 위를 구분할 줄 알고, 절제와 규율을 적용해 나쁜 코드를 좋은 코드로 바꾸는 전략도 파악한다

✍️ 깨끗한 코드를 어떻게 작성할까?

  • 논리가 간단해야 버그가 숨어들지 못한다.
  • 의존성을 최대한 줄여야 유지보수가 용이해진다.
  • 세세한 사항까지 꼼꼼하게 처리하는 코드를 만들어야 한다.
    즉, 오류처리, 메모리 누수, 경쟁 상태, 일관성 없는 명명법 등 세세한 부분까지 신경써야 한다.
  • 한 가지에 집중해야 한다. (나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다)
  • 잘 쓴 문장처럼 읽혀야 한다. (가독성)
  • 다른 사람이 고치기 쉬워야 한다.
  • 테스트 케이스가 있어야 한다.
  • 주의 깊게 짰다는 느낌을 줘야 한다. (고치려고 해도 손 댈 곳이 없는 느낌)
  • 중복이 없어야 한다.
  • 추상 메서드나 추상 클래스를 만들어 실제 구현을 감싸 작게 추상화해야 한다. 그러면 실제 구현은 언제든지 바뀌어도 괜찮다.
  • 읽으면서 짐작한 대로 돌아가야 한다.

👊🏻 우리는 저자다.

  • Javadoc에서 @author 필드는 저자를 소개한다. 즉, 독자와 잘 소통할 책임도 있다.
  • 보이스카우트 규칙 (캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라)
    즉, 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다.

🗣 느낀점

뭐든지 과하지 않아야 한다고 생각한다.

클린 코드를 지키는 것은 좋지만, 과도하게 할 필요는 없다고 생각한다.

즉, 너무 엄격할 필요는 없다.

평소에 의식적으로 연습해서 습관을 들이자.