리팩토링 후기

• 처음부터 끝가지 변수명부터 시작해서 메소드 이름, 클래스 이름 그리고 불필요한 클래스를 감추거나 인스턴스화 시켜서 필요한 순간에만 사용하게끔 만들었다.
• 불필요한 상속으로 추상화 단계만 복잡하게 만들어져 있던 메인 로직을 단순화 시키고 수정하고, 코드 품질을 올리기 위해 부단히 노력했다.
• 아직은 필요 이상으로 덩치가 큰 클래스가 보이고, 비즈니스상 얽히고설켜 큰 흐름으로 따라가야만 로직의 큰 줄기를 파악할 수 있기 때문에 패키지로 분류하고, 클래스로 분류한뒤 클래스 두개를 합치거나, 추상화 수준을 맞추기 위해 정확한 한가지 책임을 지고 역활을 하는 클래스로 분리하기도 하고 있다.

처음 시작할땐 막막해 보이던게 리팩토링을 진행하면 할수록 확신이 든다. 소프트웨어는 살아 있다.

• 무슨 말이냐면, 관심도 주지않고 동작하니까 넌 됐어. 정도의 애정을 가지고 있으면, 그 코드는 죽은 코드다.
• 리팩토링을 마음먹고 내가 봐도 흐뭇한 코드가 될때까지 닦고 조이고 기름치다 보니 input이 들어오면 output을 내는 한낱 소프트웨어일 뿐이지만 티코가 무리하게 속도를 내는 소프트웨어가 아니라 소나타 정도 되는 중형 세단이 마음먹고 속도를 내는 느낌이다.
• 구조는 착 잡혀 있으며, 한눈에 보기도 쉽게 분류를 잘 진행했고, 실제로 해당 코드를 처음보는 사람에게도 검수를 받아봤다.
• 이제 소나타가 아니라 벤틀리로 변신할 차례다.

벤틀리 소프트웨어를 만들기 위해서는?

• 음… 아직도 고심하고 있는 부분인데, 지금 갓 클래스를 분류하고 인스턴스화 할수 있는 객체로 분리하면서 Dependency Injection에 많은 신경을 썼다.
• 어떤 특정한 일을 하는 클래스를 인스턴스화 할때 필요한 변수들을 주입받고 그때 자기 역할만 수행하고 가비지 컬렉터에게 수집을 당해버리는 클래스 말이다.
• 이걸 왜 하냐면… 처음부터 테스트 코드가 같이 작성된 소프트웨어가 아니다 보니, 테스트 코드를 작성하고 싶어도 작성할 수 없는 수준의 소프트웨어였다.
• DI에 신경을 쓰면, 테스트 가능한 클래스들이 많아질 것이고, 이걸 바탕으로 자동화 테스트를 작성하려고 계획중이기 때문이다.
• 벤틀리가 소프트웨어 그 자체라면… 테스트 코드는 벤틀리가 잘 달릴 수 있는 도로 쯤으로 생각하면 될까?

Thanks to 객체 관련 책들!