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

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

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

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

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

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

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

적당히는 깔끔해야한다

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

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

균형을 잡자

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

요즘 사이드 프로젝트로 만들고 있는 프로그램을 소개해보려고 합니다.

어떤 프로그램을 만드는지

• '텍스트 파일에 적은 코드를 원하는 키로 전조해주는 프로그램'을 만들고 있습니다. 부연설명을 좀 더 해보자면..
• 기타치는 걸 좋아해서 가끔씩 괜찮은 노래를 커버합니다. 타브나 종이 악보도 있지만, 텍스트 파일에 적는 걸 선호합니다. 빠르게 만들 수 있어서요. 코드를 따고, 텍스트 파일에 가사와 함께 적습니다.

하지만 번거로울 때도 있습니다. 카피한 곡의 음역이 부르기에 너무 높거나 낮으면 저한테 맞도록 전조해주는 작업이 필요한데, 그러려면 적었던 모든 코드를 일일이 바꿔야 하거든요.

만들고 있는 프로그램은 이런 작업을 편하게 해줍니다.

만드는 이유, 그리고 프로젝트를 통해 얻고자 하는 것

• 그간 경험했던 프로젝트에서 짰던 코드를 되돌아보면 정말 만족스러웠던 적은 없었던 것 같습니다. 프로젝트를 진행할수록 점점 손댈 수 없이 코드가 복잡해지는 경험을 몇 번 하면서, 어떻게 하면 더 괜찮은 코드를 짤 수 있을지를 고민했습니다. 생각해본 개선 방안 중 하나는 객체지향을 더 잘 이해하는 것이었습니다.
• 이런 노력의 일환으로 객체지향의 사실과 오해라는 조영호 님의 책을 읽었습니다.

책에서 이야기하는 바, 즉 프로그램과 연관된 도메인을 잘 이해하고, 역할, 책임, 협력 관계가 잘 드러난 객체 관계를 잘 만드는 데 익숙해지려면, 실제로 어떤 도메인에 대한 프로그램을 만들어보면서 책에 나온 내용을 적용하는 것이 좋을 것 같았습니다. 직접 만드는 경험을 통해 얻을 수 있는 것이 크다고 생각하거든요. 그래서 만들어보기로 했습니다.

주제 선정 기준

• 실제로 쓸 프로그램인가?

전에도 실제로 필요해서 프로그램을 만든 적이 있었는데, 여러 장점이 있었습니다. 프로그램을 어떻게 만들지 기준이 명확해졌고, 만들고 나서도 자주 쓰면서 불편한 점을 개선하게 되어 자연스럽게 프로그램 구조를 다듬을 수 있었거든요.

• 내가 잘 아는 도메인인가?

도메인을 잘 알면 그 도메인을 코드로 바꾸는 것도 수월할 거라고 생각했습니다. 제가 잘 알고있는 도메인과 관련된 프로그램을 만들면, 그 도메인을 이해하는 데 드는 노력을 줄여서 구현하는 데 더 집중할 수 있을 것 같았습니다. 만들고 있는 프로그램은 음악 도메인과 연관되어 있는데요, 음악 이론을 알고 있기도 해서 프로젝트 진행이 수월할 것으로 예상했습니다.

진행 상황

• 첫 목표는 코드 하나를 주어진 키에 맞게 전조하는 핵심 로직을 구현하는 것이었고, 미진하나마 완료한 상태입니다.
• 다음 목표는 CLI 기반으로 텍스트 포맷 악보 파일을 가져와서 코드를 전조할 수 있도록 만드는 겁니다.
• 혼자서 하다 보니 막힐 때가 많아서 더디게 진행하고 있지만, 그만큼 배우는 것도 많은 것 같습니다. 더 진척되면 또 공유해보겠습니다ㅎㅎ