📜 프로젝트 문서
FEDC4_HONKOK_JunilHwang
prgrms-fe-devcourse • Updated Oct 20, 2023
💻 프로젝트 컨셉 및 목표
사용자를 정확히 타겟팅을 하는게 좋은 것 같아요! 몇 번 서비스를 만들어보니까 처음에는 대상을 확실하게 정하고 그 사람들에게 우리가 제공해줄 수 있는게 무엇인가를 고민해보는 경험이 무척 중요하다고 느끼는 중입니다 ㅎㅎ
“이 프로젝트를 통해서 우리가 달성하고 싶은 목표”
- 팀의 목표
- 기능을 완벽하게 구현하자
- 모두 다 구현 하고 싶다 (건우님)
- 개인의 목표
지금 당장 명확한 목표가 없다면, 고민을 시작해보자.
- 단순히 프로젝트를 잘 만드는 것 말고,
“학습적인 목표”
ex) 컴포넌트 다운 컴포넌트를 만들어보자
ex) 테스트 코드를 작성해보자
ex) 스토리북으로 다양한 컴포넌트를 테스트할 수 있도록 해보자. ( 예를들어 컴포넌트 10종에 대해 테스트를 한다거나)
이 프로젝트를 수행 했을 때, 나는 “어떤” 상태가 되고 싶은지.
✅ 프로젝트 구조 및 설계
API Client
- API Client가 여러개일수도 있다는 가정. 지금은 한 개의 apiClient를 만들어서 사용 하는데, 범용적인 이름과는 무관하게, 특정 API를 가르키고 있다. 사용하는 입장에서 조금은 헷갈릴 수 있지 않을까.
의존 하는 방향이 한 방향으로만 (단방향) 흐르도록 하기
- index를 적극적으로 활용하기
- import를 보고, 현재 클래스나 현재 함수나 현재 파일이 어떤 패키지나 폴더에 의존적인지 한 눈에 파악하기
- 계층이 한 방향으로 흐르도록 만들어주기
- 양방향 의존 하지 않기
비슷한 관심사들끼리 묶어주기
- 비슷한 성질의 일을 한다고 해서, 한 곳에다가 파일을 몰아놓지 말기
- 모든 상수를 한 곳에 모아놓지 않기.
- 상수의 스코프를 생각하기.
- 이 상수가 어떤 영역에서 쓰이는가.
- 해당 영역에다가 위치시키면 더 좋지 않을까.
🛠️ 기술 스택 및 협업툴
- 노션에서 한 번에 볼 수 있도록 하기
- github project 활용 하는 것 → 좋은 방법 이라고 생각. github에서 보기에도 쉽고
- 각 티켓에 대한 사용자 스토리
- 스토리에 대한 티켓을 만들고
- 해당 티켓에 대한 서브 티켓 같은 것들을 만들어서 관리 해주면 어떨까?
- 노션과 깃허브를 계속 왔다갔다 하면서 볼 때 컨텍스트 스위칭이 자주 발생하다보니, 한 곳에 몰아놓고 확인하면 어떨까?
- nextjs 안 쓰는 이유? → 가볍게 하기 위해서
- 배포 → vercel에 할 예정
- 스토리북도 배포해서 관리해보자 → 크로마틱 활용
- develop에 머지 되면 자동으로 크로마틱에 배포되도록 만들어보기
- 내가 만든 컴포넌트가 추가되고, 스토리가 추가되면, 다른 팀원들도 그걸 확인해볼 수 있도록 해보자.
- 어떤 식으로 내가 만든 컴포넌트를 활용할 수 있는지.
- 스토리북에다 기능을 만들다보면 사이드 이펙트에 대한 고민도 하게 되고
- 자연스럽게 어떤게 좋은 컴포넌트인지 고민을 하게 된다.
🗓️ 일정 산정 및 관리 방법
- “스프린트 기간” 만 정해놓고, 정확히 어떤 기능을 언제까지 할 것인지를 명시한 곳이 없다.
- 어떤 기능에 대한 우선순위 정도는 있는데, 어떤 순서로 작업을 할 것인지와 해당 작업이 얼마나 걸릴 것인지 등도 필요하지 않을까?
- 예상 일정과, 실제 일정에 대한 비교도 해보자.
- A라는 기능이 1일 정도 걸릴 것 같았는데
- 실제로 해보니까 2일 정도 걸렸다.
- 이 차이가 왜 발생 했고, 다음에는 어떻게 하면 더 개발 시간을 단축할 수 있을까?
- 경험치를 쌓아가는 것
- 기능 개발을 할 때 어떤 점들을 고려해야 좋은지. 일정 산정에 대한 연습을 하다 보면 부가적인 일들이나 어려운 난이도가 될 법한 일들에 대한 고민을 자연스럽게 하게 된다.
- 병렬로 할 수 있는 것들
- 직렬로 해야만 하는 것들
- 블록킹 작업이 될 것 같은 것들
- B라는 작업을 하기 위해선 A를 먼저 끝내야 되는데, A에서 뭔가 문제가 생겨서 B가 진행이 안 되고 있네 → 블록킹
- API가 먼저 만들어져야 내가 뭔가 작업을 할 수 있을 것 같은데, API 없이 개발 하는게 되나?
- 답은, 가능 하긴 하다.
- API가 분명히 존재했었는데, 어떤 이상한 사람이 한번에 10000개의 요청을 날려서 서버가 터져버렸네… 어떡하지? 나 작업해야 되는데?
- 어떤식으로 우리가 블록킹 상황에 대해 대응할 것인가
- 필수 요구사항과 선택 요구사항
- 이 기능은 꼭 필요해!
- 이 기능은 있으면 좋은데, 없어도 사실 무방할 것 같아.
👥 협업 방식
- 목적을 달성하기 위한 수단이 적절한가?
- 우리의 목적은 무엇인가?
- “커뮤니케이션을 할 때 목적이 중요하다”
- 회의를 왜 해야 되지?
- 우리가 이 회의를 통해서 얻어가고자 하는게 뭐지?
- 회의가 끝났을 때 어떤 산출물이 나와야 하지?
- 회의를 시작하기전에 어떤 것들을 우리가 준비해야 하지?
- 회의 시간을 어떻게 줄일 수 있지?
- 어떻게 우리가 조금 더 발언을 잘 하게 만들 수 있지?
- 회의가 끝난 다음에 어떤 액션을 취해야 되지?
- 그 액션이 정상적으로 되었음을 언제 체크해야 되지?
- 결국에는 회의를 하거나 커뮤니케이션을 할 때 어떤 것들을 내가 준비해놓고 전달해야 좋을까?
- 어떤 말을 해야 조금 더 진정성이 있을까?
- 어떤 도구가 있으면 조금 더 잘 전달할 수 있을까?
- 공부는 혼자 할 수 있지만, 커뮤니케이션은 혼자 불가능하다.
- 어떻게 우리가 커뮤니케이션을 해야 좋은지에 대해서는 프로그래머스를 하는 동안 계속, 지속적으로, 항상 생각해보면 좋다.