1. 책의 예시 코드에서 사용한 리팩토링 기법을 살펴보자.

<aside> ✅ - 클래스를 선언한다.

• 선언한 클래스를 상속하는 클래스가 많아지면, 해당 클래스를 추상 클래스로 변경한다.
• 추상 메소드의 개수가 많아지면 해당 클래스를 인터페이스로 추출한다.

</aside>

• 왜 개발 시작 단계에서 인터페이스의 사용을 설계하고 적용하는게 어려울까? 라는 생각을 많이 했는데, 인터페이스는 처음부터 선언해 사용하는 것 보다 코드를 짠 다음 리팩토링 하는 과정에서 공통된 기능을 끄집어낼 때 사용하는 것이 좀 더 자연스러운 흐름이라는 것을 느꼈다.

<aside> ✅ - 비즈니스 로직을 처리하는 클래스를 선언한다. (주로 서비스 계층)

• 해당 클래스에서 오류/예외를 처리하는 부분을 별개의 클래스로 분리한다.
• 오류/예외 처리 로직은 분리한 Exception 클래스에서 관리한다.

</aside>

• Spring MVC 구조에서는 Exception 로직은 별개의 Exception 클래스로 관리하는 것이 일반적
  • 비즈니스 로직 클래스가 깨끗해져 차후 확장이 쉬워진다.
• 그러나 ‘비즈니스 로직’ 의 개념은 유동적이기 때문에, 서비스 클래스가 단일 책임 원칙을 위반하게 되는 경우가 많다.
  • 계좌이체 로직을 처리하는 클래스를 작성했다.
    • 계좌이체 처리 로직, 계좌이체 후 잔액 계산 로직, 계좌이체 실패시 재시도 로직 모두 계좌이체 에 해당하니까 하나의 클래스로 작성해야지!
    • 앗 클래스 하나에 코드라인이 너무 많아졌다!
• 클래스의 책임이 너무 무겁다고 느껴진다면, 기능을 세분화하고 클래스를 세분화 하는 것을 고려하자.

2. 소프트웨어 설계와 분할

• 소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다.
  • 적절한 장소를 만들어 코드만 분리해도 설계가 좋아진다.
  • 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 더 쉬워진다.
    • 코드에 주석을 작성하시는 편인가요? 🤔
    • 주석 없이 코드만으로 의도를 파악할 수 있어야 좋은 코드이다?

3. 결론

• 나쁜 코드도 깨끗한 코드로 개선할 수 있지만, 비용이 엄청나게 많이 든다.
  • 모듈이 서로 얽히고 설켜 뒤엉키고 숨겨진 의존성이 수도 없이 생긴다.
  • 오래된 의존성을 찾아내 깨려면 상당한 시간과 인내심이 필요하다.
• 처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽다.
  • 처음부터 깨끗한 코드를 짜는 것은 쉽지 않다.
  • 하지만 아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다.
• 코드는 언제나 최대한 깔끔하고 단순하게 정리하자.

• 잘 짜여진 코드를 많이 읽고, 이해하고, 참고하자.
  • 내가 좋은 코드를 짤 수 있을 때 까지
• 코드 리뷰는 활발할수록 좋다.
  • 혼자 하나부터 열까지 짜는 코드는 정갈할 수 있다.
  • 코드 스타일이 다른 여러 개발자가 함께 작성하는 코드는 뒤엉키기 쉽다.