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

• 개발 속도가 꽤 빨랐던 게 만족스러운 부분이었던 것 같습니다.

• 각자에게 문제가 생겼을 시 문제 공유가 잘 이루어지고 화면 공유, 적극적인 의견 표현 등 트러블 슈팅이 신속하게 이루어졌더 부분이 좋았습니다.

• 각 부문의 기획 조건에 맞게 발생할 수 있는 다양한 예외 상황을 고려한 꼼꼼한 예외 처리가 이루어져 만족스러웠습니다.

• Redis, Github Action, Docker Compose 등 새로운 기술 스택을 적용해볼 수 있는 기회가 되어 좋았습니다.

• 예외 처리, 알림 수신 등의 부분에 대해 적극적으로 AOP를 적용해볼 수 있었던 점이 의미 있었습니다.

• GitHub 관련 규칙 등이 잘 이루어지고 커밋 메시지가 직관적이어서 팀원간의 협업이 수월하였습니다.

• 팀원 모두가 리팩토링을 통해 코드 컨벤션을 지키고 객체지향적이고 고도화된 코드를 짜기 위해 노력하는 모습이 보기 좋았습니다.

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

• 기초 설계가 다소 미흡했던 부분이 있어 개발 도중에 변경 상황이 여러 번 발생하여 아쉬웠습니다.

• 팀원간의 커뮤니케이션에 다소 부족했던 부분이 있는 것 같아서 아쉬웠습니다.

• 권한 관련 유효성 검증 리팩도링 도중에 실수가 발생했던 점이 불편하였습니다.

• 각 도메인이 복잡하게 얽혀 있다 보니까 전부 병합했을 때 완벽하게 유기적으로 작동하지는 않았다는 점이 아쉬웠습니다.

• 각박한 스케줄로 인하여 코드 병합시 팀원간의 코드 리뷰가 거의 부재했던 점이 문제였던 것 같습니다.

• 프로젝트기간 동안 TIL작성에 조금 소홀해졌습니다.

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

• 전체적인 서비스 관점에서 기획 요구 조건들을 확실히 파악하고 탄탄한 기초 설계를 작성하고 시작해야만 개발 과정이 한층 수월해질 것 같습니다.

• 기획 단계에 시간을 더 투자해서라도 탄탄하고 면밀한 설계를 하는 것이 중요할 것 같습니다

• 서로간의 적극적인 코드 리뷰와 코드 공유를 통하여 더욱 품질 높은 코드를 작성하는 것이 좋은 방법이 될 수 있을 것 같습니다.

• 특정 기능을 구현할 때 요구 조건을 더욱 면밀히 파악하고 기능을 구현하여 불필요한 코드 수정을 최대한 방지하기 위해 노력해야 합니다.

• 개발 일정이 짧다면 설계 단계에서도 짧은 개발 기간을 고려하여 설계 단계에서 이를 염두하고 설계를 진행 해야할 것 같습니다.