[회고] 메인프로젝트 / 협업

🎧 글 진행 순서
1. 프로젝트 결과물 & 구현내용
2. "2주간" 범한 실수 : 개발은 혼자하는 것이 아니다. -> 혼자 끙끙은 절대 안대! 차라리 징징!
3. "2주간" 범한 실수 : 개발은 혼자하는 것이 아니다. -> github는 단순히 "버전관리" 플랫폼이 아니다.
4. 페이지 중심의 대화 vs 기능 중심의 대화
5. Git을 활용한 협업

 

다사다난했던 프로젝트가 마무리되었다.

이번 프로젝트에서는 배운게 너무 많아서 정리하기도 쉽지 않고, 특별히 팀원분들과 멘토분들의 도움을 많이 받아서 감사한 시간이었다.

그래서, 프로젝트의 회고를 협업회고 / 기술회고로 나눠서 정리해보고자 한다.

 

짧은 요약을 하자면,

"나 혼자 하는 삽질이 내 구뎅이만 파는 행동이라는 사실을 알게되었다..."

 

프로젝트 결과물 & 구현내용

프로젝트 명 : 스터디 통합 플랫폼 EduSync
프로젝트 기간 : 2023.05.01 ~ 2023.05.25
인원 : FE 3명, BE 3명
배포링크 : https://www.edusync.com
Github : https://github.com/codestates-seb/seb43_main_016
구현담당 : 스터디 그룹 관리 / 캘린더 기능

 

 

"2주간" 범한 실수 : 개발은 혼자하는 것이 아니다 ①

부트캠프에 들어오기 전부터, 부트캠프 6개월 학습 기간 내내 들었던 이야기이다.

하지만, 실제 프로젝트에서 팀원분들께 민폐를 끼치고 나서야 그 내용을 깨달을 수 있었다.

위의 API 명세서는 스터디 그룹 기능을 구현하기 이전에 진입할 스터디 그룹의 id를 특정하는데 꼭 필요한 api 명세서이다.

백엔드 측에서 여러 기능들을 구현해주셨지만, 이 명세서를 포함한 몇몇 명세서가 나오지 않아 다른 기능을 구현하면서 "그저 기다림"과 나름의 방법 (MSW 등)으로 억지로 구현하려고 했던 것이 첫 번째 실수였다.

 

내게 필요한 내용이 있으면 적극적으로 어필하고, 설득하고, 해당 문제를 빠르게 해결할 수 있는 방안을 강구해야 한다.

개발은 개인이 아닌 "Team"으로 진행되는 것이며, 각 기능은 철저히 업무분장이 이뤄져서 각자가 담당해야 하며, 결과물에 대한 평은 Team 모두가 공유하는 것이기 때문에, 내가 현재 어려워하는 문제를 매 상황마다 공유하고 빠르고 효과적인 대안을 끊임없이 강구해야만 한다.

 

"2주간" 범한 실수 : 개발은 혼자하는 것이 아니다 ② : github는 단순히 "버전관리" 플랫폼이 아니다.

프로젝트 2주간의 issue와 discussion을 보면 나의 issue가 전혀 없다..

실제로는 화면 정의서를 만들고 나서 열심히 각 기능들을 구현하던 중이었고 여러 문제에 봉착해서 고민에 고민을 거듭하는 과정이었다.

 

한 1~2주쯤 지나서 팀장님과 오픈토크 채널에서 모여서 이것저것 이야기를 나누다가 문제 해결을 위한 여러 방안들에 대해 이야기를 나눈 뒤에야 github에서 issue / discussion / canvan 등을 활용할 때의 이점에 대해 체감하게 되었다.

(사실, 이때서야 협업 + 왜 프로젝트 때 쌈박질을 해봐야 하는지에 대해 알게되었다.)

github를 활용한 협업의 장점은 다음과 같다.

1. 역적 처단의 효과적인 수단 : 대부분 내가 역적이라는게 함정.
2. 책임 떠넘기기(?)의 효과적인 수단 : 나는 분명 요청했고, 너는 분명 답했어!
3. 보기 쉽고, 진행상황 파악하기 쉽다 → 닥달하기에 좋다!
4. 결론 : 어떻게든 빠르게 문제를 해결하고, 리팩토링하고, 더 나은 방안을 찾고, 함께 좋은 결과물을 내는데 효과적이다!

위와 같은 성찰의 결과물은 다음과 같다.

 

페이지 중심의 대화 vs 기능 중심의 대화

나는 기존에 페이지 중심의 "Components > Pages" 라는 단순한 페이지 중심의 조립식 개발을 생각했다.

이 경우 "내 페이지, 내 기능"은 정상적으로 동작할 지 모르겠으나 백엔드와의 협업, 컴포넌트 및 기능의 범용적 재사용의 측면에서 상당히 불리한 생각이었다.

이불킥 ) 백엔드 분들께 api 명세서를 페이지 중심으로 정렬해주실 것을 요청드렸는데,,,,,,,,, ;;;;;;;

반대로, 기능 중심으로 어떤 기능들을 시작으로 구현할 것인지 고민한다면 페이지 관련한 내용들은 전부 "최종 조립"이라는 단계만 남기고 기능 자체에 집중할 수 있기 때문에 훨씬 효과적이다.

* 어쩌면 나는 "웹의 기능"이라는 개념을 일반 사용자 느낌으로만 체감하고 있었는지도 모른다.. 어쩌면 지금도..

 

Github를 활용한 협업

위에서 언급한 Github를 활용한 협업의 장점을 다시 한번 적어보자면 다음과 같다.

1. 역적 처단의 효과적인 수단 : 대부분 내가 역적이라는게 함정.
2. 책임 떠넘기기(?)의 효과적인 수단 : 나는 분명 요청했고, 너는 분명 답했어!
3. 보기 쉽고, 진행상황 파악하기 쉽다 → 닥달하기에 좋다!
4. 결론 : 어떻게든 빠르게 문제를 해결하고, 리팩토링하고, 더 나은 방안을 찾고, 함께 좋은 결과물을 내는데 효과적이다!

사실 Github에서만 가능한 내용은 아니지만, "버전 관리"와 맞물려서 강력한 기능으로 동작한다.

다음은 Github를 활용해서 협업을 위해 노력한 흔적들이다.

 

& Discussion → 각종 요청

& Issue → Process Tracking

& Pull Request → Comment & Approve

& Roadmap, Canvan