코드 컨벤션, git Rule 등 미리 협의와 합의를 통해 규칙을 정해서 프로젝트을 진행할 때, 불필요한 소통과 다시 한번 점검해야하는 리소스 낭비를 방지할 수 있었다.
모르는 것을 물어보면 다들 빠르게 이유, 과정, 결과에 의겨해서 슬랙 및 zep 소통에서 피드백을 해줬다.
과제에 제시한 기능 이외의 정보들을 적극적으로 공유하면서, 기능 구현 확장과 용이성에 대해 협업을 하려고 했다.
모두가 알고있는 강의의 내용 을 잘 활용해서 팀원간 어떤 기능을 구현하는지에 대해서 빠르게 파악하고 활용할 수 있었다.
⛳TRY
미리 협의를 통해서 AWS DB를 정하거나 IntelliJ 환경 변수 기능 협의해 프로젝트 시작 전에 먼저 결정하고 프로젝트를 진행할 수 있도록 한다.
미리 기능을 구현할 수 있는 팀원이 빠르게 구현을 완성을 하고, 추가 기능 부분에서 좀더 기능을 분리해서 진행할 수 있도록 한다.
추가적인 구현 가능성을 처음부터 고려를 해서 필수 구현을 하는 동시에 추가 구현 여부에 관한 준비를 동시에 진행해서 개발을 하도록 한다.
강의를 기반으로 진행하는 것이 학습하는 부분에서는 좋은 자세지만, 여유가 있다면 탐구하는 방향으로 고민을 해보는 시간을 가지고 구현할 수 있도록 한다.
완벽한 정해져있는 고착된 방법의 기능 구현을 하려는 자세보다는 타당한 이유가 있다면, 새로운 아이디어로 기능 구현을 시도하고 코드리뷰를 할 수 있도록 한다.
❗PROBLEM
DB관련 각 팀원간 환경 변수가 맞지 않아서 git PR 및 merge에 관련 할 때마다 신경써야했다.
Filter 단에 엮어져 있는 인증/인가 기능이 한 Flow이기 때문에 여러명이 동시에 진행하는 것이 힘들었다.
추가 기능에 대해서 확장 가능성을 일단 배제하고 프로젝트가 진행이 되어 추가 기능에 관련한 요구사항에 있어서 대처가 미흡했다.
Spring Security 강의 포맷을 기반으로 구현을 하다보니 기능 확장에 있어 제한이 있었다.
좋아요 기능의 추가/삭제 부분이 Toggle 형태로 구현되어 RESTful한 API가 부합하지 않았다.
TRY / Action Plan
프로젝트 전 S.A. 룰에서 프로젝트 참여하는 팀원마다 달라지는 DB환경을 통일하기 위해, AWS DB 구축을 완성 또는 IntelliJ 의 application.properties에서의 환경 변수 설정 등 사전 협의를 반드시 진행하여 기능 구현 중 불필요한 설정을 추가적으로 하지 않도록 한다.
기능을 구현하는 팀원은 강의 제공 자료 또는 많이 사용하는 템플릿 등 고착화 된 방법만을 고수하지 않고, 자신많의 아이디에이션을 통한 타당한 근거를 통해 자신만의 코드를 작성, 팀원과 코드리뷰 하는 자세를 가질 수 있도록 한다.
PRD에 따른 기능 구현을 진행함에 있어서 구현하는 개발자는 추가적으로 확장할 수 있는 기능에 관하여 확장 가능성 여부를 고려하여 개발 할 수 있도록 한다.
ex. AccessToken 기능 구현할 시, RefreshToken 기능이 추가적으로 구현할 수 있음을 가정하여 개발
