생산적이지 못한 하루를 보냈다. 코딩하는 시간 대비 결과물이 적었다. 생산성이 떨어진 이유를 생각나는 대로 나열해 보자. 일단, 작업하는 도메인이 사용자였다. 사용자는 활용되는 곳이 많은 도메인이다. 즉, 변경이 일어나면 수정할 부분이 많다. 이것이 첫번째로 발목을 잡았다.
첫번째로 해야할 일은 도메인에 새로운 속성을 추가하는 것이었다. 새로운 속성 객체가 값 객체인지 엔티티인지 부터 설계상의 정리가 완벽하지 않은 상태로 시작했다(이것이 원인이었구나). 수정을 하고, 테스트 실행과정에서 컴파일을 하니 고칠 부분이 굉장히 많이 생겼다. 일단 되는 상태로 만들기 위한 작업을 했다. 그러다보니 명백한 안티패턴도 많이 사용하게 되었다. 일단 되게 만들고, 하나씩 각개격파를 하면 물론 된다. 하지만, 고민이 많은 상태에서 시작 했기 때문에, 머릿속이 금방 복잡해졌다. 통제하고 있다는 느낌이 전혀 들지 않았고, 옳게 만들기위해 한번에 생각해야 할 주제가 너무 많아졌다.
결국 모두 리셋하고, 처음 체크아웃한 상태로 되돌아왔다.(이건 잘못한 것 같다) 작업 계획을 세우고, 몇가지 할일들을 나열했다. 공통 도메인에 속성을 추가하는 것은 살짝 뒤로 미루어 두었다.
이번에는 인터페이스에 집중했다. 아키텍쳐의 계층별로 책임이 잘 분배되었는가를 신경썼다. 그 후에 말이 되는 이름으로 소통하고 있는가를 신경썼다. 돌아보면 걸린 시간에 비해 기록이 적은 것이 아쉽다. 시간을 아끼기 위해 시행착오에 대한 상세한 기록을 줄였는데, 결과는 시간도 오래걸렸고, 기록도 없다. 어차피 시간이 걸릴거라면, 어떤 이름이 왜 '더' 좋은지를 체계적으로 판단하기 위해 사례를 비교해 두는 편이 좋았을 것 같다.
사실, 체계적인 이름 평가가 중요하다는 것은 퇴근길에 클린 코드를 읽으면서 깨닫게 되었다. 어떤 이름이 왜 더 나쁜지에 대해서 잘 써 있었다. 부끄럽게도 이번에 클린 코드를 처음 읽었다. 고민을 많이 하고 읽으니 내용이 잘 와 닿았다. 다음 문장이 특히 기억에 남는다.
이름이 다르다면 의미도 달라야 한다
이름이 겹칠때, 컴파일을 위해서 의미없는 단어를 추가하는 식으로 이름지은 적이 많이 있었다. (e.g. user, userData) 오늘만해도 몇번은 겪은 일이다. 비슷해보이는 대상에 이름을 다르게 지었다면, 의미가 어떻게 다른지를 반드시 설명 할 수 있어야 한다.
이름을 짓는데는 공유시간이 큰 도움이 되었다. 말이 전혀 안되는 부분은 없는지, 흐름이 논리적으로 잘 이어지는지를 점검 받을 수 있었다. 보여준다는 생각만으로도 컴파일이 되는 설명글을 쓰고 있다는 생각이 들어서, 가독성에 더 신경 쓰게 되었다.
의식의 흐름을 따라서 글을 썼지만, 쓰고 보니 어려움을 겪었던 이유와 개선해야 할 점들을 알 수 있어서 좋다. 범위가 커지면, 어떻게든 통제할 수 있을 만큼으로 잘라야 한다는 것. 무엇이 왜 좋은지 분명하지 않다면, 적어서라도 분명하게 만든 후에 넘어가는 것이 낫다는 것. 코딩을 시작하기 전에 고민해야 할 부분은 대부분 확실하게 정리하고 와야 한다는 것(두뇌 과부하). 내가 겪고 있는 많은 문제들이 이미 책에 나와 있으므로 성실하게 간접경험을 쌓는 편이 좋다는 것.
