이번 주에는 2.5일간의 미니프로젝트를 진행했다. 짧았던 만큼 치열했던 기억을 더듬어보며 가지고 가고 싶은 것과 바꾸고 싶은 것을 간단하게 정리해 본다.

유지하고 싶은 것

  • 팀원
    갑작스러운 인원 변경(5명 -> 3명)에도 각자 불평불만 없이 늘어난 일을 뚝딱 해치우는 것을 보고 파이널 프로젝트에서도 이 팀원들과 함께 했으면 좋겠다는 생각을 했다. 또한 각자의 부족한 점을 채워주는 조합이었어서 협업의 시너지를 느낄 수 있었다.

  • 자주 코드를 합치는 습관
    단기간에 진행됐던 프로젝트였던 만큼 잠깐 시간이 지나도 풀리퀘스트의 커밋 수가 커졌다. 팀장분의 판단 아래 머지를 주기적으로 하다보니 merge conflict 해결하는 시간이 줄어들었고, 프로젝트 상황을 자주 업데이트할 수 있어 개인 작업 상황과 타인의 작업 상황을 쉽게 확인할 수 있었다.

  • 문제 상황의 빠른 공유
    테스트케이스를 꼼꼼히 따져가며 확인하는 팀원분이 문제가 있을 때마다 문제를 빠르게 공유했다. 덕분에 비교적 어려운 문제를 집단지성으로 빠르게 해결할 수 있었다.

바꾸고 싶은 것

  • 브랜칭 정책 세분화
    master브랜치에 풀 리퀘스트 머지를 한 이후 오류를 해결하기 위해 팀 전체가 진땀을 흘렸던 경험을 했다. test와 같은 브랜치에 머지한 후 디버깅을 한 뒤 master 브랜치로 옮겼으면 더 나았을 것이라 생각한다. 유명 기업들의 기술 블로그를 보며 브랜치 전략을 벤치마킹하는 것도 좋을 것 같다.

  • 디버깅 전략 부재
    실행 오류가 나고 오류를 쉽게 찾을 수 없을 때, 나만의 디버깅 전략이 없었기 때문인지 쉽게 당황하고 다른 팀원의 도움을 받아야 했다.

  • 원격 협업 전략
    이메일이나 슬랙 메세지 등을 다른 팀원보다 늦게 확인하는 경향이 있었다. 다행히 이번 미니 프로젝트는 바로 옆자리에 있는 팀원들이 말로 바로 전달해 주어 큰 문제가 되지 않았다. 개인 작업에 집중하면서 너무 늦지 않게 알림을 확인할 수 있는 전략이 필요하다고 느꼈다. 예를 들어, 포모도로 휴식 세션이 끝난 직후 알림을 확인하고 일 우선 순위를 바꾸는 루틴을 추가해보는 것이다.

  • 지저분한 코드
    시간 내에 구현하는 것에 매몰되어 있다보니 코드의 질이 현저히 낮아졌다. 파이널 프로젝트에서는 미니 프로젝트보다 큰 규모의 코드를 작성하게 될 텐데, 코드의 질이 낮아지면 나중에 다른 기능들을 추가하거나 디버깅, 유지보수 단계에서 문제가 될 것같다는 생각을 했다.

——————————————————————————

0개의 댓글