7.22~8.8 27조 KPT회고

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

👍 회의를 통한 프로젝트 기획

• 개인 개발은 회의를 통한 기획 이라는 단계가 존재하지 않는다. 스스로 요구사항을 분석하고, 그를 토대로 개발을 진행하기 때문에 자기 주관적인 생각만을 이용해서 작업을 진행한다. 하지만 이런 특성이 팀 개발에서도 이어질 수 있다. 팀원들이 매우 소극적인 경우 팀장의 주도하에 개발을 진행하면 팀장의 생각대로만 개발이 행해지는 경우도 있는데, 본 프로젝트의 경우 모두가 의견을 제시해서 각자의 의견중 타당한 부분을 채택해 개발을 진행했다. 이 부분이 팀 프로젝트의 장점을 살린거 같아서 만족스럽다.

👍 정기적 회의로 상황 공유 및 코드리뷰

• 업무를 분담하고 기능을 구현할때 까지 개발만 진행하면, 같은 객체를 이용해서 다른 기능을 구현하는 사람과 메소드 명, 리턴 타입 등등의 차이가 발생할 위험이 있다. 본 프로젝트의 조의 경우 잦은 회의를 통해 공동으로 사용되는 객체의 타입, 이름등을 계속 공유하면서 통일시켜 개발 과정이 수월할 수 있었다.

👍 깃헙 커밋을 통해 업데이트 된 부분 표기

• 팀 프로젝트의 경우 각자의 작업을 대략적으로 인지하고 개인 작업을 진행한다. 이를 위해서 보게 되는것이 commit message인데, message의 수준에 따라 추가적인 질문이 생길수도, 아닐수도 있다. 본 프로젝트의 경우 message를 완벽하게 작성하진 않았지만, 대략적으로 해당 push 버전이 어떤 method를 구현했고, 수정한지 파악이 가능하도록 작성해서 개발 과정을 더욱 수월하게 해주었다.

👍 코드 작성만 하는게 아닌 다이어그램, flow 차트, 노션 작성 등을 이용해서 개발 과정을 기록함

• 코드를 작성하다 보면 구조에 혼란이 오고, 어느 부분 까지 된건지, 다른 팀원은 뭘 하는지 파악하기 힘든 경우가 발생한다. 이를 방지하기 위해서 본 프로젝트에선 다이어그램, 노션 작성 등을 이용해서 각자의 진행사항을 공유했고, 이를 통해서 개발 과정과, 계획을 전부 파악할 수 있었다. 

---

Problem & Try- 불편하게 느끼는 부분과 Problem에 대한 해결책

⚠️ IDE 문제 발생시 도움을 줄 수 있는 지식이 없음

• 작성한 코드에 대한 에러는 내용에 맞게 수정을 거치면 되지만 IDE와 관련된 문제는 해결하기가 쉽지 않았다. 각자 개발하고 있는 로컬 환경도 모두 다르기 때문에 팀원들끼리 서로 도움을 주는 것에도 어려움을 겪었다.
• Try
  • 가장 중요한건 설정파일은 최대한 gitignore에 등록을 하는것이며, 개인 로컬에서 발생하는 에러는 따로 작성을 해서 정리를 해둬야 한다.

⚠️ 프로젝트 초기 Git Branch를 메인으로 다 merge해서 최종 백업을 진행하지 못했음

• 프로젝트 초기 각자 맡은 부분을 Branch 화 하여 커밋을 하였는데, Github pull request & merge가 익숙하지 않아 main branch에 모두 merge를 해버렸다.
• Try
  • 3번째 구조로 작업을 시작할때 중간 main인 dev branch를 생성해서 dev에 PR을 하고, 작동 확인을 하는등 배포용인 main을 사용하지 않은 방식을 사용했다.
  • 항상 main은 최종만 PR한다는 생각을 지녀야한다. 

⚠️ Github 사용 미숙으로 시간을 낭비함

• GitHub를 사용한 개발이 익숙치 않아 push시 충돌이 발생한걸 해결하지 못하거나, 커밋을 선행하지 않아 pull을 하지 못하는 오류등으로 시간을 빼앗긴 경우가 종종 있었다.
• Try
  • 사실 이런류의 오류는 접하는 횟수가 늘면서 익숙해지는 것이기 때문에 당장 완벽하게 하지 못하지만, 자주 발생하는 오류는 정리를 하고, 오류 발생시 마다 해당 문서를 보면서 익숙해져야 한다.