프로젝트 중간 점검(동영 멘토) (1)

기획

1. 2JAVATAYO를 기획하면서 가장 공들인 콘셉트는 무엇인가요? (차별화된 특징은 무엇인가요?)
• 이전 커피챗에서 사용자에 대한 검증 시스템이 차별점이라고 했는데, 검증 시스템의 진입 장벽은 어떻게 해소할 것인지 대책은 마련되어 있나요?
• 해당 검증 시스템이 정착하기까지 필요한 기반 데이터 수집
• 그 전까지는 이 서비스의 특징을 무엇으로 내세울 것인지?
• 다른 사용자의 평가가 없는 신규 유저에 대한 진입 장벽
• 흔히 ‘고인물'이라고 하는 기존에 검증된 사람’만' 수요로 하는 문제
• 개인적인 감정에 의한 평가 시스템의 붕괴 (단순한 점수를 척도로 평가 시스템을 구축할 경우 이런 문제를 맞이할 가능성이 더 높아집니다.)
• 예시가 궁금하시면 알려주세요. (예시 썰풀이 가능)

2. 기능 요구사항과 인수 조건 같은 프로젝트 달성 목표는 어떻게 관리되고 있을까요?
• 발표 영상에서 진척도라는 표현을 자주 사용하셨는데, ‘진척’을 알기 위해선 ‘목표 A 대비 현재 B만큼 진행되었다’라는 기준이 있어야 합니다.
• 이전에 Issue를 TODO처럼 사용하라고 말씀드렸는데, 그게 기능 요구사항을 대체할 수 있다는 의도로 말씀드린 내용은 아니었습니다. 오해 없었길 바랍니다…
• 제가 좋아하는 양식은 ‘유저 스토리’인데요. 꼭 유저 스토리가 아니라도 ‘시용자는 로그인을 할 수 있다’ 같이 단언하는 형태의 문장만 되어도 좋습니다.
• 사용자가 로그인을 할 수 있다는 기능 요구사항을 만족하기 위해 기술적으로 API 통신을 진행해야 한거나, 전역 상태 관리를 해야 한다거나 등의 세부적인 태스크로 구분할 수 있고 이것을 하나의 이슈(작업 단위)라고 볼 수 있습니다.

기술

1. .eslintrc.json과 package.json 속 eslintConfig
• 우선 순위로 인해 .eslintrc.json 파일을 설정 파일로 사용합니다. eslintConfig는 불필요하니 제거해주세요.

2. package.json 속 husky
• 제가 알기로 package.json에 husky 필드로 설정하는 방식은 5버전 이후로 deprecated된 방식으로 알고 있습니다. 역시 불필요한 속성입니다.

3. .ts와 .tsx 구분
• 컨벤션의 영역으로 볼 수도 있는 부분인데, 저는 해당 파일에서 JSX 구문을 리턴하는 경우 .(t|j)sx로 생성하고, JSX 구문이 포함되어 있지 않은 경우 .(t|j)s로 생성합니다.
• 현재 프로젝트 파일들을 볼 때 JSX 구문이 없음에도 확장자가 .tsx이거나, JSX 구문을 포함하고 있음에도 확장자가 .ts인 경우가 보이는데, 어느쪽이든 일관성 있게 맞춰주시면 좋을 것 같습니다. (번들러 설정을 통해 아예 .js 또는 .ts으로만 생성해도 알아서 처리하도록 할 수 있습니다.) (CRA에선 자체 지원 중)

4. 배포
• 중간 점검인데 실제로 시연해볼 수 있는 프로토타입이 없는 부분이 조금 아쉬워요. 시연해볼 수 있는 결과물이 있었다면 더욱 디테일한 피드백을 드릴 수 있었을 텐데, 직접 clone해서 실행해봐도 환경 변수 등의 이유로 기능이 온전히 실행되지 않네요.
• 최종 결과 발표 때는 꼭 여유를 두고 미리 배포를 시도해보세요, 배포 과정이나 배포 후에 발생하는 문제를 파악하기 위한 시간이 있어야 해요.

협업

1. PR 승인 규칙
• 당장 개발 진행을 불가능하게 만드는 버그를 해결하는 핫픽스 작업의 경우는 2 approve라는 규칙을 회피할 수 있는 예외 사항을 추가해보세요.
• e.g. 해당 버그와 관련된 실무자 1명의 approve 또는 팀장의 approve 등