1장 깨끗한 코드

• 클린 코드에 대한 정리와 기준을 제시한다

previous

• 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 프로그래밍이며 요구 사항을 표현하는 언어가 바로 코드

나쁜 코드

• 나쁜 코드와 생상성은 반비례한다
• 재설계에는 이하와 같은 문제점이 존재한다
  - 새로운 프로젝트는 기존 시스템의 모든 기능을 제공해야 하며 개발 도중 추가, 변경되는 기존 시스템의 기능도
  따라잡아야 한다
  - 레거시 프로젝트가 크면 클수록 재설계가 어려워진다

깨끗한 코드?

1. 비야네 스트롭스트룹

• 나쁜 코드는 나쁜 코드를 불러온다
• 오류 처리를 철저하게 해야한다
• 한 가지를 잘하는 코드를 작성해야 한다

2. 그래디 부치

• 깨끗한 코드는 잘 쓴 문장처럼 읽혀야 한다
• 코드는 추측이 아닌 사실 기반으로 반드시 필요한 내용만 담는다

3. 큰 데이브 토마스

• 테스트케이스가 있어야 한다
• 의미있는 이름이 붙는다
• 의존성은 최소이며 각 의존성을 명확히 정의한다

4. 마이클 페더스

• 코드를 주의깊게 작성하여 깜끔하고 단정하게 정리한다

5. 론 제프리스

• 중복이 없다
• 한가지 기능만 수행해야 한다
• 가독성이 좋아야 한다
• 의미있는 이름을 사용한다
• 작은 추상화를 고려한다

6. 워드 커닝햄

• 독해하기 좋아야 하며 읽으면서 짐작한 대로 돌아가야 한다

보이스카우트 규칙

• 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라는 보이스카우트의 규칙을 따라 조금씩 지속적으로 코드를 개선하는 것이 필요한다

감상

• 이전 프로젝트를 할 때 한 메서드가 너무나도 많은 기능을 수행하는 바람에 해당 메서드에서 문제가 발생하는 경우 문제 발생 지점을 찾는것에 오랜 시간이 걸리는 경험을 한 적이 있다. 운영성 SI가 보통 그렇듯 해당 메서드에 대한 리팩토링은 이루어지지 않았고 심지어 기능이 더 추가되어서 모두가 손을 대고 싶어하지 않는 메서드가 되었다. 이러한 메서드가 하나만이 아니었기 때문에 개발자들이 언제나 오류를 분석하는 것을 어려워했다. 신규로 추가되는 기능만이라도 메서드를 분리하는 편이 좋았을거란 생각을 하는 것과 동시에 지금까지 안일하게 코드를 짜왔던 스스로를 반성할 수 있었다. 지금 당장 책에 나오는 모든 것을 적용하는 것은 힘들다 하더라도 최소한 SOLID 원칙만은 지킬 수 있도록 노력해야겠다.