💻 프로젝트 컨셉 및 기획 의도
- 누구나 한 번쯤 겪어봤을 법한, 사람들에게 익숙한 프로젝트 주제라고 생각됩니다.
- 신년 계획이 실패하는 현상이 발생하는 상황에 대해 이런 이유들이 있다고? 싶을 정도로 치밀한 자료 조사가 인상 깊습니다.
✅ 프로젝트 구조 및 설계
- 일관적인 디렉터리/파일 구조를 유지하려고 신경 쓰고 있는 모습이 보입니다.
- 실제 배포 시에는 console 구문이 포함되지 않도록 주의해주세요.
- 가급적이긴 하지만, 웬만해서는 아예 포함되지 않는 편이 이롭습니다.
- 선택 사항에 해당하는 부분인데, SCSS를 사용할 때 SCSS 파일 자체를 사용하는 것뿐만 아니라 모듈 형태로 사용할 수 있는 SCSS Module도 있습니다.
- 모듈을 활용할 수 있는 부분, 활용하면 좋은 부분에는 모듈을 적당히 활용해봐도 좋지 않을까 싶네요.
🛠️ 기술 스택 및 협업툴
- Next의 Router와 Image, Link 등 제공되고 있는 기본 기능들을 적절히 잘 활용하고 있는 걸로 보입니다,
- Jira는 권한 상 확인이 불가능하지만, GitHub에서도 확인할 수 있게 관리 중인 방식은 좋은 것 같습니다.
- assign을 통해 이슈의 담당자를 지정할 수 있는데, 이슈 이름에 담당자의 이름이 들어가야 할지…? 는 의문이긴 하네요. (담당자가 바뀔 수도 있는데 그럴 때마다 이슈 이름도 변경?)
🗓️ 일정 산정 및 관리 방법
- 메인 프로젝트 관리 도구가 Jira라서 그런지, 제가 노션에서 못 찾은 것인지는 모르겠지만 일정 산정 방법을 찾을 수 없습니다. 🥲
🧑🏻💻 기능 구현 및 주요 개발 포인트
- SCSS의 장점이라고 한다면 아무래도 재활용이 가능하다는 게 큰 이점이지 않을까 싶은데, 스타일 코드에서 중복된 구문이 들어가있는 모습이 보입니다.
- 급한 부분은 아니니 리팩터링 진행할 때 정리해보는 것으로 하시죠 (DRY)
- 배포는 빠르면 빠를수록 좋습니다.
👥 협업 방식
- 지금처럼 자동화할 수 있는 코드 스타일과 컨벤션은 도구(hooks)를 활용해서 자동화해두시면 좋을 것 같습니다.
- 이전 커피챗에서 코드와 개발 구조에 관한 논의를 활발하게 진행하던 모습으로 미루어볼 때 도구가 커버하지 못하는 영역에 대해서는 직접 검토하는 것도 잘 하고 계시는 것 같습니다.
- 저도 개인적으로는 ‘주석을 남기는 것 대신 한 눈에 봐도 이해할 수 있게 코드를 작성하자’가 기본 자세긴 합니다만, 그렇다고 하더라도 주석이 필요한 부분은 있기 마련입니다. (주로 비즈니스 로직과 개발/기획 맥락에 관한 부분)
- 필요하지 않은 부분에 남기지 않는 것은 상관 없으나, 필요한 부분에 남기지 않는 것은 추후 본인이나 동료에게 업보로 돌아오므로 코드를 작성할 때 이 로직을 이해하기 위해 필요한 부연 설명이 있을지를 검토하는 자세를 가져보면 좋을 것 같습니다,