드디어 마지막 장들이다........

16장 SerialDate 리팩터링

• 테스트 커버리지 50%인 SerialDate 를 리팩토링하는 과정....
• 16장도 코드 설명이 대부분이라 거의 쓸게 없네
• 그냥 저자의 코드 짜는 흐름과 가치관을 볼 수 있는것 같다
• 테스트 커버리지를 증가시키고 더욱 유지보수가 쉽고 가독성이 좋은 코드를 짜는 과정...
• 이 과정을 통해 다음 사람은 코드를 좀 더 쉽게 이해하고 쉽게 개선할것이라는 기대효과

17장 냄새와 휴리스틱

코드 냄새라는 안좋은 코드에 대한 내용

• 주석

  • 다른 시스템에 저장할 정보 는 주석으로 적절하지 못하다
  • 오래된 주석, 엉뚱한 주석, 잘못된 주석은 쓸모가 없다. 삭제해라
  • 코드만으로 충분한데 구구절절 설명하는 중복되는 주석은 필요 없다
  • 주석을 작성할거면 간결하고 명료하게 작성해라
  • 주석 처리된 코드는 읽는 사람을 헷갈리게 만들고 쓸모가 없다

• 환경

  • 빌드는 간단히 한 단계로 끝나야 한다. 명령이나 스크립트를 잇달아 실행해 각 요소를 따로 빌드할 필요가 없어야 한다.
  • 모든 단위 테스트 는 한 명령으로 돌려야 한다

• 함수

  • 함수에서 인수 개수는 작을수록 좋고, 없으면 가장 좋다. 넷 이상은 최대한 피한다
  • 플래그(boolean) 인수는 혼란을 초래하므로 피해야 마땅하다 → 근데 이 플래그 하나를 위한 메서드를 따로 빼는것도 코드를 왔다갔다 하는 비용이 생긴다고 생각해서 나는 피함.
  • 아무도 호출하지 않는 함수는 삭제한다

• 일반

  • 소스 파일 하나에 언어 하나만 사용해라
  • 함수나 클래스는 다른 프로그래머가 당연하게 여길 만한 동작과 기능을 제공해야 한다
  • 스스로의 직관에 의존하지 말고 경계 조건을 찾아내 테스트해라
  • 컴파일러 경고를 꺼버리면 빌드가 쉬워질지 모르지만 좋지 않다
  • DRY(Don't Repeat Yourself) 중복된 코드를 피해라
  • 추상화를 똑바로 해라. 잘못된 추상화는 고치기 어렵다
  • 기초 클래스는 파생 클래스를 몰라야 한다. 기초 클래스가 파생 클래스에 의존하면 안됨
  • 인터페이스를 작고 깐깐하게 만들어라. 정보를 제한해 결합도를 낮춰라
  • 죽은 코드를 발견하면 시스템에서 제거해라 - 불가능한 if, throw 없는 try catch에서 catch
  • 변수와 함수는 사용되는 위치에 가깝게 정의해라
  • 코드에 일관성을 부여해라
  • 무관한 개념을 인위적으로 결합하지 마라
  • 클래스 메서드는 자기 클래스의 변수와 함수에 관심을 가져야지 다른 클래스의 변수와 함수에 관심을 가져서는 안된다
  • 코드를 짤 때는 의도를 최대한 분명히 밝혀라
  • 코드는 독자가 자연스럽게 기대할 위치에 배치해라
  • static으로 정의하면 안되는 함수를 static으로 정의하지 마라
  • 서술적인 변수를 많이 써라
  • 이름만으로 분명한 함수를 만들어라
  • 코드의 알고리즘을 이해해라 → 나도 이 부분은 고쳐야 할 것 같다. 다른 사람의 코드가 어려우면 설렁설렁 보는 경향이 있다...
  • IF/ELSE나 SWITCH/CASE 보다 다형성을 사용해라.
  • 업계 표준에 기반한 구현 표준을 따라라
  • 매직 넘버는 상수로 교체하라 → 이거 중요한거 아는데 맨날 까먹는다....
  • 설계 결정을 강제할 때는 규칙보다 관례를 사용해라
  • 조건을 캡슐화해서 함수로 표현하라 → 이러면 함수가 너무 많아지는데....
  • 부정 조건은 피해라. 가능하면 긍정 조건으로 표현
  • 함수는 한가지 일만 해라
  • 시스템 전반에 걸쳐 일관성을 유지해라
  • 경계 조건을 캡슐화해라. → +1 같은거 변수로 만들라는 뜻
  • 설정 정보는 최상위 단계에 둬라
  • 자신이 직접 사용하는 모듈만 알도록 코드를 짜라

• Java

  • 긴 Import를 피하고 와일드카드를 사용해라
  • 상수는 상속하지 마라
  • enum을 활용해라

• 이름

  • 서술적인 이름을 사용해라 → 이름만 봐도 의도를 알 수 있도록
  • 적절한 추상화 수준에서 이름을 선택해라. 구현을 드러내는 이름은 피해라
  • 가능하다면 표준 명명법을 활용해라
  • 함수나 변수의 목적을 명확히 밝히는 이름을 선택해라
  • 긴 범위는 긴 이름을 사용해라
  • 인코딩을 피해라
  • 이름으로 부수 효과를 설명하라

• 테스트

  • 테스트 케이스는 깨질 만한 부분을 모두 테스트해야 한다
  • 커버리지 도구를 사용해 테스트가 빠뜨리는 공백을 찾아라
  • 사소한 테스트를 건너뛰지 마라
  • 경계 조건을 테스트하라 → 경계조건 얘기 되게 많이 하시네
  • 버그 주변은 철저히 테스트해라
  • 실패하는 패턴을 살펴라
  • 테스트는 빨라야한다

후기

드디어 클린코드 책을 다 읽었다!!!
따라하면 좋은 내용들이 굉장히 많이 있는 것 같다.
하지만 다 따라하지는 못할 것 같고 최대한 지키려고 노력을 해보자
나의 명확한 기준을 세우는데에 도움이 될 것 같다.
쉽게 생각하면 클린 코드 는 나뿐만 아니라 다른 사람들도 보기 좋은 코드를 말하는 것 같다.