안녕하세요. 그동안 사이드 프로젝트가 꽤 많이 진행되었습니다.

핵심 로직을 만들었고, 커맨드라인에서 실행할 수 있는 정도까지 구현을 끝냈습니다.

쓸만할 정도가 되려면 아직 멀었지만, 핵심 로직을 만들면서 했던 경험과 느낀 점을 적어봤습니다.

도메인 지식만으로는 부족하다

• 도메인을 코드로 구현하는 것은 이 프로젝트를 통해 얻고자 한 큰 목표였습니다.
• 프로젝트 도메인인 음악 도메인을 잘 알고 있다고 여겼기 때문에 프로젝트 진행이 수월하지 않을까 생각했지만, 그렇지 않았습니다. 도메인 지식을 코드로 옮기는 건 도메인을 아는 것과는 다른 문제였습니다.
• 도메인 지식을 코드로 옮기려고 할 때, 어떤 문법을 써서 어떤 설계로 도메인 모델을 만들지가 잘 떠오르지 않았거든요. 도메인 지식뿐만 아니라 언어를 어떻게 이용할지도 잘 알아야했고, 그러려면 구현에 쓰는 프로그래밍 언어를 잘 알아야했습니다.

처음부터 완벽할 필요는 없다

• 좀처럼 프로젝트가 진행되지 않다보니, 고민만 하면서 시간이 지체되었습니다.
• 깔끔하게 만들고 다음 할 일로 넘어가고 싶었던 것 같습니다. 하지만 처음부터 완벽한 코드를 짜려고 하면 넘어갈 수 없다는 걸 인정해야 했습니다.
• 일단은 어떻게든 도메인 모델에서 제공해야 할 핵심 로직을 구현하고 나중에 더 깔끔하게 고치기로 결정했고, 다소 복잡해지긴 했지만, 결국에는 구현하고자 했던 로직을 만들었습니다.

적당히는 깔끔해야한다

• 만들어낸 코드는 비록 동작하긴 했지만, 이해하기 어려운 코드가 되어버렸습니다.
• 기존에 만들어놓은 코드를 가지고 작업을 이어나가는 게 점점 어려워졌습니다. 기존 코드의 구조가 제대로 이해가지 않으니까 다른 기능을 만들려고 할 때 기존 코드를 어떻게 쓸지 알기가 힘들었습니다.
• 참고할만한 내용이 있을 것 같은 책을 알아봤고, 마틴 파울러의 <리팩토링>을 읽고 여러가지 리팩토링 기법을 적용했습니다. 리팩토링은 겪고 있던 문제를 상당히 완화해주었습니다.

• 가장 도움받았던 건 '이름 바꾸기'입니다. 기존에 이름 붙였던 클래스, 메서드, 필드 등 요소의 이름이 적절한지 생각해보고 다듬었습니다.
• 처음 이름붙일 당시에는 몰랐는데, 다시 살펴보니 그 요소가 가진 역할을 잘 드러내지 못하는 경우가 자주 있었습니다.
• 적절한 이름인지 생각해보면서, 그 요소가 쓰이는 주변 환경의 관점에서도 바라볼 수 있었습니다. 예를 들어 지금의 메서드명이 적절한지 따져볼 때, 그 메서드가 속한 클래스를 살펴보는 것처럼요.
• 목적이 잘 드러나는 이름으로 바꾸고 나니까 다음으로 개선해야 할 점도 좀 더 수월하게 알 수 있었습니다.

균형을 잡자

• 리팩토링했다고 해서 코드가 완벽해졌다고 볼 수는 없었습니다. 더 괜찮게 만들 수 있는 여지가 남아있겠죠.
• 하지만 코드를 다듬다보니 이 정도면 다른 작업을 하는 데 문제가 없겠다 싶은 정도가 되는 시점이 있었습니다.
• 계속해서 리팩토링만 할 수는 없었습니다. 구현해야 할 것들이 아직 한참 남아있기 때문입니다.
• 구현을 방해하지 않는 정도로 마무리하고, 추가로 해야 할 사항이 있다면 기록해놓고 다음에 적용할 수 있도록 하는 게 일정 관리에 낫다고 느꼈습니다.