세이자바

어떤 프로젝트를 초반, 아키텍처나 프레임워크를 설계 시점에 목소리를 크게 내어 설계를 주도하면 이후 개발단계의 중반을 넘어가는 이후부터, 혹은 유지보수하면서 자신이 영향을 주었던 설계방식에 대해 후회를 하는 경우가 항상 있다.

• 왜 이렇게 번거롭게 단계를 많이 두었을까?
• 왜 이 메소드를 바로 부르도록 했을까?
• 이걸 왜 인터페이스로 분리를 안해두었을까?
• ...

스스로도 고민될 때가 많이 있고 다른 개발자들이 대놓고 뭐라고할 때도 있고..
이상한 것 알면서도 어찌할 수가 없을 때가 참 많았던 것 같다.

그런데 리팩토링을 보면 다음과 같은 글이 있다

시스템이 변할수록 얼마나 숨겨야 하는지에 대한 원칙 또한 바뀐다. 여섯 달 전에는 잘된 것 같았던 캡슐화가 지금 와서는 서툴러 보일지도 모른다. 리팩토링은 여러분이 미리 예상하지 못했던 것에 대해 미안하다고 말할 필요가 없이, 그냥 지금 고치면 된다는 것을 의미한다.(p.191)

물론 지금 바로 고친다는 것이 그다지 간단한 일은 아니지만 테스트를 좀 더 효율적으로 작성하면 그렇게 어려울 것 같지도 않다.
단 자신감과 용기가 있어야 하는 것.

정말 그렇게 고치지 못할지라도 위안으로 삼을 수 있는 구절이다.