피드백

2024-12-09

• 역할 분담에 대한 조정 필요

• 인원이 다른 팀들보다 부족하므로 생산성 향상을 위한 라이브러리 추가 필요성 ex) headless UI

2024-12-13

• 김민섭

  • 컴포넌트 및 각종 코드 재사용 및 레이아웃 구현시 가독성 향상 및 상수 값 JSON 형태 전환으로 인한 성능 향상

• 조지연

  • 고정된 텍스트는 코드 안에 넣어두어도 됨. 다만 숫자의 경우 전역으로 사용될 수 있음(별도 파일에 넣어두고 interpolate로 처리)
  • 서버에서 데이터를 받아올 때는 interface를 정의하고 서버 데이터 리턴 타입이 같도록 서버와 공유하는 것을 추천
  • 서브 컴포넌트 분리: CartTable -> CartItems
  • 코드에 undefined, null 등을 넣는 것은 좋지 않음. Optional chaining 사용
  • 특정 변수(checkedItems)의 변화에 따라 재계산 되는 변수들은 useMemo 사용을 고려해보기
  • 사용이 복잡한 변수에 주석 달기

• 박정혜

  • 최대한 중복되는 코드 줄이기
  • 향후 server call이 일어나면 TODO와 error handling 추가
  • 카멜케이스 사용 습관화 들이기
  • valications -> validator로 동사로 바꾸기(보통 현업에서 util의 경우 많이 사용함)
  • 각 validator에 설명 달아주기
  • boolean 타입에 기본값으로 null 이 아니라 false로 넣기
  • 실제 코드리뷰 할 때 아무 설명없이 주석처리된 소스 보내지 않기

2024-12-20

• 조지연

  • 함수는 하나의 기능을 해야 나중에 unit test도 쉬워짐. 다중 if/else if/else if... 는 권하지 않으며, 최대한 3개 미만의 if/else를 가질 수 있도록 설계하시면 향후 컴포넌트 설계 및 테스트에 도움이 될 것임
  • any 타입 보다는 컴파일 타임 에러 정의를 위해 object를 생성하시는 권고 (다른 부분에서 에러가 발생할 수 있음)
  • state의 기본값을 상수로 넣을 때는 주석을 달아주는게 이해에 도움이 됨
  • "추후 연결" 같은 내용은 주석으로 // TODO: 추후 연결 만들고 user_id: 'NOT_IMPLEMENTEDE' 와 같이 dummy data를 넣어두는게 좋음 (참고: https://ostarblog.tistory.com/10)
  • 기타: camelCase 유의해주세요.

• 김민섭

  • product 정보 불러올시 로직 개선사항 ( 카트정보 유저 UID 기반 불러오기, 카트정보에서 product 컬렉션 리퀘스트
  • 에러 처리에 대한 직관적인 표현 필요
  • 실패 이후 rollback 기능 필요

2024-12-23

• 조지연

  • 금액적인 부분은 서버에서 받아오는걸 권장(uglifier를 하더라도 소스코드 보기를 하면 유저가 모두 확인 가능)

  • 향후 payment 기능을 실제 구현할때는 CUJ별로 로직을 문서화 해두는걸 추천

  • payment db콜을 할 때는 꼭 rollback처리를 해둬야 함

    보통 payment API 예컨데 Paypay API등을 사용할 때에 이를 호출하고, 이 응답결과에 따라 뭐 transaction을 업데이트 하거나 그러는데 만약 payment API가 실패일 경우 어디를 초기화하고 어떤 부분을 다시 제공해야 하는지, 특히 데이터 처리부분 (예: 장바구니에 넣은 아이템, 전체 계산된 값)을 신경써서 구현 및 롤백전략을 세우시길 추천드립니다.

  • 기타 코드 개선 지도 (간결한 함수, 일관성 유지, 리터럴 축약법 등)

• 김민섭

  • 전체적인 중복된 기능 및 페이지 모듈화 작업 필요성 파악
  • 변수명 선언시 통일성 (newAddressDetail or details)
  • 리터널 축약법 적용
  • 컴포넌트 전달 인자로 인한 가독성 하락 유의 ( 컴포넌트 내부에 처리)