우리 팀은 깃허브로 프로젝트를 관리하기로 결정했다.
위키에 각종 컨벤션, 역할 분담, 브랜칭 전략 등을 작성하고
깃허브 프로젝트를 통해 칸반보드 작성도 관리하기로 했다.
쓰면 쓸수록 느끼는 거지만, 깃허브의 기능은 정말 무궁무진한 것 같다..

지난 주 페어프그래밍을 3명이서 하게 되면서 간접적으로 팀 프로젝트를 경험했었는데, 그 당시에는 역할 분담도 없었고 같은 코드를 동시에 작성하려다 보니 어려움이 많았었다.
그래도 그때 팀원 모두가 문제를 공유했기에, 이번 팀 프로젝트는 확실히 역할도 나누고, 컨벤션 등 순조롭게 준비하게 됐다.
게다가 동시에 코드를 작성하는 게 아니라 브랜치를 나눠 비동기적으로 코드를 작성하다 보니, 지난 페어 프로그래밍 당시 보다 훨씬 수월하다고 느꼈다.
깃허브로 브랜치를 나눠 협업도 경험해보고, 프로젝트 경험이 많은 케니나 꼼꼼하고 똑똑한 이안으로부터도 너무나 많은 걸 배우고 있다.
이번 1차 프로젝트는 디자인 시안과 기획이 이미 확정된 상태로 전달 받아서 개발하는 방식이다. 그러다 보니, 애자일 방식을 온전히 수용하기에는 어렵다고 생각했다.
그래서 초기 설계까지는 워터폴을 적용하고, 이후 2주간 컴포넌트 작성 시에 애자일 방식을 접목하기로 합의했다. 이미 확정된 디자인 시안과 기획 방향에 대한 기본적인 인터페이스 설계를 정리한 상태에서 이후 2주간 피드백을 주고 받으며 컴포넌트를 작성하는 걸로 했다.
사실 매번 즉흥으로 코드를 작성하고 유지보수를 하는 방향으로만 코드를 작성해봤기에 인터페이스 설계 경험은 새로웠다. 이게 인터페이스 설계라고 하기도 뭐하지만, 최대한 하나의 컴포넌트에서 어떤 props를 받고 어떤 state를 설정하고 어떤 함수를 작성하고, 전역으로 관리할 상태 중 해당 컴포넌트가 어떤 상태를 주입받을 지를 고려하면서 작성했다.
작성하면서 느낀 건데, 설계를 하면 할수록 코드는 복잡해지고 가독성은 낮아져서 이걸 전달 받은 다른 팀원이 불편함을 느낄 것 같아서 최대한 계속 업데이트하려 하는데 아직 어렵다..
작성을 하고 나서 propType 패키지를 알게 돼서 다음에는 이걸 기준으로 prop에 대한 설계를 먼저 해봐야겠다..


프로젝트 기간이 끝나면 3문제에서 4문제로 문제 수를 늘려볼까 고민 중.
이제 좀 그래피에 익숙해지나 싶었더니 dfs가 또 약점이 됐다.
입력값이 많아지면 자바스크립트에서 재귀를 쓰기가 너무 부담스러운 상황들이 온다(다른 언어들은 그냥 재귀를 써도 되는 문제조차...).
스택 자료구조를 사용해서 dfs를 구현하는 방법을 연습해야겠다.

프로젝트 기간처럼 코드 작성하기에도 바쁘고 무언가를 새로 배우기 부담스러울 때, 단순히 TIL로만 새로 배운 걸 정리하는 정도로는 부족함을 많이 느낀다. 단순히 혼자 배우고 소화하기에는 시간이 부족하다.
그래서 팀원 간에 서로 배운 것들을 공유하는 모음집을 관리하기 시작했는데,
많이 배웠으면 좋겠다.


계획한 일정을 차질없이 진행하는 게 최우선 목표다.
아직까지는 별 일 없었지만, 브랜치를 나눠 협업하다보면 conflict도 많이 날 것 같고, 그 과정에서 실수를 많이 할 것 같아 걱정이지만 잘 해결해 나갔으면 좋겠다.

프로젝트 기간이라 바쁘지만, 알고리즘 스터디도 꾸준히 할 수 있기를!
프로젝트 기간이라는 이유로, 새로운 지식 습득을 게을리 하지 않기를!