컴포넌트 추상화 공통적인 요소들을 추출해 불필요한 부분들을 생략하고 객체의 속성 중 중요한 것에만 중점을 두어 개략화(사전 : 대강 추리는 일) 하는 것 하나의 컴포넌트가 하나의 책임만을 담당한다. 책임이란 어플리케이션에서 컴포넌트가 하는 행동 컴포넌트들을 각각의 책임에 맞게 필요한 로직만으로 구성한다면 응집도가 높아지며, 다른 컴포넌트와의 결합도는 줄고 컴포넌트 특성상 외부로 노출할 필요가 없는 부분은 캡슐화가 될 것 컴포넌트는 이벤트 기반으로 스타일과 DOM 구조까지 고려하여 고유한 책임을 수행하게 되기에 버튼에 스타일을 적용하거나 클릭했을 때의 애니메이션을 넣거나 필요에 따라 색상과 폰트를 변경하거나 생각보다 다양한 것들이 책임을 수행하기 위해 고려되어야 한다. 텍스트와 같이 작은 책임 수행을 넘어서 레이아웃의 형태를 책임지는 컴포넌트, 서버와의 통신을 통해 데이터를 가져오는 컴포넌트, 특정 도메인에 관련된 비즈니스 로직을 수행하는 컴포넌트 등 범위가 확대될수록 이러한 책임을…

하단 토스 컨퍼런스 내용 clean code 개발할 때 병목이 되고 유지보수가 오래걸리며, 기능 추가가 불가능하거나, 성능이 안좋을 수 있는 코드는 다음과 같다. 흐름 파악이 어렵고 도메인 맥락 표현이 안되어 동료에게 물어봐야 알 수 있는 코드 읽기 좋은 깔끔한 코드는 코드 리뷰의 시간을 단축하며, 버그가 났을 때 디버깅 시간도 단축시킨다. 클린코드의 의의=유지보수(코드파악, 디버깅, 리뷰) 시간(시간=자원=돈)의 단축 나쁜 코드는 하나의 목적인 코드가 흩뿌려져 있는 경우 다 떨어져 있어 나중에 기능을 추가할 때 스크롤을 위아래로 이동하며 미로찾기를 해야함 하나의 함수가 여러가지 일을 하고 있는 경우 세부 구현을 모두 읽어야 함수의 역할을 알 수 있다. 코드 추가 및 삭제도 시간이 걸림 함수의 세부 구현 단계가 제각각일 경우 큰 그림을 보며 리팩토링 하면 함수 세부 구현 단계 통일 하나의 목적인 코드는 뭉쳐두기 하나의 함수는 한가지만 하도록 쪼개기 ⇒ 클린코드란 짧은 코드가 아닌 …

사용시 이점 중간에 service worker를 통해서 네트워크 요청을 가로채고 모의 응답을 받아 반환하기 때문에 기존 data fetch 로직을 그대로 사용하여 mock 데이터를 반환 받을 수 있다. 그렇기 때문에 api 가 혹시라도 늦게 나온다고 하더라도 사전에 api spec 만 미리 맞춰놓는다면 네트워크 요청 로직을 미리 작성해 놓고 그대로 사용하여 테스트할 수 있다. 데이터를 하드코딩 하거나 mock server를 만든다고 하더라도 추후에 url 및 엔드포인트 변경이라던가 네트워크 요청 로직을 다시 작성할 필요가 있는데, msw는 그에 비해 on/off 하듯이 기존에 필요한 로직을 그대로 사용하여 원하는 데이터를 조작하여 사용할 수 있어 백엔드와 개발 시점이 겹친다고 하더라도 일정이 미뤄지지 않고 개발할 수 있다. 원하는 테스트를 진행하기 위해 db 조작을 따로 요청할 필요 없이 mock 데이터를 생성해 테스트할 수 있다. header, cookie 등 네트워크 요청시 사…

code smells in css css 규칙 스타일은 추가만하고 취소는 하지 않도록 한다. 매직넘버(반드시 그렇게만 작동하는 값) 피하기 조건부 선택자를 피한다. 재사용 불가능하고 특정도를 높이며 선택자를 한정함으로 브라우저 작업량을 증가시켜 성능을 저하시킨다. 꼭 필요한 경우를 제외하고 절대값을 피하고 상대값을 사용한다. 무차별 강제 스타일을 피한다. 위험한 선택자(너무 광범위하게 적용될 수 있는 것)를 피한다. !Important 피하기 사용시 명확한 의도를 갖고 사용하도록 한다. ID 보다 class를 선호하라 class는 한 페이지에 한번만 존재해도 되고 여러번 존재해도 되며 재사용이 가능해지는 경우가 많다. 느슨한 클래스 이름(의도한 목적을 충분히 드러내지 못하는)을 피한다. Reference CSS 코드 냄새