코드 다듬기, 리팩토링

Readable Code: 읽기 좋은 코드를 작성하는 사고법를 듣고 요약한 내용입니다.

주석의 양면성

• 리팩토링 시, 큰 난관 중 하나는 히스토리를 전혀 알 수 없는 코드다.
• 의사 결정의 히스토리를 코드로 표현할 수 없을 때, 주석으로 설명
• 주석을 작성할 때, 자주 변하는 정보는 지양
  • 주석이 없는 코드보다 부정확한 주석이 더 위험하다.
  • 코드가 변경되었다면, 주석도 업데이트 해야한다.

💡 좋은 주석

우리가 가진 모든 표현 방법을 총동원해 코드에 의도를 녹여내고, 그럼에도 불구하고 전달해야 할 정보가 남았을 때 사용하는 주석

변수와 메서드의 나열 순서

• 변수는 사용하는 순서대로 나열한다.
  • 인지적 경제성
• 객체는 협력을 위한 존재
  • 정답은 없지만, 외부와 협력하는 public method는 상단에
• 나열 순서로도 의도와 정보를 전달할 수 있다.

패키지 나누기

• 문맥으로써 정보를 제공할 수 있다.
• 패키지를 쪼개지 않으면 관리가 어려워진다.
• 패키지를 너무 잘게 쪼개도 마찬가지로 관리가 어려워진다
• 패키지 변경은 팀원과의 합의를 이룬 시점에

IDE

• Ctrl + Alt + L
• SolarLint
• EditorConfig

능동적 읽기

• 복잡하거나 엉망인 코드를 읽고 이해하려 할 때, 리팩토링을 하자.
  • 공백으로 단락 구분
  • 메서드와 객체와 추상화 해보기
  • 주석으로 이해한 내용 표기하며 읽기
• 언제든지 rollback 할 수 있다
  • 겁먹지 말자
• 목표는 도메인 지식을 늘리는 것.
• 작성자의 의도를 파악하는 것.

오버 엔지니어링

• 적정 수준보다 더 높은 수준의 엔지니어링
  • 구현체가 하나인 인터페이스
    • 아키텍처 이해에 도움을 주거나, 추가될 가능성이 높다면 OK
    • 구현체를 수정할 때마다 인터페이스를 수정해야함
    • 코드 탐색에 영향을 줌. 애플리케이션이 비대해 짐.
  • 너무 이른 추상화
    • 정보가 숨겨지기 때문에 복잡도가 높아진다.
    • 의도 파악하기 어렵다.
• 경험의 영역이다. 경험을 쌓자.

은탄환은 없다. (No Silver Bullet)

• 체스를 코딩하려면?
  • 인터페이스와 클래스로 구현하자! → 유지보수 하기 쉬울거야!
  • but 체스는 500년동안 변하지 않았다..
• 클린코드는 은탄환이 아니다.
• 지속가능한 소프트웨어의 품질 vs 기술 부채를 안고 가는 빠른 결과물
  • 둘 사이에서의 줄다리기를 잘 해야한다.
  • 클린 코드를 항상 생각하면서 추후 수정이 쉽도록 작성해야 한다.
• 모든 기술과 방법론은 적정 기술의 범위 내에서 사용되어야 한다.
• 도구라는 것은, 일단 그것을 한계까지 사용할 줄 아는 사람이 그것을 사용하지 말아야 할 때도 아는 법이다.
  • 적정 수준을 알기 위해, 때로는 극단적으로 시도해보자.
  • 경험이 중요하다.