주제
스터디/프로젝트 구인 서비스를 간단하게 만들어보기로 했다.
간단할 줄 알았는데 꽤 규모가 컸다!
걷는 기간이라면서 오토바이보다 빠르게 경보해야 될 것 같다는 느낌이 들었다.
5일만에 할 수 있을까 싶지만 해봐야 알 것 같다!
Wireframe
주제가 정해지고 회의를 통해 얻었던 간략한 정보들로
wireframe을 우선 만들었다.
최대한 만들고 api문서<->와이어프레임 간의 상호작용을 통해 개선해나가면 될 것 같다.
사실상 디자인을 하게 되었는데 와이어프레임은 정말 틀 뿐이라 개발이 어려울 것 같아
이왕 하는 김에 두개를 다 만들기는 시간이 없어서 디자인처럼 구성했다.
개발 백로그 만들기
항상 느꼈던 힘들었던 기분은 이렇게 뭔가 주제를 정하고 프로젝트를 진행하려 할 때
당장 뭐부터 해야될지 감이 안잡혔다는 것이다.
협업 시 issue 발행도 생략하였고 칸반보드 사용 같은 이슈트래킹을 따로 하지 않기 때문에
팀 간의 진행상황 공유나 앞으로의 계획 등을 알기 어려울 것 같아
개발 백로그를 작성하였다.
이런 식으로는 처음 작성해보았는데 더 구체적이어야 할 지 추상적이어야 할 지 감이 오진 않는다.
개발을 진행하다가 길을 잃지 않을 수 있는 이정표 역할 정도는 충분히 할 것이라고 믿었다.
협업
team ground rule
코드, 프로젝트도 중요하지만 그걸 하는 건 사람이다.
언제 얼마나 반드시 개발에 몰두하는 시간을 가질지, 언제 간단한 회의, 회고를 진행할 지
언제 낮잠시간을 가질지 회의하여 선정했다.
낮잠의 경우 프로젝트 이야기를 꺼내지 않고 휴식을 보장받을 수 있는 시간이 있으면 좋지 않을까 생각해서 제안했다!
리액트 상태관리 하다가 팀원이 unmount 되는 일은 없어야 된다고 생각한다.
code convention
클린코딩 규칙 등 퀄리티적인 룰들을 적용하기에는 아직 많이 부담스럽다.
프로젝트를 위한 가장 큰 목표는 완성해야 되는 것을 제 시간안에 완성하는 것이기 때문에
읽기 좋고 사용하기 좋은 코드인지 생각해보자는 식으로만 규칙을 정했다.
그 외에 프로젝트를 위한 폴더구조를 어떤식으로 형성할지 최소한으로 정했고
최소한의 eslint 설정과 명확한 코드 포맷팅을 위한 prettier 설정을 했다.
파일 import 순서도 설정하면 좋을 것 같긴 한데 시간이 많이 들 것 같아 생략했다.
git 협업
gitflow 브랜치 전략 그대로 협업하지는 않더라도
최소한의 commit, branch convention을 설정하고 지키도록 노력하는 방향으로 정했다.
저번주에 멘토님이 깃허브 위키 사용을 적극적으로 권장해주셔서
위키에 정리하여 작성했다.
1:1:1 code review, 1 issue 1 pr 등 해보고 싶은 것이 많았지만
시간과 분량을 생각해서 issue 발행은 생략했고 pr 내용도 자율적으로 작성하기로 했다.
코드 리뷰도 우선 형식적으로는 받기로 하였지만 상황에 맞게 유동적으로 진행할 것 같다.
백엔드 협업하기
프론트엔드 개발은 백엔드 API에 굉장히 의존적이기 때문에
끊임없는 소통이 오가야 하는 것은 필수라고 생각한다.
그렇게 해도 실제 프로덕션 환경에서 연동해봤을 때 온전하지 않을 확률이 높을 테니까
백엔드 분들에게 API문서, 도메인 제약조건, ERD 의 추가 변경에 대해서는
꼭 알려달라고 말씀드린 것 같았다.
사실 이정도만 잘 볼 수 있다면 충분하다고 생각했다.
배포-개발 환경 차이에 대한 불확실성 제거를 해보고 싶다
json-server를 사용하여 의존도를 줄인다고 하지만
저번주에 사용해보고 문서도 확인해보니 제약이 많다는 생각이 들었다.
우리가 정한 api명세가 있지만 json-server에 기본적으로 구현되어있는 api의 명세는 달랐다.
또한 json-server의 경우 응답이 모두 일정하고 가짜 db파일에 의존하게 되는데
실제 어떤 api의 응답들은 반드시 그런 내용들만 포함하고 있지 않다.
예를 들면 access token 같은..
validation도 체크해볼 수 없다. 내부적인 로직에서 검증하는 것 자체가 구현되어있지 않으니까
이런 부분에서는 msw가 어렵긴 해도 좀 더 좋지 않을까 싶었다
todolist 같은 단순한 crud에서는 좋지만 이렇게 조금만 비즈니스가 복잡해져도
사용이 쉽진 않은 것 같다는 것을 느꼈다.
json-server로 최대한 백엔드 개발 단계에 의존하지 않고 싶었고
팀의 프론트 개발 진척에 영향이 없었으면 좋겠다고 생각해서
json-server의 api들을 필요한 만큼 직접 커스텀해보려고 한다.
axios로 요청하면 정말 api문서대로 응답할 수 있도록...
