개발 진행 순서
- S.A 작성 시에 필요한 내용을 다음 순서에 맞춰 빠르게 정합니다.
a. 프로젝트 기획
b. 필수 기능, 부가 기능 (우선 순위)
c. 역할 분담
d. 개발 일정
→ 기능 별 마감 기한, 브랜치 최종 병합 날짜 반드시 정해주세요.
→ 마감 기한까지 완수하지 못했을 때, 그 부분을 누가 담당할 것인지도 미리 이야기해두면 좋습니다.e. ERD 작성
f. repo 만들고 브랜치 어떻게 나눌지 정하기
g. 와이어프레임 - 1번을 토대로 S.A 작성을 빠르게 끝내고 초안을 튜터님한테 검토 요청드립니다.
- 피드백을 반영하여 S.A 완성 후 제출하고 바로 개발에 들어갑니다.
S.A 작성 방법
- 프로젝트 소개
- 서비스 기획, 배경
- 서비스 구성
- 기능 구성
- 역할 분담
- DB 테이블
- 와이어프레임
- 아키텍쳐
- 커밋메시지 컨벤션
- 우리 조만의 커밋 메세지 컨벤션을 정해서 커밋을 해주세요.
- [추가], [수정], [변경], [add], [modify], [fix] 등의 말머리
- 말머리 뒤에는 핵심 내용만 간단하게
- ex.
- [add] 로그인, 회원 가입 추가
- [fix] 소셜 로그인 오류 수정
- [추가] info app 정보 페이지 추가
- 브랜치 관리
- 일반적으로 master(main) branch - develop branch - 기능별 branch로 나눕니다.
- 이렇게 나눌 경우 브랜치가 너무 많아진다면, master(main) branch - develop branch - 개인별 branch로 나눠주세요.
- 브랜치를 상위 브랜치로 병합 완료 했다면, 해당 브랜치는 일정 기간 후에 반드시 삭제해주세요.
- 일반적으로 데브 브랜치를 메인 브랜치처럼 생각하고 병합한 뒤, 최종 병합만 메인 브랜치에 해주시면 됩니다. 그전까지 메인 브랜치는 건들지맙시다!
- (주의) 항상 브랜치 위치를 잘 파악해두고 다른 사람 브랜치나 데브 브랜치에 아무 생각없이 커밋 푸쉬하는 일이 없도록 합시다. 되도록이면 PR을 사용해주시고, 브랜치 병합 전에 꼭 모든 팀원들에게 미리 알리고 병합하면 좋을 것 같아요
- 일반적으로 master(main) branch - develop branch - 기능별 branch로 나눕니다.
작성 TOOL
- 프로젝트 문서화 - Notion
- 프로젝트 기획과 관련된 내용 위주로 작성
- 기획 배경, 기획 의도
- 서비스 타겟
- 기대 효과, 프로젝트 확장성
- 역할 분담 + 팀 소개
- 개발 일정 (스프레드시트 간트 차트 템플릿 이용)
- 사용자 피드백 결과 + 개선 사항
- 프로젝트 시각화 - Figma
프론트엔드 참고 사이트
디자인 스킬
아이콘
폰트
부트스트랩, 테일윈드
디자인 레퍼런스
발표
피피티 템플릿
회고
잼보드
코드 리뷰
- 주석 처리를 잘하자
- 코드 리뷰는 보통 프로젝트 진행 중에 핵심 기능 PR 전이나 브랜치 병합 전 진행
- 물론 프로젝트 중간에 코드 리뷰를 하면 매우 좋지만 여유가 안될 때는 회고 후에 꼭 하고 넘어갑시다!
- 회고를 위한 코드 리뷰의 목적
- 본인이 맡은 부분을 제외하고 제대로 알고 지나가기 어려움
→ 다른 파트 구현에 대해 대략적으로도 알 수 있도록 공유 - 설명하면서 부족한 부분 파악 → 보충 학습할 부분 파악 가능
- 본인이 맡은 부분을 제외하고 제대로 알고 지나가기 어려움
유지/보수
- 회사에서 유의미한 프로젝트를 판단하는 기준
- 만들고 끝인 토이 프로젝트는 무의미하게 생각함
- 운영 경험 또는 유지·보수·개선 경험을 중요하게 생각
- 이런 것들을 해보세요
-
코드 리뷰를 통해 개선할 점을 파악하고 추가로 구현해보기
-
완성하지 못한 부분을 끝까지 구현해보기
-
그밖에 추가로 넣고 싶었던 기능 구현해보기
→ 그리고 이런 것들을 했다면 반드시 github issue에 기록을 남겨주세요.
-
