오늘은 이번주에 팀 프로젝트를 하며 했던것에 대하여 적어보려 한다.

우선, 우리 팀은 과제 중 기초 사항만 구현하기로 하였고 학습과 경험에 중점을 두는 방향으로 진행을 하였다.

그래서 내가 택한 것은 DDD와 Presentation Layer였다.
이전 글에서도 작성 하였지만, 이 둘을 택한 이유는 개발자 간의 협업에서도 이점을 발휘할 수 있는 구조라 보였기 때문이다.
실제 코드를 작성하며 업무 분담을 도메인 별로 하니 매우 편안했다.

Why?

각자 도메인을 다 만든 이후 api service에서 조립하니 끝이고, 각자 영향을 끼치지 않아 정말 코드 작성에 큰 무리가 없었다.
대신, 나의 경우 댓글을 만들게 되었는데 댓글의 경우 Post에 종속적이기 때문에 어느정도 영향이 있어 이 영향을 어떻게 최소화 할지에 대한 고민을 많이 했던 것 같다.
그래서 처음에는 DB에 PostType과 PostId를 두고 받아오는 형태로 진행을 하려 했지만 정합성 문제 때문에 코드 단에서 분기를 나눠주는 형태로 변화가 필요하였는데, 그걸 또 다른 쪽에서 사용할 때 PostType과 Entity를 받게 되었는데 이렇게 되니 Entity를 알아야 한다는 점이 걸리기 시작하였고 그걸 또 몰라도 되게끔 만들고 싶다는 욕망이 꿈틀거려서 ENUM에 함수를 담아 ANY 타입으로 entity를 따오고 IS문법으로 처리하는 형태도 생각해보았는데 이렇게 되면 또 Post 기능을 제공하는 Domain이 있고, 댓글이 달려야 하는 상황이라면 ENUM이 거대해지고, DomainService 로직과는 또 분리가 되고, ANY 타입 자체에 대한 문제점이 산제해 있어 코드가 점차 더러워 지기 시작하였다.
그래서 아, 이건 아닌 것 같다라는 판단으로 다시 PostType과 PostId를 DB에 넣는 형태로 바꾸게 되었다.

이후 Permission체크를 Service로직에 넣어도 되는가? 라는 생각과 Filter를 사용할 떄 kotlin에서 어디까지 뻘짓이 가능한가와 함수형 언어를 좀 더 사용해보자라는 여러가지 생각들이 합쳐져 뻘짓의 시작을 알리었다.

원래는 React의 useState의 멀티 쓰레드 기반으로 작동 시키기라는 생각으로 진행하였으며, 대신 React의 useState와는 다르게 Type을 기반으로 값이 저장되고, 아무 쓰레드에서나 그 값에 대한 접근을 하고, 수정이 가능토록 만들생각이었다. (사실 리엑트의 useState 훅처럼 함수의 caller를 따와서 각 함수마다 공유 가능한 값을 만들려고 하였지만.... 오버헤드가 너무 클 것 같다는 생각에 그만 두었다.)
이렇게 되면 이점은 Spring과는 완전 별개로 여러 값을 올리거나 가져와 쓸 수 있다.
그런데 Filter를 제작하여 넣으려 하니 어라...? 그냥 함수 만들어서 던져주면 끝 아닌가? 라는 생각으로 간단하게 먼저 만들어 보았다. 저 코드는 이후 나중에 따로 설계하여 테스트를 진행해보고, 실무에 적용 가능할지 안할지는 제쳐두고 어디까지 가능할지에 중점을 두고 한 번 만들어 볼 예정이다.
안할 가능성이 높다만... 신경쓸 부분이 좀 많다.

그리고 Filter를 만드는 도중에 어..? 이거 그냥 함수 만들어서 Filter에 넘겨주면 그 기능만 Filter가 가질 수 있지 않을까? 라는 생각으로 함수를 만들어 넘겨보니 잘 작동되었다.

이후 코드를 보니 Filter에는 말 그대로 Filter가 걸리는 제한 사항만 작성 되있으니 보기 편하기도 하였다.
다만 유지보수 측면에서 그 함수가 어디에 작성되어 있는지에 대하여 알아야 된다는 단점이 있어보이기도 하지만, Domain Package안에 config도 있으니 찾기 쉽지 않을까...? 라는 조심스러운 생각도 든다.

실제 Filter를 건 이후 DomainService에 당장 기초사항인 CRUD 코드와 로직만 있으니 코드 다이어트 측면에서는 매우 예쁘게 보이긴 했다.
다만, 이 과정에서 코드를 이제 전부 합치고 실행할 때 현재 개발이 덜된 것들과 문제가 되는 사항들이 매우 많았기 때문에 지금 뻘짓 할때가 아니라 생각되어 코드 수정을 우선시 하는 것으로 진행을 바꾸었다.

아아, 이것은 『협.업』이라는 것이다.

이 때 느낀것은 결국 각자 학습의 중점을 두고 진행을 하는 형식으로 하다보니 어떤 문제가 발생 했는지를 모르고 마땅히 따로 추가 구현사항에 대한 부분에서 너무 풀어지지 않았나가 약간 후회가 된다.

사실 프로젝트에서 가장 힘들었던 것은 다른 것도 아니고 업무를 할당 하였을 때 그것을 반영해주지 않고 진행했던 점에서 제대로 전달이 안된것인가? 아니면 뭔가 문제가 있는건가? 라는 생각도 들고 너무 이상을 쫓아 코드에 대한 강제성을 부여한 것이 문제가 되는 것인가? 하는 여러 생각들이 들어 이 부분에 대하여 많은 생각이 들었고, 조금 더 어떻게 협업 과정중에서 설득과 이야기에 대한 전달을 해야 할지 고민해볼 주제가 생긴 것 같다.
또한 Issue에 대한 이야기가 회의 과정에서만 나오다 보니 조금 더 이런 부분이 극대화 된것이 아닐까 생각도 든다.
이러한 점에서 조금 더 협업에 관한 툴을 좀더 다체롭게 사용하는 방법을 익혀야겠다는 생각이 많이 들었다.
또한 어느정도의 틀을 잡아놓고 계획성을 확실하게 이상과 현실에 대해서 잘 조절하는 방식을 익혀야 겠다는 생각이 가장 큰 것 같다.

너무 안좋은 이야기만 선두에 안좋은 사항들에 적어놓은 것 같지만 사실 협업을 진행하여 얻은 것도 많았다.

협업을 진행하다 보니 결국 다른 사람의 영향을 최대한 적게 받는 코드 작성법은 없을까? 어떻게 해야 이 코드를 장착시켜 최소한의 코드로 작동되게 만드는 것을 생각해보는게 매우 재미있었다.
코드를 대하는 관점 또한 여러가지가 존재하고 그것을 trade off를 잘 판단하며 작성해야 할 것 같다는 생각이 저절로 들었다.

이것 이외에도 코드적으로 여러가지 문제들이 있었는데 이 글에서 다루기에는 글이 너무 길어질 것 같아 글을 따로 빼서 작성하려 한다. 우선 날 가장 괴롭게 만들었던 JPA의 referenceColumnName.. 이것 만큼은 기록으로 남겨두어야한다.

결론 - 협업과 내가 생각한 여러가지 코드가 문제가 되는 부분들 또한 잡을 수 있어서 여러가지 생각해 볼 기회가 많이 생겨서 재밌었다!