[우테코 7기 프리코스 4주 차] 회고

 

 

 

GitHub - m-a-king/java-convenience-store-7-m-a-king

 

---

 

5F 회고

 

5F 회고

 

사실 (Facts)

 

마지막 주차의 미션은 그동안 배운 모든 개념을 종합적으로 적용해보는 자리였다. 하지만 개인적인 사정으로 충분한 시간을 투자하지 못해 동작하는 코드를 만드는 데 집중할 수밖에 없었다. 다소 복잡한 비즈니스 요구사항은 모두 해결했지만, 설계 측면에서 한계를 느꼈다. 도메인이 데이터 클래스처럼 사용되며 대부분의 로직이 서비스 클래스에 집중되는 점이 대표적인 문제였다. 또, 재고 관리 기능을 Product 클래스에서 분리해 repository 계층의 map으로 관리하면서, 도메인이 주도적으로 동작하는 설계를 적용하기가 더욱 어려웠다.

결과적으로 예제 케이스는 모두 통과하고 프로그램은 정상적으로 동작했지만, 코드의 유지보수성과 객체지향적인 구조의 아름다움이 부족했다는 점에서 아쉬움이 남는다.

 

 

감정 (Feelings)

 

모든 테스트를 통과하고 요구사항을 성공적으로 해결했다는 성취감과 안도감이 있었다. 하지만 설계에 더 신경 쓸 시간이 있었다면 결과물을 한층 더 개선할 수 있었을 것 같아 아쉬움이 남는다. 특히, 구현 중에도 코드의 부족함을 느꼈기에 결과물을 마주했을 때 그 점이 더 크게 다가왔다.

 

 

발견 (Findings)

 

트랜잭션 스크립트 패턴은 단기적으로는 개발 속도를 높일 수 있지만, 장기적으로는 유지보수성과 확장성에서 한계를 드러낼 수 있다는 점을 체감했다. 또한, 초기 설계 단계에서 책임을 도메인으로 점진적으로 옮겨두지 않으면, 리팩토링 시 큰 부담으로 다가올 수 있다는 점을 배웠다. 실제로 리팩토링을 시도했지만, 기존 구조에서 도메인 중심으로 전환하기가 생각만큼 쉽지 않았던 경험이 이를 뒷받침한다.

 

 

향후 행동 (Future Actions)

 

도메인 객체에게 명확한 책임을 부여하는 설계 역량을 강화하겠다. 초기 설계 단계에서 요구사항을 분석하며, 도메인으로 넘길 수 있는 책임들을 정의하고 이를 반영하는 습관을 들이겠다. 이를 통해, 리팩토링 과정에서 막막함을 줄이고, 객체지향적인 구조를 더 자연스럽게 적용할 수 있는 기반을 마련할 것이다. 또한, 설계와 구현 사이의 균형을 맞추기 위해 TDD 방식을 더욱 적극적으로 활용하겠다.

 

 

피드백 (Feedback)

 

코드 리뷰에서는 다양한 의견을 받을 수 있었고, 그중 특히 도메인 객체가 데이터를 옮기기만 하는 역할에 그쳐 DTO와 다를 바 없어 보인다는 지적이 기억에 남았다. DTO로 쓰이고 있던 객체를 억지로 도메인 객체로 변경했던 것이라서 정확히 들킨 기분. 또한, 필드가 과도하게 많아 해당 객체가 어떤 역할을 하는지 명확하지 않다는 피드백도 있었다. 결과적으로, 도메인이 데이터를 담기만 하고 로직을 포함하지 않아 객체 지향의 기본 원칙을 충족하지 못했다는 점에서 개선이 필요하다는 의견이 많았다. 나 역시 이 점에 동의하며, 다른 코드들을 리뷰하며 얻은 인사이트를 바탕으로 다시 구현해보고 싶다.