[TIL] 프로젝트를 시작하며

오늘부터 새로운 항해를 시작했다.
부트캠프 이제 지겨운데 그래도 빠르게 팀플을 해볼 수 있다는 점에서 나쁘지 않은 것 같기도 하고..
지금까지 했던 방식과는 다른 방식으로 접근해보고 싶었다.
예전에는 기능 구현하는데 급급하고, 팀원들을 설득시키느라 진을 다 뺐는데
이제는 그냥 내가 빠르게 리딩하고 환경셋팅까지 마무리 해놓고 설명하는 방식으로 진행했다.
그래서 속도감있게 진행되었고.. 덕분에 여유롭게 오늘 하려고 했던 일을 마무리할 수 있었다.
팀장이라 가능한 것도 있겠지만 팀원들도 잘 따라와줘서 고마웠다.

기억나는 팀플만 열한 번째... 이젠 메뉴얼이 생겼다.

이 짓도 반복되다보니 패턴이 생기더라.
그래서 내가 팀플을 시작하기에 앞서 꼭 하는 짓들이 있다.
오늘은 내가 팀플을 진행 하는 루틴에 대해 써보고자 한다.

0. 자기 소개

• 오글거리지만 자기 소개 타임을 가진다.
  • 서로의 기술에 대한 이해도와 프로젝트를 통해 이루고자 하는 목표를 파악하기 위함이다.
  • 그리고 경험상 어느 정도는 친밀감이 형성되어야 소통에 드는 비용이 줄어든다.

1. 요구사항을 구체화 한다.

• 만들어야 할 것이 무엇인지 논의하며 파악하고, 이 과정에서 API를 설계하고 화면 구성을 한다.
  • 이 때 어떤 uri와 HTTP methods로 어떤 요청을 보내고 어떤 응답을 할 지에 대해 논의한다.
  • 어디까지를 MVP로 두고 추가 기능은 어떤 우선순위로 둘지 의논한다.
  • 문서화는 어떤 것을 이용할지? Swagger / Postman / Redoc
  • 만약 인증 기능이 들어간다면 어떤 식으로 할지
    • JWT / localStorage / Cookie / Session
    • 만약 accessToken을 쓴다면 refreshToken을 쓸지 말지, 쓴다면 어떤 식으로 구현할지
• figma를 이용하여 wire frame을 만든다.
  • 어떤 url에서 어떤 페이지를 보여줄지, 어떤 기능이 있는지 유저 스토리를 생각하며 만든다.
  • 유저 스토리를 기반으로 기획을 논의하면 예외 처리를 어떻게 할 지에 대해서도 좀 더 구체화가 되는 것 같다.
• 데드라인과 기술 스택을 정한다.
  • 기술 스택을 정하기엔 이른 감이 있긴 하지만, 팀원들이 어떤 언어와 라이브러리/프레임워크에 익숙한지를 파악하고, 언제까지 기능을 구현해야하는지 기한을 고려하여 기술 스택을 정하는 편이다. 빨리 정할 수록 그 언어/프레임워크/라이브러리에 익숙하지 않은 동료가 빨리 공부를 시작할 수 있다.
• DB modeling
  • 테이블을 설계한다. 이 때 NoSQL인지 RDB인지에 따라 조금 방식이 다른데, 꽤 시간을 많이 잡아먹는 부분이다.
  • 어디까지 정규화를 할지, 가끔은 반정규화를 허용 할지 이런 것들을 고민한다.

2. 협업 룰을 정한다.

https://pro-yomi.tistory.com/103

[Clean-Code] 클린코드 제안서

• Code convention을 정한다.
• Git 
  • Commit message Convention을 정한다.
  • PR / issue template을 만든다.
  • branch strategy를 정한다.
  • branch 규칙을 적용한다. (머지할 때 PR 날려야 하고 Approve 2명 이상) 
  • 코드리뷰 필수

Commit convention

3. 프로젝트 셋팅

• lint / prettier 설정
• 패키지 매니저를 정한다. (yarn을 쓸지 npm을 쓸지.. poetry를 쓸지 pipenv를 쓸지 venv를 쓸지 virtualenv를 쓸지 등)
• 디렉토리 구조에 대해 이야기 하며 어떤 아키텍처로 구성할지 고민한다.
  • 근데 디자인 패턴을 좀 더 공부할 필요성이 느껴진다.
  • 클린 아키텍처도 더 읽어야 하고... (예전에 토스 컨퍼런스에서 비슷한 내용이 나와 재미있었음)
  • 헥사고날 아키텍처에 대해 더 알아보고 싶다.
• 어떤 방식으로 배포할지에 대해 고민한다.
  • aws ec2를 쓸지 lambda를 쓸지 heroku를 쓸지 그냥 라즈베리 파이 띄워서..
• 그 외
  • CI/CD는 언제쯤 적용할지
  • Test code는 어떤 식으로 / 얼마나(unit test 레이어별로? E2E만?) 짤지

 

4. 구현

말이 필요 없다. 그냥 브랜치 파서 계속 구현하고 PR올리고 코드리뷰 받고 머지하고 무한반복

앞에서 이미 규칙을 다 정해놨으면 그 뒤로는 조금 수월해진다.

아무래도 소통의 비용이 줄어들어 생산성이 올라가는 효과가 있는 것 같다.

 

 

5. 회고

• 무사히 배포되어 돌아가는 서비스를 보며 회고를 한다.
  • 리팩토링할 부분 / 개선할 부분은 없는지
  • 더 추가할 기능은 없는지
  • 버그는 없는지? (테스트코드 && QA 필수)
  • 어떻게 하면 서버비를 줄일 수 있을지