KPT 회고
Keep - 현재 만족하고 있는 부분
- 서로 기한 내에 정해진 기일에 맞추어, 프로젝트를 완성해내었다.
- 적극적으로 모든 팀원이 문제를 해결해나가기 위해 노력하였다.
- 여러 가지 기능들을 구현하려고 시도했다.
- 코드 컨벤션은 너무 잘 지켰다고 생각한다.
- 코드 컨벤션과 , 깃허브 룰에 대해 어느정도 숙지하고 프로젝트에 진입해서, 서로 깃에 의한 시행착오, 오류가 생각보다 적었다. 초반에는 거의 없었다.
- 각자 기능구현을 하려고 책임감을 가지고, PM 9시 이후에도 기능 구현을 하기 위해 노력하였다.
- 스크럼 횟수, 시간 너~무 잘 지켜졌다.
Problem - 불편하게 느끼는 부분
- 프로젝트 일정을 촉박하게 잡아서 , 프로젝트 각 기능에 대한 시간분배가 아쉬움
- 기능을 구현하는 과정에서, 개발 지식 부재로 인해 해결이 미흡한, 완성도가 떨어지는 부분이 존재한다.
- 코드에 대한 규칙이나 . 구조가 정해지지 않아 서로 코드를 보는데에 가독성이 상당히 떨어졌다.
- 사소한 코드 변경이나 내실이 없는 코드도 commit 을 해서 커밋 양만 많고 가독성 떨어짐(300개…?)
- 기획단계에서 메인컬러, 컨셉, 기능, 개인 업무분담 토의가 부족해서 완성도가 아쉬움.
- README를 제대로 작성하지 못했다.(진짜 중요) 이거 무조건 잘 작성하기
- Firebase init, API KEY 암호화하지 못했다 , gitignore 처리를 하지 못했다 → 보안, 손해 위험 큼
- 리팩토링이나, 위에서 상술한 세심한 프로젝트 전반에 걸친 수정에 대한 세심함이 부족하였다.
- 필수구현사항 체크 아쉬움. → FIGMA랑 노션을 작성하는 과정에서 실질적인 필수구현사항 Docs문서를 제대로 확인하지 않았음
- 주석이 부족해서 다른 사람이 작성한 코드, 함수 이해하는데 불필요한 시간 소요
Try - Problem에 대한 해결책, 당장 실행 가능한 것
- 분담된 개인 업무에 대한 마감기한을 정한다? , 프로젝트 일정관리에 관한 문서를 작성한다.(ex)Trello , Excel - 현업에서 사용함 다음에 사용하는 것을 고려 마감기한이나, 데드라인에 대하여, 각 개인이 지속적인 언급을 시도.
- 팀원들과 어려운 부분을 좀 더 빠르게 공유하고 찾아본 정보를 공유한다 그리고 적극적으로 같이 협업하여 문제를 해결하려고 노력한다. + 개인의 노력
- 잘 만들어진 프로젝트, 현업에서 일하시는 프론트엔드 개발자를 깃허브에서
- 확장프로그램(프리티어 등) 같은 설정파일을 사용하여 형식 맞추기
- 에어비엔비 https://github.com/airbnb/javascript?tab=readme-ov-file#jquery
- 최소한 개인이 작성한 코드 안에서 일관성 확보
- commit 할 때 조금 더 내용이 채워지고 기능이 제대로 동작하는지 로컬 환경에서 테스트 후 공용 공간에 내실있게 진중하게 커밋하자.
- 커밋은 feature 단위로 올라가야함 ⇒ stash (임시보관함) 활용하여 branch 이동, pull 진행
- git rebase 전략 / reset / revert 알아보기.
- 기획과 디자인(메인컬러, 컨셉), 기능에 대한 세부적인 사항을 확정 후 상세내용을 작성하여 구현하며, 개인 업무분담에 대한 시간분배를 깊게 해야한다.
- README작성 잊지 말자. 작성법을 잘 모를 경우 github를 통해 잘 된 프론트 프로젝트 , 잘 된 다른 팀 깃허브를 방문하여 참고한다.
- gitignore를 작성해 api key와 주요 암호를 감추자. + 코드 내부적으로 암호화 AES, RES 등 정보보안에 사용되는 암호화를 사용할 수 있으면 사용하자. https://velog.io/@jeong_woo/JS-프론트앤드-암호화-복호화
- 리팩토링과 코드 재작성에 관하여 수정, 토의할 수 있는 시간을 데드라인 혹은 스크럼을 통해서 코드 집중 작성 시간 외에 일정 시간을 팀원과 함께 할애하여, 지속적인 적극적인 의견 피력이 필요하다. 적극적인 토의가 필요하다
- 필수구현사항 Docs문서를 제대로 확인하자.
- 주석을 생활화하며 , 함수, 기능마다 잘 달아주자. → 다른 분들이 봤을 때 가독성이 훨씬 좋아져요.