그동안 미니 프로젝트를 진행한다고 회고를 전혀 하지 못했다. 오늘은 진행했던 미니 프로젝트를 가지고 KPT 회고를 해보려고 한다.
KEEP
- Git 컨벤션 및 브랜치 전략
- 프로젝트를 시작하기에 앞서 Git에 관련된 컨벤션(커밋 메시지, 브랜치 이름 정하기 등) 및 브랜치 전략(main / develop / 작업 브랜치)을 정했더니 작업하는데 있어 효율적이었던 것 같다.
- 페어 코드 리뷰
- 내가 모르고 있던 내용이나 시야에 대해서 공유를 할 수 있기 때문에 페어를 정해서 코드 리뷰를 했던건 좋았던 것 같다. 짧은 일정이었지만 중간에 페어를 바꿨던 것도 좋았던 것 같다.
- AI 코드 리뷰어
- 리뷰를 해준다는 것은 페어가 그만큼 시간과 에너지를 들여야한다는 것이기 때문에 최소한의 시간과 에너지만 쓸 수 있도록 사전에 AI가 코드를 리뷰를 해주는 것도 좋았던 것 같다. 전체적인 내용보다는 파일 단위로 리뷰를 해주기 때문에 반복적인 내용이 있고 적용하면 안되는 내용도 섞여있지만, 오타, 중복 코드, 변수 네이밍 등 쉽게 놓칠 수 있는 부분은 꽤나 잘 찾아주기 때문에 잘 사용하면 유용할 것 같다.
PROBLEM
- 코드 컨벤션
- Git에 대해서는 컨벤션을 정했지만 코드에 대해서는 컨벤션을 정하지 않아서 코드를 합친 후에 리팩토링을 해야하는 등 리소스가 추가로 투입되었다. 각자의 코드 스타일이 다르기 때문에 사전에 디테일한 부분에 대해 컨벤션을 정했더라면 코드의 품질은 올라가면서 리소스는 적게 필요했을 것 같다는 생각이 들었다.
- 브랜치 전략
- 프로젝트 시작 전에 브랜치 전략을 정했지만 프로젝트를 진행하면서 제대로 지켜지지 않은 부분이 있었다. 하나의 브랜치에서 너무 많은 기능을 구현한다거나, develop 브랜치에 반영하는 타이밍을 제대로 잡지 못해서 각각의 브랜치를 서로 pull 당겨서 작업을 한다던가 하는 문제가 있었다.
- 적절한 역할 분담
- 각자의 진도 상황, 참여하고 있는 수준별 학습반 등 여러 부분에서 차이가 있었는데 그것을 고려하고 역할 분담을 나눴음에도 프로젝트를 진행하면서 일정에 대한 압박과 함께 적절하게 역할 분담이 되고 있는가에 대한 생각을 하게 되었다.
TRY
- 코드 컨벤션
- 다음 프로젝트에는 코드의 품질은 올리고 투입되는 리소스는 줄일 수 있도록 사전에 코드 컨벤션을 정할 것이다. 얼마만큼 디테일하게 정해야하는지 감이 오지 않기 때문에 이번에 코드 컨벤션을 적용한 조의 멤버와 튜터님들에게 조언을 구해서 진행하면 좋을 것 같다.
- 브랜치 전략
- 이번 프로젝트에서 진행 했던 브랜치 전략은 처음에는 그럴싸 했지만 마지막에는 그럴싸하지 못했다. 끝까지 그럴싸하지 못했다는 것은 운용법이 잘못 되었을 수 있다는 뜻이기도 하기 때문에 튜터님들에게 조언을 구해서 끝까지 잘 지킬 수 있는 전략을 시도해봐야 할 것 같다.
- 프로젝트 디렉토리 관리
- 이번 프로젝트는 계층, 설정 등으로 디렉토리를 관리했는데 기능이 많지 않았음에도 불구하고 깔끔한 모양이 아니었다. 발표회에서 좋은 평가를 받았던 도메인을 기준으로 관리하는 방법을 다음에는 사용해야 할 것 같다.
