오늘은 세부적인 코딩 컨벤션 및 첫번째 PR에 대한 리뷰 회의를 진행했다.
eslint config
이번 프로젝트에서는 air-bnb 스타일로 convention을 설정했는데 생각보다 엄청 타이트하다. 그래서 기본 설정중에서 몇개의 설정을 off 했다.
"import/extensions": "off",
"import/prefer-default-export": "off", import/extensions 은 다른 파일을 import할 때 경로에 대한 설정이다. on일때는 상대경로는 허용하지 않는다. off일때는 상대경로를 허용한다.
import/prefer-default-export는 export에 대한 설정이다. on일때는 export default만 허용하고, off일때는 export를 허용한다.
foldering
Redux를 사용하지 않고, SWR과 context-api를 사용하게 되면서, 기존과는 다른 방식의 foldering이 필요했다. 일단 우리 팀에서 정한 방법은 아래와 같다.
src
|--features
|----feature
|------index.tsx
|------api.ts
|------hooks.ts
index.tsx파일은 이 기능의 메인 페이지이다. index.tsx를pages안에 있는 각 기능의 페이지 파일에import시키는 방식으로 router를 구성한다.api.ts는 해당 기능에서 사용하는end-point들과type들이 명시된다.hooks.ts는 해당 기능에서 사용하는 custom hook들이 명시된다.
github issue
프로젝트의 현황을 관리할 수 있는 많은 툴들이 있지만, 아직 프로젝트의 규모가 크지 않고 정보의 분산을 최소화 하고자 github에서 제공하는 issue와 project 기능을 이용하기로 했다.
page를 기준으로 milestones 을 작성하고, 그 안에 feature를 기준으로 issue를 작성한다. 그리고 더 세부적인 작업은 issue 안에서 task로 작성한다.
milestones 는 그 안에 속한 issue 들의 완료 현황을 보여주기 때문에 작업 완료 현황을 따로 기록하지 않아도 쉽게 조회 할 수 있다.
rendering 방식에 대한 고찰
Next.js로 프로젝트가 빌드가 되긴 했지만, 더 효율적이고 최적화된 성능을 위해 rendering 방식에 대해 고민해보았다. 1차적인 결론은 CSR로 구현하는 것이다. 내가 구현하고자 하는 페이지의 기능은 SSR의 장점이 전부 필요 없는 페이지 이기때문이다.
다만, 이럼에도 불구하고 아직 수치적인 성능 비교를 해보지 않았기 때문에 SSR을 완전히 배제한다기보다는 향후 성능 테스트를 통해 결정하기로 했다.
code review
우리 팀원이 고맙게도 코드 리뷰를 해주었다. 처음 받아보는 피드백이라 기분이 좋았다.
