2024-06-03 [Programmers newsfeed Project (KPT 회고)]

첫 번째 스프링 팀 프로젝트가 오늘에서야 끝이 났습니다.

문제없이 진행되었으면 좋았겠지만 처음이다보니 개선이 필요한 부분들이 많이 있었고, 그만큼 배울 수 있는 것들도 참 많았던 것 같습니다.

첫 프로젝트여서 더 많이 기억에 남을 것 같습니다.

아래는 진행했던 프로젝트의 GitHub 의 주소입니다.

https://github.com/JinkownHong/newsfeedProject.git

GitHub - JinkownHong/newsfeedProject

 

6조 Explore Project KPT 회고

 

[Keep]

1. GitHub Projects

이전 현업에서 경력이 있던 수진님의 제안으로 시작한 GitHub Project 설정 및 Issue 관리입니다.

각 이슈 별 Branch 를 설정하여 main 에서 합쳐나가는 방식으로, Branch 명의 경우 Issue Number 로 설정한 부분은 통일성 측면에서나 유지보수 측면에서 큰 도움이 되었습니다.

다음 프로젝트에도 해당 기능을 활용할 수 있다면 Issue 에 내용을 보다 구체적으로 보강하는 방안으로 더 강화해나가면 일정 조율이나 역할 분담에 있어 더 많은 도움이 될 것 같습니다.

 

2. pair programming

규모가 작은 프로젝트를 여러 명이서 나누어 진행하다 보니 도메인 별 역할을 분리하지 못하고 세세한 기능 별 역할을 분리해야만 했습니다.

때문에 한사람이 기능을 완성하지 못할 경우 다른 한사람은 코드가 완성될 때까지 기다려야 하는 경우가 발생했고, 시간이 다소 낭비될 수 밖에 없었습니다.

튜터님의 도움으로 진행한 방식은 기능적으로 많이 엮여있는 팀원들끼리, 또는 도움을 주고, 받을 수 있는 팀원들끼리 CodeWithMe 를 함께 진행하여 초반 시간을 획기적으로 줄일 수 있었습니다.

팀 내 pair programming  rule 을 정해놓고 보다 해당 시스템을 보다 적극적으로 활용해보면 코드의 통일성이나, 일정 관리 및 역할 분담 측면에서 더 많은 도움이 될 것이라 생각합니다.

 

[Problem & Try]

1. 프로젝트 초반 역할 분담 관련

프로젝트 초반 구현할 기능들을 논의하고, Team Notion 을 제출했을 때 "짧은 시간 동안 너무 많은 기능들을 욕심내고 있는 것 같다" 는 평을 들었습니다.

결과적으로 구현하지 못한 몇 가지 기능들이 있었는데 (EX. Post 내 이미지 업로드 기능, Profile 내 이미지 업로드 기능 등) 욕심이면 욕심이 원인일 수 있지만,

처음 역할 분담을 한 뒤 각자 맡은 여러 가지 기능들을 세세히 나누어 일정을 계획하고 진행했다면, 쫓기면서 팀 프로젝트를 진행하거나 기능 구현 실패는 없었을 것 같다 생각했습니다.

 

다음 프로젝트부터는 초반 세세히 일정을 정하고, 처음 구현하기로 약속한 기능들이 현실적으로 가능한지, 일정 내 완수하지 못했을 경우 어떤 식으로 해당 문제를 해결할지 등 을 정하고 들어가면 시간에 쫒기지 않고 일정대로 잘 진행할 수 있지 않을까 싶습니다.

 

2. 보이지 않는 프로젝트 컨셉

Wireframe 을 작성할 때 구현해야 할 기능들을 생각하는데 집중하느라 실질적인 프로젝트의 컨셉이나, 차별점을 생각하지 못해 프로젝트 주제를 잘 담아내지 못한 newsfeed 프로젝트로 끝이 난 것 같아 다소 아쉽습니다.

 

프로젝트 컨셉을 담을 수 있는 기능들이나 여러 장치들을 고려한 뒤 들어가는 것이 중요할 것 같습니다.

 

3. 코드 리뷰

프로젝트 초반, 코드 리뷰가 잘 진행되는 듯 싶었으나 시간이 지날수록 마감 기한에 쫓기다 보니 정해진 코드 리뷰 시간에 각자 끝내지 못한 역할들을 진행하느라 바빴습니다.

결과적으로 다른 팀원이 작성한 코드에 대한 이해도가 부족했고, 오히려 각자의 문제 해결방안을 공유할 수 있는 시간이 부족해지다보니 더 많은 시간을 소진하게 되었습니다.

 

PR 를 올리면서 작성한 코드에 대해 상세히 설명하여 어려운 부분이나 리팩토링이 필요한 부분, 완성은 했으나 더 나은 작성 방법이 궁금한 부분 등을 짚어 팀원들과 다같이 얘기해 보는 시간을 갖는 것이 코드를 작성한 팀원 입장에서도, 작성한 코드를 리뷰하는 팀원들한테도 많은 도움이 될 것 같습니다.

 

다음과 같은 코드 리뷰 시간을 거쳐, 최종적으로 코드를 수정한 이후 Merge 하는 과정을 거쳤으면 서로의 코드를 보다 완벽하게 이해하고, 다양한 기능들을 학습하는데 도움이 될 것 같습니다.

 

4. 코드 간 통일성

코드 간 통일성이 떨어질 수 밖에 없었는데 결국 서로의 코드에 대해 얘기를 나누어 보고, 의견을 들어볼 수 있는 시간이 없어 발생한 문제라 생각합니다.

 

프로젝트 일정을 확실하게 정하고(처음부터 모든 것을 정하기 어렵다면, 큰 틀은 정해져 있는 상황에서 일 별로 세세한 일정을 정하는 것도 좋은 방법이 될 것 같습니다.),

중간 중간 코드 리팩토링 과정을 거치거나 처음부터 몇가지 코드 작성 룰 (EX. 메서드 네이밍 규칙, 도메인 분류 기준 등)을 정해놓고 진행한다면 통일성을 갖춘 코드에 나름 가까워지지 않을까 .. 싶습니다.

 

5. Test 관련

코드 작성을 마무리하고, Test 시나리오를 짜는 것에 생각보다 많은 시간을 소진하였습니다.

 

기능을 구현할 때, Test Case 까지 담당하는 인원이 정리해 놓는다면, 시나리오를 기획하고 시연 영상을 녹화하는 것이 비교적 수월해질 것 같습니다.

 

결론

이렇게 정리해보니 결론적으로 발생한 모든 문제들을 보았을 때 문제의 원인은 코드 작성 전 사전에 많은 얘기를 나누어본다던지, 명확하게 일정(기능 별 일정, 데드라인, 코드 리뷰 타임)을 설정하지 않아 발생한 문제들이라는 것을 깨달을 수 있었습니다.

사전 준비를 보다 체계화하는 작업이 반드시 필요할 것 같고, 여러 명이서 진행하는 프로젝트이다 보니 서로의 코드를 리뷰할 수 있는 시간이 반드시 필요하다 느껴졌습니다.