동영팀
- 프로젝트 명 : 꿀매포청천(PricePCC)
- 프로젝트 소개 : 가격 정보 교류 및 피드백 커뮤니티
- 깃헙 링크 : [링크]
- 최종 배포 링크 : [링크]
최종 평가 피드백
기획
- 처음 무난한 주제와 생소한 콘셉트(꿀매 + 포청천 = ???), 불명확한 타겟을 보며 기획의 의도가 무엇인지 의문을 느꼈으나 생각보다 콘셉트에 진심인 모습을 보인 점은 좋다고 생각합니다.
- 다만 전체적인 기능이 이 콘셉트를 최대한 살리지 못한 느낌이 든다는 점이 아쉽기는 합니다.
- 추후 다른 백엔드 인력(?)을 구해서 프로젝트를 키워 보는 것도 괜찮지 않을까 싶네요.
개발
- 시각적인 스타일 요소에 많은 신경을 쏟은 것이 보이지만, 스타일 못지 않게 더 중요한 건 근본적인 마크업 구조라고 할 수 있습니다.
- placeholder 색상과 배경색의 대비가 낮아서 가독성이 떨어집니다.
- placeholder 색상도 스타일 영역에서 정의할 수 있기 때문에 접근성을 위해 대비를 살짝 높여주면 좋을 것 같습니다.
- 회원 가입 페이지에서 아이디를 입력할 때 공백 문자도 포함이 됩니다.
- 실제 서비스에서는 백엔드 영역에서 유효성 검증을 진행할 부분일 테지만, 프론트엔드에서도 정규식을 통해 의도하지 않은 값이 입력되는 경우를 방지하면 좋습니다.
- 글을 작성하는 영역은 기본 배경과 다른 색상을 적용해서 명확하게 영역을 지어주는 게 좋습니다.
- 에디터의 중간 부분을 클릭하면 입력 포커스가 발생하지 않고 글이 입력된 지점을 클릭해야 포커스가 시작되는데 마찬가지로 사용자의 경험을 위해서 개선하면 좋을 것 같습니다.
- 댓글 입력은 한 줄보다 여러줄이 입력될 가능성이 더 높을 것 같은데, input에서는 한 줄만 표시하게 되어 있네요. textarea 적용을 고려해볼 수 있을 것 같습니다.
- 댓글이 여러줄 입력되었을 때 레이아웃 꺠짐
- 댓글 영역을 선택하다 보면 새로고침이 꽤 잦게 발생하는데 새로고침을 실행하는 조건을 검토해보면 좋을 것 같습니다.
- 콘텐츠 크기에 비해 wrapper의 padding이 과하게 들어간 느낌이 있는 것 같아서 적절한 균형을 검토해보면 좋을 것 같습니다.
배포
- 실제 배포된 페이지에서 크리티컬한 문제 없이 작동하는 건 좋습니다.
- 그러나 배포 주기는 더욱 짧게 가져가면 좋지 않았을까 하는 아쉬움이 있습니다.
- 이전에 git flow를 적용하기로 결정했을 때도 제안한 부분이었으나, 현재 github flow로 브랜치 플로우를 바꾸었다고 하는 상황에서도 빠르게 기능을 개발하고 빠르게 main으로 머지하는 것이 목적인 github flow를 온전히 활용하지 못하고 있는 것으로 보입니다.
- Vercel 등의 서비스에서는 생성된 PR을 바탕으로 빌드된 사이트 결과물을 확인할 수 있는 Preview 기능을 제공하고 있습니다. 해당 기능을 활용해서 빠르게 최종 결과물을 확인하고 머지하는 프로세스를 가져간다면 다음 배포 주기 때 무수한 충돌이 발생하고, 출동을 해결하기 위해 모두의 작업이 blocking 되는 비효율적인 작업을 줄일 수 있을 겁니다.
- 배포는 빠를수록 좋습니다. 저장소를 생성하고 나면 바로 배포를 진행하는 것도 좋습니다. 특히 타 직군과 협업을 진행할 때는 실제 동작하는 결과물을 보여주는 게 좋으므로 다음 프로젝트에서는 바로 배포를 시작해보는 것도 추천합니다.
협업
- 실제 업무를 진행할 때는 내가 지금 무엇을 하는 중인지, 진행 상황이 어떤지를 자주 공유하는 게 좋습니다. (마찬가지로 잦으면 잦을수록 좋습니다.) 1차 목표는 누군가 너 지금 뭐하는 중이야? 라고 물어봤을 때 ‘지금 무엇을 하는 중이고 이런 상황이야’라고 답변할 수 있도록 하는 것이고, 2차 목표는 누군가 굳이 물어보지 않더라도 내가 무엇을 하고 있는지를 다른 사람들이 알 수 있게 하는 것입니다.
- 이를 위해서는 Slack과 Notion 등의 소통 도구를 잘 활용할 필요가 있습니다.
- Slack을 통한 의사 소통의 중요성에 대해서는 데브코스나 커피챗을 통해 여러 번 전달해드렸기 때문에 앞으로는 더욱 적극적으로 활용해보시면 좋을 것 같습니다.
- contribution graph를 보면 작업 분포 자체는 적당히 나누어진 것처럼 보입니다.
기타
- 프로젝트의 README가 중요하다고 언급한 적이 몇 번 있었는데, 꼭 들어가야 하는 내용은 다 있는 걸로 보입니다.
- 몇 가지 의견을 첨부하자면
- 팀원 소개는 최상단에 들어갈 이유가 없습니다. 이력서의 프로젝트로 첨부한다면 이미 해당 지원자가 참여한 프로젝트라는 사실을 인지하고 들어가기 때문에 참여한 사람의 정보는 그렇게 중요하지 않습니다.
- 가장 중요한 정보일수록 상단에 위치하는 게 좋기 때문에 프로젝트 개요가 가장 먼저 나오면 좋을 것 같고, 팀원 소개는 마지막에 들어가도 될 것 같습니다. 다른 오픈소스 프로젝트의 README는 어떤 식으로 구성되어 있는지 참고해보시면 될 것 같네요.
- 그리고 현재 프로젝트 구조, 디렉터리 구조, 시스템 설계, 인터페이스 등, 이 중 추가할 수 있는 내용이 있다면 추가하면 더 좋을 것 같습니다.
- 여러 기술을 사용하고 있는데, 개인적으로 이런 기술을 사용하기로 결정한 이유나 어떻게 활용하고 있는지에 대해서 아티클 같은 느낌으로 GitHub 위키나 이슈, 아니면 노션이나 블로그 등의 채널에 작성되어 있는 글을 추가로 첨부하는 느낌도 괜찮을 것 같습니다. (정말 선택인 사항이라 안 해도 무방)
- 소스 코드에서 example로 들어 있는 코드 뭉치들이 하나씩 보이는데, 실제로 동작하지 않는 코드들은 모두 제거하는 게 좋습니다.
총평
- 팀 프로젝트에 제대로 참여한 건 이번 프로젝트가 처음이라고 하는 분들이 많은 것에 비해선 나름 잘 수행된 프로젝트라고 생각합니다.
- 이번 프로젝트에서 느낀 아쉬움 만큼 다음 프로젝트에서 더 많은 것들을 이룰 수 있기를 바랍니다.
- 프로젝트의 최종 완성도가 떨어지는 것은 아니지만, API의 제약도 있고, 기능이 풍부하다거나, 적은 기능으로도 사용자를 사로잡을 만한 중독성이 있는 것도 아니라서 임팩트가 큰 프로젝트라고 보기엔 아쉬운 점이 있는 것 같습니다.
- 새로운 프로젝트를 통해 이력서와 포트폴리오를 보충할 수도 있겠지만, 새로운 프로젝트를 시작하는데는 그만큼 시간이 또 소요되기도 하고, 하나의 프로젝트를 계속 발전 시켜나가는 경험 또한 개인의 발전이나 이력면에서 중요한 요소라고 할 수 있기 때문에 이 프로젝트를 프로그래머스 내부 사람들이 아닌, 외부 사용자들도 사용할 수 있을 정도로 만들어 보면 좋을 것 같다는 희망사항을 제3자의 시선(?)으로 남겨봅니다.
- 특히 여러분들은 Next.js를 사용하신 만큼 꼭 메인 백엔드 API에 얽매일 필요 없이 기능을 확장할 수 있는 가능성에 충분히 열려있기 때문에 이 점은 한 번 검토해보시면 좋을 것 같습니다.