일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- TMDB
- 배포
- Protocol
- JavaScript
- http
- HTML
- jQuery
- Database
- REACT
- supabase
- useEffect
- CSS
- bootstrap
- IntersectionObserver
- url
- Github Pages
- web
- this
- Boostrap
- til
- API
- firestoredatabase
- db
- nosql
- SQL
- Fetch
- github
- data
- Cloud
- W
- Today
- Total
072DATA
`끄적끄적` 팀 프로젝트 기획 1일차 본문
안녕
오늘은 팀 프로젝트를 기획한 내용을 토대로 요약 정리 하겠습니다.
프로젝트 제목 / 간단 설명
- 프로젝트 제목
- 어?그로그램
- 프로젝트 설명
- 유저간의 취미를 공유할 수 있는 웹페이지
- 뉴스피드 형식으로 게시 글을 자유롭게 읽을 수 있음
프로젝트 제목과 프로젝트의 주제를 설정하여 취미 공유 커뮤니티를 만들어 볼 예정입니다.
기능정의 및 폴더 구조( 간단하게)
`
로그인 / 회원가입
로그인 기능
회원가입 기능
게시판 CRUD
글 작성
글 삭제
글 조회
글 수정
마이페이지
프로필 수정
나만의 게시 글
src/
├── components/
│ ├── commons/
│ │ ├── BoardList.js
│ │ ├── BoardCard.js
│ ├── Auth/
│ ├── Login.js
│ ├── Register.js
├── pages/
│ ├── Main.js
│ ├── Join.js
│ ├── Profile.js
│ ├── Board/
│ ├── BoardWrite.js
│ ├── BoardUpdate.js
각 페이지 별로 간단한 기능 정의를 작성하였고
해당 기능에 따라서 폴더 구조 또한 작성하였습니다.'
기억에 남았던 회의
팀의 컨벤션에 대한 회의를 하던 중 git branch 전략에서 branch를 만들 때 단위를 어느 정도로 하는지 좋을지에 대하여
페이지 단위로 branch를 따자 vs 보다 작은 단위 예로 들어 Board의 Update기능으로 따자
이렇게 의견을 나누었고 작은 단위로 branch 따기로 결정 하였습니다
해당 결정에 대한 이유
충돌 최소화
작업 단위를 작게 나누면 브랜치가 작아져서 병합 시 충돌 가능성이 줄어듭니다
작은 단위의 변경 사항만을 포함한 브랜치는 충돌이 발생했을 때 해결하기가 상대적으로 더 쉬운 반면
큰 단위의 브랜치는 여러 가지 변경 사항을 포함하고 있어 충돌이 발생하면 해결이 복잡해질 수 있습니다
.
작업 명확성 증가
작은 단위의 브랜치는 특정 기능이나 버그 수정에 집중하므로, 작업 내용이 명확하고 관리하기 쉬워지는데
예를 들어 BoardUpdate와 같은 기능별 브랜치는 어떤 기능이 개발 중인지 또는
어떤 버그가 수정 중인지 분명하게 알 수 있기에 코드 리뷰 및 커뮤니케이션에도 도움이 됩니다
협업 효율성 향상
팀원들이 동시에 여러 기능을 작업할 때 작은 브랜치는 각 팀원이 자신이 맡은 기능에만 집중할 수 있게 해주며
브랜치가 작으면 여러 명이 동시에 작업하더라도 브랜치 간의 충돌이 줄어들어 협업이 원활해질 수 있습니다.
마치며
이렇게 오늘 프로젝트를 기획하고 팀 회의를 하면서
회의만으로도 실력이 늘 수 있다는 것에 놀랐습니다.
서로 다른 의견이 오가거나 더 나은 방향성을 제시하고
어떻게 하면 더 원할히 협업을 이룰 수 있는지 고민해보면서
"내가 점점 개발에 대한 열정이 커지는구나" 하고 느끼는 하루였습니다!
내일도 오늘처럼 즐거운 개발이었으면 싶네여!! 끝