React

이력서 평가 후기 참고하기

1. 데모

데모에 로그인 기능이 있다면 테스트용 계정을 제공하는게 좋습니다.

1) 우산 카드는 마우스가 호버 될 때 밑면의 그림자만 보이지 않습니다. Margin을 더 넣어주시는게 좋을 것 같습니다.

2) "Choose your Brella" 버튼의 경우 글자가 가운데로 정렬되지 않아서 불편한 느낌을 줍니다. bottom의 padding을 추가하면 좋을 것 같습니다.

3) style이 mobile 환경에 responsive하지 않습니다. 글자가 서로 겹치거나 이미지 정렬이 되지 않거나 폰트 사이즈가 너무 작아 사용하기 불편합니다. 반응형으로 해주셔야 합니다.

4) 회원 가입시 이메일 인증 절차가 필요합니다. 이메일 인증을 지원하지 않으면 존재하지 않는 이메일이나 타인의 이메일로 가입이 가능하게 됩니다. 더불어 계정 생성시 password를 암호화하지 않았다면 암호화 하시기 바랍니다.

5) 메뉴에 장바구니를 추가하시기 바랍니다. 물건을 카트에 담아도 다른 물건을 선택하지 않는 이상 장바구니를 확인할 방법이 없습니다.

6) 로그인 후 "payment" 버튼을 클릭하면 로그인 하라는 메세지가 뜹니다.

총평: 쇼핑몰이나 반응형이 아니라 불편하며 기본적인 비지니스 로직이 제대로 짜여지지 않았다는 느낌을 받았습니다. 또 프로젝트가 너무 단순하여 제대로 비지니스 로직을 구현할 능력이 있는지 확인할 수 없습니다.

2. 깃허브

1) 프로젝트가 너무 단순하여 백엔드 코드로 본인의 능력을 어필하지 못합니다. 예를 들어, model은 User 밖에 존재하지 않아 DB와 관련된 지식을 보여줄 수 없습니다. 비지니스 로직을 더 보강한 후 MongoDB 대신 MySQL이나 PostgreSQL과 같은 RBDMS로 모델을 구현하면 좋을 것 같습니다. One to Many나 Many to Many와 같은 relationship을 보여주면 적어도 이 사람이 DB의 기본을 가지고 있구나 어필 할 수 있습니다.

2) 코드 분리가 필요합니다. 백엔드는 보통 Domain-driven design으로 기능이나 서비스에 따라 component 단위로 나누고 이를 다시 API, Controller, Data Access Layer, Service Layer, Model 등으로 나눕니다. express의 경우 api를 router를 써서 분리합니다. 더불어 error와 관련된 status를 작성하시기 바랍니다.  프론트엔드의 경우 모듈 시스템을 이용하며 스타일과 로직을 분리하는게 좋습니다. 더불어 프로젝트 스트럭트도 Footer이나 Header와 같은 Component는 Layout에 포함되니 Layout으로 이동시키는게 좋습니다.

3) var을 쓴 경우가 있던데 var의 scope가 함수 단위라 추천되지 않습니다. var 대신 let을 쓰시고 let 보다는 const를 사용하시기 바랍니다. 그리고 product/index.js를 보면 product data를 하드 코딩 하셨던데 API로 backend에서 가져 오시기 바랍니다. 기타 코드 부분에서 일일이 지적하기 힘든 다양한 문제가 있습니다.

4) 깃허브 페이지에 이슈들을 정리하신게 많은 무슨 말인지 이해하기 힘들거나 제대로 기술을 이해하지 못했다고 생각하는 부분이 많습니다.

4-1) nextjs SSR build? next.js는 기본적으로 JS가 꺼져 있어도 기본으로 HTML로 컨텐츠를 보여줍니다. 그리고 web은 기본적으로 html을 먼저 로딩합니다. 그리고 global object 등 기본적으로 side effect가 발생하는 일은 useEffect 안에서 사용해야 합니다.

4-2) useState setter 값 반영시점? 표현이 명확하지 않아 모르겠으나 이전 값을 업데이트 하고 싶으시다면 setState(product -> ({ ...product, quantity = product.quantity+1})) 식으로 callback function을 사용하면 됩니다. 그리고 const 대신 let(var)을 사용하신게 있는데 count 같은 경우 변수로 받지 말고 array.reduce를 사용하면 구할 수 있습니다.

4-3) Promise 함수 동기식 처리? 설명이 부정확한 것 같습니다만 Async task가 원하는 순서대로 시행되지 않지만 promise를 사용한다면 promise chain으로 원하는 순서대로 실행이 됩니다. 그리고 이럴 때는 nextjs는 babel로 ES6 + 를 지원하기 때문에 async/await을 사용할 수 있습니다. asynchronous tasks의 순서가 중요하지 않다면 performance를 위해 promise.any 등을 사용할 수 있습니다. 그리고 promise chain이 끝나면 catch로 error handling을 해야 하는데 catch가 빠진 함수가 많습니다.

4-4) api request, response 구체적으로 caching을 했다는 말인지 했다면 server에서 했는지 browser에서 했는지 명확하지 않습니다. 설명을 구체적으로 해야 할 필요가 있습니다. 그리고 cart의 경우 user가 다른 장치나 브라우저에서 로그인 할 수 있는데, 이 경우 원래 브라우저에서 cart에 담은 상품은 확인할 수 없습니다. 아마존 등의 웹사이트에서 어떻게 처리하시는지 보시기 바랍니다.

4-5) 그외 트러벌 슈팅. 분명 load balancer을 사용하셨다고 했는데 왜 CORS를 cors library로 처리하셨는지 모르겠습니다. cors를 사용하면 매 번 preflight request를 보낸 후 data를 보내기 때문에 응답속도가 느려집니다. 이 경우 cors 대신 revserse proxy를 사용해 해결하면 됩니다.

더불어 왜 상대경로를 절대 경로로 바꾸어야 할 필요가 있는지 의문입니다.

5) devDependencies를 보니 eslint나 prettier 등을 사용하지 않으시는 것 같은데 사용하지 않으시다면 lint나 formatter를 사용하시기 바랍니다.

6) Lighthouse에서 요구하는 사항을 전부 고치시기 바랍니다.

7. 유닛 테스트를 하시기 바랍니다.

총평: 전체적으로 HTML, CSS, JavaScript의 기초를 제대로 알지 못하신다는 느낌을 받았습니다. 더불어 React.js나 Next.js, Express.js 같은 라이브러니나 프레임워크의 아주 기초적인 기능만 사용이 가능하신 것 같으며 프레임워크를 사용하는 이유나 배경 혹은 원리에 대해 잘 이해하지 못한다는 느낌을 받았습니다. 더불어 코드를 사용하는 모습을 보면 왜 이런 로직을 사용하고 이런 접근을 하는가에 대한 고민 없이 작성한다는 인상을 받았습니다. 문제를 해결하는 방식도 근본적 원인을 해결하는 것이 아닌 이해 없이 단순히 구글링으로 답만 찾은 후 한다는 느낌을 받았습니다. 저도 신입이라 제 진단이 전부 옳다고 주장할 수 없지만 지금은 프로젝트가 아닌 기본기를 다시 다지는 일이 중요하다고 생각합니다.
블로그도 대략 읽어 보았습니다. 열심히 공부하신 것 같습니다만 아마도 제대로 된 피드백과 교재를 갖추지 못한게 진척을 느리게 한 것이 아닐까 생각을 합니다.
Udemy에 웹 디벨로퍼를 위한 강의를 추천 드립니다. 강의는 배우는 것의 핵심을 빠르게 익힐 수 있고 중요한 것과 중요하지 않은 것이 무엇인지 알 수 있도록 도와줍니다. 예를 들어, 대부분의 강의는 var, let, const keywords에 대해서 다루기 때문에 강의를 들었다면 var을 사용하는 일이 없었을 것 입니다.
관련 서적도 많은 도움이 되지만 기초를 다지고 큰 그림을 보기 위해서는 좋은 강의만 한 것이 없습니다.
관련 서적을 추천 드리자면
JavaScript The Definitive Guide
JavaScript: The Good Parts
JavaScript Patterns
Mastering JavaScript Functional Programming
Node.js Design Patterns
Mastering React Test-Driven Development
Refactoring the second edition
Clean Code
그리고 코드를 작성하실 때 확실하지 않으신게 있다면 무조건 해당 레퍼런스를 참고하시기 바랍니다.
더불어 개발자 community를 항상 체크 하셔야 합니다.
프로젝트에 관해서 말하자면 경험상 너무 단순한 프로젝트 보다는 어느 정도 복잡한 프로젝트가 더 큰 도움이 되는 것 같습니다. 규모가 크고 복잡하기 때문에 나타나는 문제들이 있고 특정 디자인 패턴이나 아키텍처가 필요한 상황을 알기 때문입니다.