윤민상 블로그

강의내용 이번 강의에서는 저번시간에 만들었던 todo list를 리팩터링하면서 기능, 성능을 추가한다. html 먼저 js로 관리하던 dom 코드를 html파일로 이동시켰다. 리액트는 dom을 js로 관리한다. 자바스크립트로 모든것을 다루는 것은 분명히 장점이 있지만 그건 리액트에 dom api를 위임하고 jsx를 이용해서 가독성을 높였기 때문이다. 그런게 없는 일반 자바스크립트에서 기본 dom 코드가 있는 것은 오히려 코드의 가독성을 낮춘다. extends set set을 사용하는 코드가 있었는데 클래스 자체에서 set을 extends하게 변경했다. 그러면 다음과 같이 super로 set에 접근할 수 있다. 테트리스 글에서 올리긴 했는데 이건 진짜 set으로 동작한다. es6에서 나온 클래스로만 할 수..

테스트 구축하기 드디어 나왔다. 테스트코드... 근데 이 책은 테스트에 관련된 책이 아니라서 상세하게 설명하지는 않았다. 그래서 좀 아쉽기도 하지만 테스트로 주제가 빠져버리면 책 한권으로도 부족하기 때문에 어쩔 수 없다고 생각한다. 예시 테스트 코드도 나쁘지는 않지만 좀 부족하다. 게다가 프론트엔드에서 테스트는 또 다른 얘기다. 자가 테스트코드의 가치 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다. 테스트를 작성하다 보면 원하는 기능을 추가하기 위해 무엇이 필요한지 고민하게 된다. 구현보다 인터페이스에 집중하게 된다는 장점도 있다. 게다가 코딩이 완료되는 시점을 정ㄹ확하게 판단할 수 있다. 테스트를 모두 통과한 시점이 바로 코드를 완성한 시점이다. 켄트 벡은 테스트부터 작성하는 습관을 ..

배경 엄청 오랫동안 코드스피츠 강의를 듣지 못했다. 논건아니다... 다른 우선순위에 치여서 못했을 뿐... 진짜.... 어쨋든 다시 코드스피츠 강의를 조금씩 듣고있다. 듣다보니 리팩터링과 겹치는 내용들이 많다. 둘다 켄트백의 영향을 많이 받아서 그런것같다. 리팩터링, 객체지향의 사실과 오해, 코드스피츠가 점차 한 점으로 모이고 있는 느낌이 든다. 원래 어떤 분야든 공부를 하댜보면 전혀 다른 분야의 과목도 한 점으로 모인다고 하는데 조금 느껴진다. 강의 이론 5,6강에서는 todo list를 만든다. todolist를 만들면서 이것저것 설명을 하시는데 설명에 관한 것들을 먼저 적고 마지막에 코드와 관련된 얘기를 하겠다. 상태값 boolean 상태값으로는 boolean이 좋지 않다. 사실 나도 알고 있던 내..

코드에서 나는 악취 이번에도 세부적인 내용은 적지 않겠다. 그 중에서도 중요하다고 생각한 몇가지만 적어보겠다. 그리고 가장 중요한 것은 코드를 작성할 때 생각을 하면서 짜는 것이다. 생각없이 코드를 적으면 악취를 풍긴다. 최대한 냄새를 풍기지 않게 주의하면서 코딩을 하자. 기이한 이름 코드를 명료하게 표현하는데 표현하는데 가장 중요한 요소 하나는 바로 이름이다. 마땅한 이름이 떠오르지 않는다면 설게에 더 근본적인 문제가 숨어 있을 가능성이 높다. (너무 많은 역할을 하고 있지는 않은지 생각해보자) 네이밍은 엄청나게 중요하다. 진짜로 엄청엄청. 변수명을 보고 유추하기 어렵다면 그건 잘못된 네이밍이다. 설계가 잘못되었는지 두 가지 이상의 역할을 하고 있는지 이런것들을 생각하는 것도 중요하지만 그것과는 별개로..

개발환경 적용은 끝났다. 테스트코드나 ci cd까지 추가하는 건 너무 광범위하다고 생각해서 다루지 않을려고 했다. 그런데 storybook을 적용하면서 몇가지 문제점이 생겨서 적용방법만 소개해보려고 한다. 스토리북 설치하기 다음 명령어로 스토리북을 설치하자. 참고로 yarn이아니라서 그냥 레포에 직접 들어가서 명령어를 입력하면 된다. npx는 yarn 환경이라면 yarn으로 알아서 설치해준다. npx sb init --builder @storybook/builder-vite 이게 끝이면 내가 글을 쓰지 않았다. yarn story명령어로 스토리북을 실행하면 import를 할 수 없다는 에러가 발생한다. 해당 라이브러리를 찾아보니 실제로 설치되지 않은 라이브러리다. 아마 내부에서 사용되는 것 같은데... ..

추가적인 문제점 찾아보기 yarn berry로 npm의 고질적인 문제점을 해결하고 monorepo로 재사용성을 높였다. 이제 아무런 문제가 없을까?? 프론트개발자는 항상 문제를 찾아야한다. 주어진 환경에 만족하지 않고 불편함을 느끼고 해결할 방법을 찾아야한다. 내가 느낀 불편한점은 웹팩이다. 웹팩은 너무 느리다. 빌드시간도 느리고 서버 구동시간도 느리다. 웹팩은 분명히 많은 사람들이 사용하고 레퍼런스도 많다. 하지만 문제점도 분명하다. 너무 느리다. 불필요한 플러그인을 제거하고 terserplugin을 적용하거나 gzip압축을 하고 캐시를 적용해도 본질적인 문제는 해결되지 않는다. 웹팩의 문제점 그러면 웹팩이 왜 느릴까?? 사실 프론트엔드의 발전과정을 이해해야한다. 너무 자세히 말하면 주제가 달라지기 때..

커져가는 프로젝트의 문제점 인지하기 저번 글에서 yarn berry에 대해서 학습했다. 기존 npm에 대한 숙제 하나는 끝낸 셈이다. 그런데 다른 문제가 발생했다. 개발자 대부분은 회사를 다닌다. 그리고 대부분의 회사에서는 만들고 끝이 아니라 끊임없이 유지보수하고 기능을 추가한다. 처음에는 가벼운 프로젝트라고 할지라도 시간이 지남에 따라 엄청 거대해진다. 전혀 다른 프로젝트라면 새롭게 프로젝트를 시작하면 되겠지만 기존 프로젝트의 디자인 시스템이나 유틸함수, 상수등을 공유해야될 경우가 있다. 이걸 npm으로 배포해서 여러프로젝트에서 install하는 형식도 있겠지만 관리가 너무 힘들다. 컴포넌트만 하더라도 매일매일 변경되는데 이걸 매번 배포하고 업데이트를 할 생각을 하면 벌써 머리가 아프다. 이럴때 mon..

npm과 yarn 프론트엔드 혹은 nodejs개발자라면 npm이라는 말을 다들 들어보고 사용해봤을 것이다. npm은 Node Package Manager의 약자이다. 즉 node기반의 모든 패키지들을 관리하는 툴이다. 그리고 npm과 더불어서 yarn이라는 것도 많이 사용된다. yarn은 npm 구조에 의존하고 있으며 페이스북에서 만들었고 속도나 보안측면에서 조금 장점이 있다. 그대신 디스크 용량을 조금 더 잡아먹는다고 한다. 사실상 명령어가 조금 다른것을 제외하고 눈에 띄게 차이가 나지는 않는것같다. 애초에 yarn은 npm에 의존하고 있기도 하고 차이가 심하다면 다들 yarn을 사용할텐데 그래도 아직까지는 npm 이용자 수가 더 많다. 문제점 인지하기 npm이나 yarn을 사용하면 큰 문제없이 패키지..