리뷰 확인 및 반영

1. 리뷰확인하기

• EOF( End of file) 관련
• editorconfig 통해 강제 줄바꿈 적용해보기

• StyledComponent의 S 네이밍 스페이스 구분의 이유?
• 참고링크

• 상수 변수 함수, 컴포넌트 네이밍 규칙
• 상수네이밍의 일관성 부족
• Tabs, data, movie, movieColumns, …

• Items
• object로 컴포넌트 만들어둘 경우, 사용하지 않는 컴포넌트가 미리 생성되어있어 비효율 발생

• 리렌더링 시 이슈
• key를 지정함으로 해결 (by 승범)
• DataTable 컴포넌트가 같기 때문에, 내부 state를 그대로 가져와 사용하게 된다. 따라서 key를 통해 다른 컴포넌트임을 명시함으로써 unmount, mount를 새로하도록 한다.

• 변수 네이밍 관련
• currItem > currentItem >> selectedItem

• init 추적 관련 console.log() 제거

• Data 타입의 네이밍 관련

• props로 받은 data를 useState의 초기값으로 사용하는 패턴
• 참고 포스트 링크

• 정렬을 위한 useEffect()
• 리렌더링 되는 문제 해결 가능
• orderBy의 key가 없을경우 얼리리턴 해주기

• CompareFunc의 복잡성 낮추기

• column이 같은 정렬 상태를 공유하고 있는 문제

• sort 가능한 column, UI적으로 표현해주기

3. 개선 사항 설계

4. 개선 사항 코드 반영

이벤트 핸들러 네이밍

What is the right name of event handler? onClick or handleClick?

This is subjective, but what you would see the most is the following: if you are creating component and exposing event hooks, those props would be on: onClick, onHover, onUsernameChanged, onError. From inside your components, these props are just functions you call on some event.

https://stackoverflow.com/questions/60048249/what-is-the-right-name-of-event-handler-onclick-or-handleclick

• 관련 없는 자잘한 review 반영

• Tab 로직 재설계

• CompareFunc 재설계

2. 셀프 코드 리뷰

응집도는 어떤 관점에서 보냐에 따라 다르다

• 관심사 별
• domain

• 기능별
• 컴포넌트별, util별

 

• 관심사별 먼저 묶고 > 여러군데에서 사용되면 기능별
• duck pattern
• api에 안에 type 선언하고, 여러 군데서 사용하면, 그 때 빼는 것을 고려
• 데이터 정합성
• 파편화 <Pick ..>

• 상황별로 다 다르기 때문에, 나의 상황을 고려해야한다!

 

• 처음 설계할 때
• server에서 데이터를 어떻게 내려줄까?
• 기능은 무엇이있을까
• 과제의 목적
• 확장성과 재사용성
 
• 구현을 했나 설계를 했나
• 시간분배 해야한다!
• 큰문제는 잘게 쪼개어서 생각해봐야한다.
 
• duck패턴 / React 자유도 높다.

 

뱅크샐러드의 특별한 스펙, '테크 스펙' | 뱅크샐러드

개발자들이 개발을 시작할 때의 모습은 제각각입니다. 일단 코드부터 두드리고 보는 행동파 개발자도 있고, 눈앞에 보이는 노트 위에 간단한 구조를 그려 보는 개발자도 있죠. 뱅크샐러드에서는 모두 같은 행동을 합니다. 우리는 테크 스펙을 써요. 코드 짜기도 바쁜 우리는 문서까지 작성할 시간이 없습니다.

https://blog.banksalad.com/tech/we-work-by-tech-spec/