금일 기동팀+무민팀+마크팀 합동 커피챗에서 팀 프로젝트 시작에 많은 도움이 될 수 있는 내용이 많이 나와 공유드립니다~ 참고 링크를 잘 활용해보셔유~
[1기-B]윤승록(기동팀)
[2021-10-14 기동팀, 무민팀, 마크팀 커피챗 요약]주제: 팀 프로젝트를 진행 시 알아야 할 점 - 협업의 방법내용: 기획단계 →아이디어 →API 구현, → 프론트에서 개발을 할 때는 어떻게 해야 하는가팀은 보통 보통 2(FE)+2(BE)+2(DE) 로 구성이 된다.기획서 작성
- The Idea
- 배경
- Target층을 설정하는 것이 정말 중요하다! (20대 개발자를 하고 싶은 주 타겟층인지...)
- 타깃 고객 및 사이즈
- 기대효과
- 역할분담
- 보통 기획 및 디자인
- 프론트
- 백엔드
- 프로젝트 매니저
그렇다면 실제 사례가 궁금한데요?그래서 DND의 사례를 보도록 하자.참고: https://github.com/DNDACADEMY/dnd-notice/wiki[기획단계]1. 주창하는 가치 및 정체성 확립공통 키워드를 뽑아내고 필터하는 과정을 통해서 슬로건과 키워드!를 뽑아내서 로고를 제작2. 해당 정체성을 기반으로 메인 컬러를 결정했다.
- 컬러시스템은 개발자들이 주로 사용하는 코드에디터에서 추출해낸 컬러를 사용함.
3. 세부적인 기술 스택 선정
- 상태관리 (Redux, ContextApi, useSwr, mobx)
- css : css? scss? styled-component? emoitions?
- 프레임워크, 라이브러리
등등...4. 전체적인 아키텍처구조를 설정[협업 준비단계]5. 각 분야별로 협업 준비를 한다.→ 프론트엔드는 Eslint 와 Prettier에 대한 합의를 먼저 진행한다.
- 프론트엔드 개발 팀 내 공동의 코딩 컨벤션을 설정함으로써 협업을 원활히 한다.
6. 네이밍 컨벤션, 디렉토리 구조 설정7. 협업을 어떻게 할지 (git 에 대한 약속 규칙!)
- ex) 이슈베이스 기반의 개발을 하자
- 이슈 생성!을 해야하는데 이슈 생성은 어떤식으로 할건지? 타이틀은 어떻게 할건지? 이슈의 설명은 어떻게 할 것인지?
- 템플릿을 사용을 하자!
- 이후 이슈생성 → 이슈번호 기반 브랜치 생성 → ex) feature/23/login-create
8. Commit에 대한 규칙을 수립한다.
- 일관된 커밋을 하기 위한 툴: https://blog.dnd.ac/github-commitzen-template/
9. Pull Request에 대해 정해진 규칙을 사용하는 것이 좋다!
- 템플릿을 만들어서 레포에 저장해 둘 수 있다.
- 기동님의 DND 블로그 글을 참고하자.
[개발단계]10. 요구사항 명세
- 서비스에 필요한 기능 명세
- ex) 로그인 기능, 인증 기능 etc.
11. 와이어 프레임 작성을 통해 전반적인 디자인의 흐름을 파악한다. (Figma) 사용을 많이 한다.12. 프론트 개발 수행정말 디자인이 힘들 때만 보기: https://ant.design/
- Typography 정하기
- Button 정하기 ...
- 이 외에도 다양한 요소들에 대한 규격을 정해놓고 사용하면 좋다.
- 현업에서는 '운영'이라는 요소와 '디자이너'의 존재로 인해, UI 프레임워크를 차용하기보다는 하나하나 만들어서 사용하지만,
- 사이드 프로젝트에서는 개발 기한이 짧기 때문에 이런 UI 프레임워크를 사용하는 것도 개발 기한을 줄이고, 퀄리티를 높이는 데 좋다.
이제 본격적인 개발을 시작할 수 있다.13. 또한, git Branch 전략 ( git flow )을 사전에 수립해 놓고 숙지해 두면, 매끄러운 협업이 가능하다!
- 기동님의 DND 블로그 글을 참고하자.
- git checkout -b develop : 보통 develop branch 에서 모든 개발이 이루어진다.
- 하지만 develop 브랜치에서 바로 개발하지 않고, develop → 이슈베이스 기반의 하위 브랜치 파생 후 개발
- 이후 develop으로 PR을 올린다. 이 시점에서 코드리뷰가 이루어지는 것
- ex) feature/66/modal-component/create 브랜치에서 이루어진 개발을 develop 브랜치로 PR을 올리고, 리뷰되고, 승인하여 병합되고...
- 충분히 개발이 되고 나서는 main 으로 PR을 올릴 수도 있겠지
- git merge / rebase ... 등등의 명령어들을 그 때 그 때 찾아서 사용하자.
- 보통 master → develop → feature 의 브랜치 구조를 가지지만, hotfix는 급하기 때문에, master → hotfix 형식의 브랜치 구조를 가지고, 문제가 해결이 되면 그제서야 develop 에 적용이 된다.
- 보통은 master브랜치가 운영되고 있는 브랜치인데, release 브랜치는 master로 가기 전에, develop된 소스들 중, 검증된 특정 시점까지의 소스를 잡아서 테스팅하는 브랜치가 release.
- 즉 , master (운영) || release (어느 정도 검증된 소스 개발자+디자이너+PM 가 참여하여 테스팅을 거치면서, 만약 수정사항이 있으면 바로바로 커밋을 한다. 충분히 테스트가 되면, 그제서야 master branch 가 되는 것. ) || develop (개발중)
- 어, 그런데, release에서 commit된 내용들은 develop에는 적용이 안되있잖아? 그래서 release는 master와 develop, 두 곳에 PR해준다.
- 배포 버전에 대해서 태그를 달아두어서 gitHub 내에서 특정 배포 시점을 찾아갈 수도 있다.
[배포단계]14. 배포준비 및 배포
- netflify
- heroku
를 이용해서 상대적으로 쉽게 배포를 해볼 수도 있다.또는 amazon (ec2 free tier), serverless, lightsail(가볍게 돈 내고 배포)를 이용해 볼 수 도 있다.[추가]ContextApi 강추, CSS에서 컬러값은 미리미리 변수화해놓자.ThemeProvider를 사용해보자! 테마를 쉽게쉽게 넣을 수 있을 것이다!