클린코드는 없다.

늘 고민이었다.
어딘가 소스가 깨끗하지 못하다는 인상을 받았다.
만족스럽지 못한 우리네업무코드를 보다 만족스럽고 바람직한 코드로 리팩터링하고싶었다.
많이 고민됐고, 의심스러웠고, 그리고 믿어왔다.
1. 코드가 지나치게 절자치향적이었다.
2. 익셉션에 대해 생각하기 어려웠다.
3. 형상관리에 어려움이 있었다.
4. 장애가 발생해도 적절히 대응하기 어려웠다.
5. 코드에 비즈니스(도메인)이 제대로 들어나지 않은 느낌을 받았다.
6. 네이밍에 대해 생각하기 어려웠다.
무엇보다도 변경에 어려움이 있다는 느낌을 받았고, 대부분이 그렇게 생각한다.
사실 다들 어느정도 알고있다. 스파게티코드란 단어를 실무에 써본적도 들어본적도 없지만
그게 뭔지 다들 알고있다.

나는 이문제를 OOP와 DDD가 해결해 줄 것이라는 오랜믿음을 가지고 공부하고 적용해보려했다.
결론부터 말하자면 실패했다.

DDD cqrs를 공부하면서 우리네업무코드를 한층더 객관적으로 볼 수 있게 되었다.
대부분의 업무코드들이 조회용코드였고, 그것들이 OOP와 DDD에 fit하지 않다는 사실을 알게되었다.
왜냐하면 DDD는 R를 뺀 CUD에 fit한 컨셉이지 read를 위한 컨셉이 아닌것이다.

허탈했다.
다시 원점으로 돌아간 기분이다.

물론 허탈함과 동시에 뿌듯하기도 했다.(사실 이게 더 크다)
아 내 개발인생은 지금부터가 시작이구나.
무지개넘어를 쫓는짓은 그만하고 팀원과의 커뮤니케이션/컨벤션/테스트 등등 기본에 충실해야겠구나 싶었다.

물론 여태 공부한것들이 헛수고인것도 아니다.
생각보다 나는 OOP에 대해 더잘 이해할수있게 되었고, DDD의 컨셉이나 msa의 필요성, JPA의 필요성도 잘알게되었다.
단지 그것들이 우리네업무코드와는 fit하지 않다는 것빼고는...
특이 OOP가 말하는 메시지는, 절대로 어려워서는 안된다. 단순해야하고 쉽게 공감이 가야한다.
적용이 하기 어려웠던 이유가 내가 oop컨셉을 잘 이해하지 못해서라고 생각햇었는데 사실은 그게 아닌것이다.

결론은
클린코드는 없다. 하지만 수렴해야한다.
끝.