[우아한 남매들] KPT 회고

?? 죄송하지만 우아한 형제들 아니고요,, 우린 남매들입니당... 착각하여 들어오신 분은 죄송하게 되었습니다.. ㅎㅎ

배달의 만족?

대표 배달 서비스인 '배달의 민족'을 레퍼런스하여 Java로 구현해보자! 하여 진행하게 된 프로젝트입니다

며칠간 팀원들과 재밌게 그리고 열정적으로 참여하게 되어 한 번 짧은 프로젝트였지만 회고를 진행해볼까 합니다!!

회고는 KPT로 우리 팀이 잘한 점, 잘 못한 점, 고쳐야 할 점을 회고해 볼 것이다.

Keep

• 탄탄한 기획: 이전에 한 KPT 회고에서 기획을 탄탄히 못한 점을 아쉬워했었는데, 그걸 발판삼아 이번 프로젝트에서는 탄탄한 기획을 먼저 팀원들과 충분히 진행하고 개발에 들어갔다.
  또한, 개발 도중 의문점이 생기면 주저없이 다른 팀원들에게 공유하여 문제를 바로바로 해결한 점이 가장 발전한 점이라고 생각한다.

• 디자인 패턴의 사용: 우리는 여러가지 디자인 패턴을 우리의 프로젝트에 녹여냈다. 대표적으로 MVC 패턴, Singleton 패턴, 중재자 패턴을 사용하였다. 특히, 소연님께서 데이터 동기화 문제를 짚어주셨고, 내가 싱글톤 패턴으로 해당 솔루션이 생각난 점이 딱 맞아떨어졌다고 생각된다!

• 클린코드의 지향: 우리 팀만의 클린코드란 무엇인가를 먼저 정의하고 개발에 들어섰기에 클린코드를 생각하면서 개발할 수 있는 동기가 되었다.
  심지어 우리 팀 PM님께서 클린코드에 집착하는 면모가 있어 살짜쿵 아니 이것까지...?라는 생각이 들기까지 했당...ㅎㅎ

• 객체지향 개발 원리: 우리 팀원들이 다들 SOLID에 진심이어서 밥 마틴 아저씨를 생각하며 solid를 꼭꼭 지키고자 기획에 임했다..
  특히 SRP를 지키기 위하여 이런 저런 예시를 들어가며, 이 상황에서는 SRP가 지켜지는 것인가? 지켜지지 않는 것인가?를 오...래 토론한 것이 새록새록 기억난다...

Problem

문제는 없다 는 설마....고 일단 !!

• 테스트 코드의 부재: 구현 기간이 짧아 테스트보다는 구현에만 치중하였기에 테스트코드를 작성하지 않아, 개발된 것을 확인하면서 개발할 수 없었다.

• 분리되지 않은 진입점 클래스: Main 클래스를 MVC로 나누지 않아서 진입점에 대한 경계가 모호해졌다.

  • 처음 진입점1: View ⇒ 서비스 시작 시, 일단 비회원 화면을 보여준다. 그 후에 사용자의 선택에 따라 적절한 Controller로 분기가 넘어간다.(이 경우, View가 Controller를 부르는 방식으로 설계된다.)
    그 후 호출된 Controller에서는 유저 요청에 따라 적절한Model을 가져오고 View를 보여준다.(Controller ⇒View, Service 호출)
    
  • 처음 진입점2: Controller ⇒ Main에서 분기 로직을 컨트롤러로 생각해야한다. 마치 api요청에 대한 응답?

• Controller의 역할 혼동: Controller에서 여러 개의 Service를 접근하여 사용하면서 Controller 단에도 로직이 생겨버렸다.

Try

Problem을 해결하기 위해서는....?

• 테스트 코드를 작성하여 코드를 검증하는 절차를 추가한다.

• 인터페이스를 미리 설계해서 개발 시간을 단축하고, 변경에 유리한 유연한 설계를 하고, 유지보수성을 강화한다.

• Main을 Controller와 View로 분리하여 진입점을 Controller로 설정한다.

• Service에서 다른 도메인의 Service에 접근하거나 Service에서 다른 도메인의 DAO에 접근하여 Controller의 로직을 삭제한다.