NBCamp Java 5th: Chapter 4 OutSourcing Project KPT 회고

팀프로젝트가 시작됐다.

나는 리더를 모르고 신청을안했다. 사실 할까말까 고민하다가 안했다. 근데 우리팀에는 리더가 없다.

할껄 그랬다. 나는 리더하고싶은 사람이 없을때 뽑기보다는 내가 자처해서한다. 그래서 나는 리더가 됐다.

 

프로젝트를 하며 돌아보니, 내가 리더이긴 하지만 모든 팀원분들이 잘 도와주셔서 모두가 리더였다.

우리 팀원분들은 회의시간에 마이크와 캠을키며 소통을 잘 했다. ( 6/19~6/25)

 

팀프로젝트 이름은 아웃소싱 프로젝트이며, 프론트는 구현하지않고 포스트맨으로 간단하게 한다.

crud가 기본이며, 최종프로젝트 전 한번 더 하는 느낌이다.

주제는 총 3개가있었으며 1. sns만들기 2. 배달주문 사이트 만들기 3. 익명커뮤니티 만들기 

우리는 2번 배달주문 사이트로 했다.

 

개발전 api 명세와 erd를 작성했다.

 

api 엄청 많다 ;;

api

erd다 엄청많다

erd

우리팀의 기능 구현

 나는 네이버 소셜 로그인을 도전 해봤지만, 거의 다 된거같지만

기간내에는 하지 못했다.. 추후에 혼자서 해볼 예정이다 ㅠ

 

Ground Rules와 Goals이다.

 

코드 컨벤션이다.

Github Rules이다.

 

튜터님의 중간 피드백

api 명세 잘해주셨어요.
- url 설계시 복수와 단수를 혼용하는 것은 지양하는게 좋아요.
- profile은 users와 연관이 있으니 url을 users/profile로 작성하는게 좋겠네요.
- json 배열은 [ {el1, el2}, {el1, el2} ] 형태에요.

main entity분류와 관계를 잘 맺으셨어요.
- follow pk 논리명이 store pk 논리명과 겹치네요
- domain size는 최대값을 예상하여 산정해보세요.
- create_at과 update_at는 데이터 생성,변경 시점을 추적하기 위한 컬럼이에요. 부착하지 않는 곳은 용도에 맞게 부착해보세요.
- 컬럼의 순서는 중요도에 따라 배치하고 공통되는 컬럼에 위치는 동일하게 맞춰줘야 가독성이 높아져요.

기능과 도메인 단위로 적절하게 잘 나누셨네요. 자신의 맡은 파트는 물론 다른 팀원의 파트에 관심을 가지고 협력해보시기 바랍니다.
자신이 맡은 도메인 혹은 기능을 구현할때 다른 도메인 메소드 등이 필요하다면 해당 파트를 맡은 팀원분에게 필요한 부분을 요청해보거나 조율해보세요.

스코프를 산정할 때에는 탑다운 방식으로 전체 구현 일정, 테스트 일정을 정한 후 기능 단위로 task를 분리해보세요.
분리한 task에 소요시간을 예측해보고 주어진 기간 내에 구현 가능한 부분까지를 스코프로 산정합니다.
프로젝트 일정은 개인 task를 todo-doing-done으로 나눈 후 시작일시, 종료일시를 예측하여 스스로 일정을 관리하며 팀원 모두가 볼 수 있게 tool을 사용하여 관리해 보세요. 현재는 예측한 시간이 정확하지 않을 수 있어요. 하지만 시간을 정하고 업무에 임하는 습관을 만들어보세요.

 

팀원분들의 한줄평 

 

튜터님의 최종 피드백

14조 팀원 여러분들 모두 수고 많으셨습니다.
작성하시는 문서와 컨벤션 등을 준수하시는 모습만 보아도 단합이 잘되셨다는걸 느낄 수 있었어요.
계획표(일정관리), 회의내용(회의록)도 작성하시면서 프로젝트를 성공적으로 이끌기 위해 노력하신 모든 점들이 좋았어요. 다음 프로젝트에서는 더 발전된 방향을 적용해보시길 바래요.
고민하셨던 여러 메뉴를 포함한 단건 주문은 entity 설계를 변경하시면서 잘 해결하셨네요. 결국 entity를 설계하는 것은 시스템이 비즈니스를 수용할 수 있는지를 결정하는 주요 요소 중에 하나임을 배우셨다면 좋은 경험이 되었을거라 생각합니다. 다:다 문제를 해결하는 법도 익히시게 되었네요.시연 영상은 음성과 텍스트가 없고 정상적인 케이스 일부만 보여져서 조금 아쉬웠지만 수고 많으셨어요.** [고려해보세요]에 언급하지 않은건 대부분 잘하신거에요. 오해하지마세요.[좋아요]
- 규칙성 있는 주석 좋아요.
- 패키지 구조가 규칙성있게 개선되었네요. 도메인형 패키지 구조로 프로젝트를 구성하였을 때는 entity별로 도메인을 나누는 것이 아닌 유사한 entity별로 aggregate(군집)을 짓는 것을 원칙으로 해요. 군집된 entity들 간에 협력으로 해당 도메인에 비즈니스를 처리하고 외부 도메인 협력이 필요할 시 interface를 통해 조합해보시기 바래요.
- TimeStamp에 @PrePersist를 의도에 맞게 잘사용하셨네요. 위와 같이 entity에 persist 전후, update 전후 등과 같이 영속성을 관리할 수 있는 기능이 있으니 잘 활용해보세요.
- 구체적인 예외처리 좋아요. 여기서 추가하자면 예외 발생은 custom exception 외에도 정의되어 있는 checked, uncheched exception들이 참 많아요. 정의되지 않은 예외도 일관성 있게 핸들링 할 수 있도록 추가 작성해보세요. 또한 현재 설계로는 예외처리 객체가 없이 status만으로 client에서 예외임을 구별해야하기 때문에 statusCode를 잘 정리해보시길 바래요.
- entity에 제약조건과 같은 구제적인 ddl 설정을 잘해주셨고 테이블명도 _table로 일관성있게 잚 만드셨어요. fetchType도 잘 정하셨네요.
- 일관성 있는 Controller 구현 좋았어요.[고려해보세요]
-  오래된 익숙한 팀이 아닌 경우 코드컨벤션을 맞추는 것은 참 어려운 일이에요. 하지만 동일 개발자가 작성한 코드가 일관성이 없다면 가독성, 신뢰성면에서 좋지 않고 무엇보다 개인의 구현 습관을 만드는데 저해요소가 되요. 젓가락질 잘한다고 밥 잘먹는거 아니지만 우린 프로가 되야하는 사람이기 때문에 이점도 고려해보시길 바래요.
-  controller layer에서 transactional을 다루 것은 좋지 않아요. controller는 api를 관리하는 영역이기에 비즈니스를 만다는 service layer에서 transactional을 처리해보세요.
- controller에 global mapping 정보가 규칙적이지 못한 경우도 있네요. 추적성이 떨어질 수 있으니 유의해 보시길 바래요.
- Config 파일에 이미 UserAuth로 선언된 상수가 magic number로 작성되어 있는게 있네요. Magic number에 경우 되도록 상수로 관리할 필요가 있어요.
- Security filter에 예외처리에 대해서도 고려해보세요. Security에 경우 대부분 예외 발생 시 기본 설정으로 response하게 되어 있어요. EntryPoint, AccessHandler 등을 활용하여 filter 예외처리도 고려해보세요.
- 객체는 단일을 보장받으며 복수의 형태를 가질 수 없기 때문에 collection과 array를 사용하게 됩니다. OrderMenuList란 객체 명명은 적합하지 않겠네요.
- stream은 생각보다 비용이 많이 드는 연산입니다. 남용해서는 안되며 사용 시 필요한 연산을 모두 수행하는게 좋습니다.
AdminFollowService.findFollowerList와 같이 list 형태로 반환 받은 결과를 다시 list로 만들 필요는 없겠네요.
- AdminFollowService.ffindStoreAllFollower에 loop를 도면서 user 유무를 판별하는 로직은 불필요한 db connection resource 사용으로 보이네요.
- Entity에 상태와 같은 Enum은 확장성을 위해서나 식별성을 위해서나 추상적인 것이 아니라 구체적인 것이 좋아요. Process -> OrderProcess || OrderStatus
- try-catch 시 구체적인 exception으로 예외를 처리는게 가장 중요하지만 그 이외의 예외가 발생했을 때 try 후 catch하기 때문에 예상 외 exception도 처리하기 위한 코드를 작성해주어야해요.

 

 

KPT 회고

Keep - 현재 만족하고 있는 부분

• 코드 컨벤션과 깃허브 룰스, 이슈 및 PR 템플릿을 미리 정하고 지켜서 사용함
• PR시 리뷰 작성하여 코드 개선 및 확인
• 규칙성 있는 주석 작성
• Git issue랑 project를 사용해서 개발 진행과정을 보는데 좋았다.
• 구체적인 예외처리
• 규칙성 있는 패키지 구조 구성
• TimeStamp에 @PrePersist를 의도에 맞게 잘 사용함
• entity에 제약조건과 같은 구체적인 ddl 설정을 잘했고 테이블명도 _table로 일관성있게 잘 만들었으며, 적절한 fetchType 지정
• 일관성 있는 Controller의 구현
• 팀원 간의 원활한 소통과 협업🙂
• 주말에도 코딩하는 열정적인 모습
• 욕심내서 최대한 많은 기능을 구현해보고자 하는 것
• 잘하는 팀원들을 보고 동기부여를 받을 수 있어서 좋았다.

Problem - 불편하게 느끼는 부분

• 예외 발생 : custom exception 외에도 정의되어 있는 checked, uncheched exception이 많다
  • 정의되지 않은 예외도 일관성 있게 핸들링 할 수 있도록 하면 좋을 것 같다. 또한 현재 설계로는 예외처리 객체가 없이 status만으로 client에서 예외임을 구별해야하기 때문에 statusCode를 잘 정리하면 좋을 것 같다.
• 코드컨벤션
  • 동일 개발자가 작성한 코드가 일관성이 없다면 가독성, 신뢰성면에서 좋지 않고 무엇보다 개인의 구현 습관을 만드는데 저해요소가 된다.
• Config 파일에 이미 UserAuth로 선언된 상수가 magic number로 작성하였는데 상수로 관리해야 할 필요성 느낌.
• OrderMenuList란 객체 명언 적합하지 않음
  • 객체는 단일을 보장받으며 복수의 형태를 가질 수 없기 때문에 collection과 array를 사용하게 된다.
• stream을 남용하지 말고 사용 시 필요한 연산을 모두 수행하도록 할 것
• 프로젝트 시작 전 세부적인 일정 작성과 마감 기한을 작성하지 않은 것이 아쉬웠습니다.
• 테스트 코드를 작성하지 못한 것
• 휴일에 시간투자를 더 못한것이 아쉬웠다.

Try - Problem에 대한 해결책, 당장 실행 가능한 것

• 프로젝트 시작 전 세부적인 일정 작성(ex. JIRA, 마일스톤)
• 적절합 도메인형 패키지 구조 구성
  • 현재 프로젝트에서는 entity별로 도메인을 나누었는데 도메인형 패키지 구조는 유사한 entity별로 aggregate(군집)을 짓는 것을 원칙으로 한다는 것을 알게됨.
  • 군집된 entity들 간에 협력으로 해당 도메인에 비즈니스를 처리하고 외부 도메인 협력이 필요할 시 interface를 통해 조합해 볼 것
• Security filter의 예외처리
  • Security의 경우 대부분 예외 발생 시 기본 설정으로 response하게 되어 있음
  • EntryPoint, AccessHandler 등을 활용한 filter 예외처리도 고려해볼 것
• controller layer에서 transactional
  • controller는 api를 관리하는 영역이기에 비즈니스를 만드는 service layer에서 transactional을 처리할 것
• controller에 global mapping 정보
  • 규칙적이지 못한 경우가 있다 이 경우 추적성이 떨어질 수 있으니 유의해야한다.
• try-catch 시 구체적인 exception으로 예외를 처리는게 가장 중요하지만 그 이외의 예외가 발생했을 때 try 후 catch하기 때문에 예상 외 exception도 처리하기 위한 코드를 작성해 주어야한다.
• Entity에 상태와 같은 Enum을 확장성과 식별성을 위해서 구체적으로 수정. (Process -> OrderProcess || OrderStatus)
• TDD : 코드 작성 전 테스트 코드 작성을 습관화하기
• 팀플이 끝나고 자기가 구현한 코드말고도 다른사람의 코드를 뜯어보고 공부하는 시간을 가지자
• 다른사람의 api를 다 실행해보지 못한게 아쉬웠지만 다음에는 다 실행해봐야겠다.

시연영상

 https://youtu.be/NJZNop-ZLTc

깃허브 코드

https://github.com/GreedyPeople/GreedyPeople

 

 

일단 프로젝트가 끝났다, 뭔가 아쉬운부분도 있긴했지만, 팀원분들이 다 적극적으로 참여해주시고 , 새벽까지 열심히 해주셨다. 리더라는 직책이 부여됐으면 그에맞게 잘 했어야 했는데 아쉬운 부분이 많았다. 일단 ppt도 팀원분들이 다 만들어 주셨고, 물론 저는 그때 네이버 소셜로그인 하고있었지만, 결국 성공은 못했다 ㅠ 코드는 다 짜고, 토큰까지 받고 , 왜 안되지?

이 계기를 바탕으로 나는 더 성장했고, 다음 팀에서는 리더로서 더욱 잘 해야겠다 ㅠ