[네이버 부스트캠프] 네이버 부스트캠프 웹・모바일 8기 그룹 프로젝트 4주차 회고

벌써 4주차가 끝났다.

 

2주 뒤면 그룹 프로젝트가 종료되고 부스트캠프의 모든 과정이 종료된다.

 

아쉬움이 남지 않도록 남은 기간도 화이팅 해야 할 것 같다.

 

잘한 점

기능 구현 외에 다른 부분도 신경써볼 수 있었다.

 

서로를 구분하기 위한 랜덤 닉네임 생성기도 만들어보고 팀원들과 함께 서비스를 직접 사용해보며 불편했던 부분을 고쳐볼 수 있었다 (예를 들어, 내 닉네임이 별도로 표시되지 않아 불편했던 것 등)

 

또한, 이런 서비스적인 부분 뿐만 아니라 어떻게 해야 성능적인 개선을 할 수 있을지 고민하게 되었다.

 

이러한 고민을 하게 된 계기는 평소처럼 빌드를 하는 과정에서 Vite에 의해 발생한 경고 때문이었다.

대략적으로 빌드 파일의 크기가 크다는 뜻으로 생각하면 된다.

 

이를 해결하기 위해 Visualizer도 처음 사용해보고 현재 프로젝트에서 사용되는 코드 중 어떤 부분이 많은 크기를 차지하고 있는지 파악할 수 있었다.

 

이를 해결하는 과정을 통해 프론트엔드 성능 최적화에 관심을 갖게 되었다.

 

그리고, 저번 WebRTC에 이어 이번에도 페어 프로그래밍을 진행하게 되었다.

 

공동편집 기술인 CRDT를 구현하기 위해 페어 프로그래밍 방식을 채택했으며 WebRTC를 구현할 때와 마찬가지로 효과가 상당히 좋았다고 생각한다.

 

서로 부족한 부분을 채울 수 있었고 놓치는 부분도 함께 찾을 수 있었다.

 

페어 프로그래밍을 처음 시도했을 때는 불편한 점이 더 많다고 생각했다.

 

협업을 하고 싶다면 GitHub 등을 이용하는 방법이 있는데 왜 페어 프로그래밍 방식을 적용하는지 이해하지 못했다.

 

하지만, 페어 프로그래밍을 여러번 하는 과정에서 페어 프로그래밍의 장점을 느낄 수 있었고 효율적이고 빠르게 개발을 할 수 있었다.

 

아쉬운 점

기능이 추가되거나 변경이 되는 경우가 있었는데 이 과정에서 많은 부분이 바뀌어야 했던 것 같다.

 

또한, 한 컴포넌트가 많은 역할을 하고 있는 것 같다는 생각이 들었다.

 

마지막으로 작업 "과정"에 대한 문서화가 아쉬웠다.

 

나는 문서화를 할 때

1. 우선 결과를 만들어 낸다.

2. 결과를 만들어내기 까지의 과정을 기록한다.

위의 과정으로 문서화를 했다.

 

이렇게 작성했을 때의 장점은 문서가 깔끔해지고 어떤 문제를 해결하기 위한 방법이 어떤 것인지 명확하게 전달될 수 있는 것이라 생각한다.

 

하지만, 단점은 결과가 나오지 않은 도전은 문서화에 포함이 되지 않는다는 것이다.

 

예를 들어, 3번 만에 문제가 해결되는 경우 마지막 시도만 문서화 되고 나머지 두 번의 시도는 문서화 되지 않았다.

 

이런 과정에서 문서화 되지 못하는 시도들이 있다는 생각이 들었고 이를 개선해야 겠다는 생각이 들었다.

 

앞으로

추가 또는 변경이 되며 많은 수정이 필요하지 않았던 코드들을 참고하여 어떻게 구성해야 할 지 생각해봐야 할 것 같다.

 

또한, 컴포넌트는 최소한의 역할을 할 수 있도록 분리하고 자신과 관련된 상태만 갖도록 구성해야 겠다는 생각을 다시 한 번 하게 되었다.

 

마지막으로, 결과에 대한 문서화 뿐만 아니라 과정에 대한 문서화도 함께 진행하여 결과가 나오지 않은(중간에 버려진) 과정들고 문서화를 할 수 있도록 해야겠다.