TIL (2022.02.23)

DAY 10

🔖 오늘 읽은 범위 : 14장, 점진적인 개선

😃 책에서 기억하고 싶은 내용을 써보세요.

• ArgsException을 독자적인 모듈로 만들면 Args 모듈에서 잡다한 오류 지원 코드를 옮겨올 수 있다. ArgsException 모듈은 잡다한 오류 지원 코드가 들어갈 합당하고 당연한 장소다. 덕택에 Args 모듈이 깨끗해져 차후 확장도 쉬워진다.
• 소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다. 적절한 장소를 만들어 코드만 분리해도 설계가 좋아진다. 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 더 쉬워진다.
• 특별히 눈여겨볼 코드는 ArgsException의 errorMessage 메서드다. (Args 클래스에 속했던) 이 메서드는 명백히 SRP(Single Responsibility Principle) 위반이었다. Args 클래스가 오류 메시지 형식까지 책임졌기 때문이다. Args 클래스는 인수를 처리하는 클래스지 오류 메시지 형식을 처리하는 클래스가 아니기 때문이다.
• 하지만 그렇다고 ArgsException 클래스가 오류 메시지 형식을 처리해야 옳을까? 솔직하게 말해, 이것은 절충안이다. ArgsException에게 맡겨서는 안 된다고 생각하는 독자라면 새로운 클래스가 필요하다. 하지만 미리 깔끔하게 만들어진 오류 메시지로 얻는 장점은 무시하기 어렵다.
• 결론
  • 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다.
  • 나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다.
  • 물론 나쁜 코드도 깨끗한 코드로 개선할 수 있다. 하지만 비용이 엄청나게 많이 든다.

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 오늘은 코드 양이 너무 많아 다 이해하기는 어려웠다.😅 그래도 오늘 리펙터링의 핵심은 오류 코드를 분리하는 작업이라고 생각한다. 오류 처리의 책임을 ArgsException 코드에게 위임하면서, 이전 코드보다 확실히 명확해졌음을 느낄 수 있었다. 그리고 마지막에 errorMessage 메서드의 위치에 대해서는 나도 항상 고민하던 부분인데 정답은 없는 것 같다. 나는 메시지 출력을 처리하는 독자적인 클래스가 필요하다고 생각해 Printer 클래스를 만들어 처리한 적이 있다.
• 그동안 방대하고 느린 개선 과정을 눈으로 따라가보았다. 코드를 100% 이해했다고 볼 수는 없지만 적어도 어떻게 바꿔야하고, 이렇게 바꿨을 때 어떤 효과를 얻을 수 있는 지 감이 생긴 것 같다. 내 코드를 직접 리펙터링 해보면 훨씬 효과를 체감할 수 있을 것 같다.

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 없음

소감 3줄 요약

• 소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다.
• 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다.
• 나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다.