이번 주에는 2.5일간의 미니프로젝트를 진행했다. 짧았던 만큼 치열했던 기억을 더듬어보며 가지고 가고 싶은 것과 바꾸고 싶은 것을 간단하게 정리해 본다.
팀원
갑작스러운 인원 변경(5명 -> 3명)에도 각자 불평불만 없이 늘어난 일을 뚝딱 해치우는 것을 보고 파이널 프로젝트에서도 이 팀원들과 함께 했으면 좋겠다는 생각을 했다. 또한 각자의 부족한 점을 채워주는 조합이었어서 협업의 시너지를 느낄 수 있었다.
자주 코드를 합치는 습관
단기간에 진행됐던 프로젝트였던 만큼 잠깐 시간이 지나도 풀리퀘스트의 커밋 수가 커졌다. 팀장분의 판단 아래 머지를 주기적으로 하다보니 merge conflict 해결하는 시간이 줄어들었고, 프로젝트 상황을 자주 업데이트할 수 있어 개인 작업 상황과 타인의 작업 상황을 쉽게 확인할 수 있었다.
문제 상황의 빠른 공유
테스트케이스를 꼼꼼히 따져가며 확인하는 팀원분이 문제가 있을 때마다 문제를 빠르게 공유했다. 덕분에 비교적 어려운 문제를 집단지성으로 빠르게 해결할 수 있었다.
브랜칭 정책 세분화
master
브랜치에 풀 리퀘스트 머지를 한 이후 오류를 해결하기 위해 팀 전체가 진땀을 흘렸던 경험을 했다. test
와 같은 브랜치에 머지한 후 디버깅을 한 뒤 master
브랜치로 옮겼으면 더 나았을 것이라 생각한다. 유명 기업들의 기술 블로그를 보며 브랜치 전략을 벤치마킹하는 것도 좋을 것 같다.
디버깅 전략 부재
실행 오류가 나고 오류를 쉽게 찾을 수 없을 때, 나만의 디버깅 전략이 없었기 때문인지 쉽게 당황하고 다른 팀원의 도움을 받아야 했다.
원격 협업 전략
이메일이나 슬랙 메세지 등을 다른 팀원보다 늦게 확인하는 경향이 있었다. 다행히 이번 미니 프로젝트는 바로 옆자리에 있는 팀원들이 말로 바로 전달해 주어 큰 문제가 되지 않았다. 개인 작업에 집중하면서 너무 늦지 않게 알림을 확인할 수 있는 전략이 필요하다고 느꼈다. 예를 들어, 포모도로 휴식 세션이 끝난 직후 알림을 확인하고 일 우선 순위를 바꾸는 루틴을 추가해보는 것이다.
지저분한 코드
시간 내에 구현하는 것에 매몰되어 있다보니 코드의 질이 현저히 낮아졌다. 파이널 프로젝트에서는 미니 프로젝트보다 큰 규모의 코드를 작성하게 될 텐데, 코드의 질이 낮아지면 나중에 다른 기능들을 추가하거나 디버깅, 유지보수 단계에서 문제가 될 것같다는 생각을 했다.
——————————————————————————