<aside> ✉️ 안녕하세요, 1팀 여러분 코드스테이츠 교육 엔지니어 조영현입니다. 반갑습니다! 😀 보내주신 SR 요청에 대해 면밀히 검토하였고, 팀 DebugNote의 성공적인 퍼스트 프로젝트 완성을 돕고자 수정 및 보완이 필요한 부분을 정리하였습니다. 아래 피드백 문서를 확인하시고, 댓글을 통해 자유롭게 의견을 달아주시기 바랍니다.

아래의 내용은 엔지니어의 의견입니다. 엔지니어가 드리는 피드백이 반드시 정답인 것은 아니며, 충분히 논의하신 후에 피드백 내용을 반영해주세요. 프로젝트의 완성도는 결국 여러분의 몫이니까요!

</aside>

Ideation

• 에러 핸들링 로그를 기록하고 공유하는 서비스를 기획하셨군요! 개발자에게도, 개발을 공부하는 사람들에게도 유용한 서비스가 될 수 있을 것 같습니다.
• 다만, 아이디에이션에 조금 더 차별점이 필요합니다.
  • 위키 홈에 작성해주신 서비스 설명에서 언급된 기능을 요약하면 다음과 같을 것입니다.
    • 기록, 검색, 댓글, 북마크
  • 이 4가지 기능은 다른 서비스를 통해서도 활용할 수 있는 기능들입니다.
    • 개인 블로그에 에러 핸들링 프로세스를 기록할 수 있으며,
    • 구글링으로 검색 및 피검색이 가능하고,
    • 일반적인 블로그라면 댓글 기능도 일반적으로 지원되며,
    • 마지막으로 북마크는 브라우저의 기본 기능에 내장되어 있습니다.
  • 새로운 서비스를 만드는 것이 꼭 세상에 존재하지 않던 무언가를 만드는 것을 의미하는 것은 아닙니다.
    • 하지만, 적어도 기존에 있던 무언가를 개선하거나, 아니면 여러분들의 서비스 만이 가진 차별점이 필요합니다.
  • 여러분들이 기획하신 서비스가 어떤 점에서 기존의 서비스를 개선할 수 있는지, 어떤 차별점을 가질 수 있는지 조금 더 아이디어 기획 차원에서 고민해보시기 바랍니다.
    • 여러분의 서비스가 어떤 문제점을 해결할 수 있는지, 어떤 아이덴티티를 가질 수 있는지를 중점적으로 고민해보세요.

Home

• 전반적으로 서비스의 핵심 기능을 마케팅적인 문구 없이 개조식으로 잘 정리해주셨습니다.
• 한 항목은 하나의 핵심 기능만을 서술해야 하며, 항목들 간에 서술법이 일치해야 합니다.
  • 예 : “나의 에러 해결 과정을 기록하고 모아볼 수 있는 사이트”
    • 현재 두 가지 핵심 기능이 하나의 항목으로 합쳐져 있습니다.
    • “나의 에러 해결 과정을 기록할 수 있습니다.”
    • “내가 작성한 에러 핸들링 로그를 모아서 조회할 수 있습니다.”
• 위키 홈의 서비스 설명은 서비스의 핵심 기능을 간결하면서도 빠짐없이 작성하는 것이 중요합니다.
  • 만약, 제가 위에 작성한 Ideation에서, 여러분들의 기획에 대해 무언가 제가 모르고 있는 것 같다는 생각이 든다면 그 내용을 위키에 추가해야 합니다.
  • 로그인, 정보 수정 등과 같은 모든 어플리케이션에 필요한 기능들은 위키 홈에 넣을 이유가 없지만, 서비스의 아이덴티티와 관련된 기능들은 서비스 설명에 반드시 설명되어져야 합니다.
• Requirements에 존재하지만 서비스 설명에 아래의 항목들이 설명되지 않았습니다.
  • 해시태그 검색 기능
  • 대댓글 기능
• (Optional) 개조식 설명 상단에 서비스에 대해 간단하게 소개하는 2~3줄 정도의 줄글을 작성해주시는 것도 채용 담당자의 서비스 이해를 높일 수 있는 좋은 방법이므로 고려해보세요!

Team Rules

• 전반적으로 세세하게 잘 작성해주셨습니다.
  • 다만, 형식과 내용에 정리가 필요합니다. 여러분의 프로젝트 깃헙 레포지토리의 모든 곳을 채용 담당자가 본다고 생각해주세요!
• 어떤 항목의 제목에는 이모지가 있지만, 어떤 항목에는 이모지가 없습니다. 사소한 부분이지만 깔끔하게 통일된 형식 또한 가독성에 중요한 영향을 미치며, 나아가 채용 담당자의 이해도에 영향을 미치기 때문에 신경써주실 필요가 있습니다.
• Team Rules는 전체를 요약하는 항목인가요? 전체를 포괄할 의도로 작성하신 부분이라고 하기에는 내용이 부족하고 지나치게 요약적입니다.
• project schedule 항목은 하루 일과를 타임 테이블로 만들어주셨는데, project schedule이라는 제목과 부합하지 않는 것 같아요! 조금 더 적절한 제목으로 수정해주세요.
• Module versions보다는 Stack Version이 적절한 표현입니다. 또한, npm과 node외에 사용하는 모든 프레임워크, 라이브러리의 버전을 명시해주세요.
• Type Commit보다 Commit Type이 더 적절한 표현입니다.
  • 또한, 여러분들이 협의해서 작성하신 것이 맞나요? 맞다면 세세하게 작성하셨기 때문에 강점이 될 수 있겠지만, 그렇지 않다면 면접에서 채용 담당자가 커밋 규칙에 대해 질문을 던져 곤란한 상황이 발생할 수 있습니다.
  • 프로젝트의 규모에 비해서 다소 과한 느낌이 있습니다. 프로젝트의 규모가 크고, 업무 분류가 많다면 세세하게 커밋 타입을 나눠야하지만, 그렇지 않다면 굳이 커밋 규칙을 불필요하게 세분화할 필요는 없습니다.
• Code Style은 Lint 규칙을 의미하는 항목이겠죠? Prettier 옵션을 통해 꼭 필요한 규칙들을 잘 정리해주셨습니다.
• 전반적으로 형식, 내용, 서술법을 정돈하실 필요가 있습니다. 팀 룰은 프로젝트를 진행하는 동안에는 팀원들이 지켜야할 사소한 규칙일 뿐이라고 느끼실 수 있지만, 프로젝트가 끝나고 나면 팀 룰 또한 여러분의 제출할 포트폴리오의 일부이며, 합리적인 팀 룰을 규정하여 지키는 것 또한 중요한 개발 경험 중 하나가 됩니다.
  • 위에서 언급하지 않은 Git과 Workflow 항목도 정리가 필요합니다!
• 마지막으로, 의사결정과 관련된 커뮤니케이션 규칙에 대한 충분한 규칙도 필요합니다.
  • 의견이 반반으로 갈릴 경우 어떻게 의사를 결정할 것인지, 혹은 어떤 말투나 화법을 금지할 것인지 등에 대해 논의해보세요.