윤민상 블로그

배경 엄청 오랫동안 코드스피츠 강의를 듣지 못했다. 논건아니다... 다른 우선순위에 치여서 못했을 뿐... 진짜.... 어쨋든 다시 코드스피츠 강의를 조금씩 듣고있다. 듣다보니 리팩터링과 겹치는 내용들이 많다. 둘다 켄트백의 영향을 많이 받아서 그런것같다. 리팩터링, 객체지향의 사실과 오해, 코드스피츠가 점차 한 점으로 모이고 있는 느낌이 든다. 원래 어떤 분야든 공부를 하댜보면 전혀 다른 분야의 과목도 한 점으로 모인다고 하는데 조금 느껴진다. 강의 이론 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을 사용하면 큰 문제없이 패키지..

리팩터링 원칙 리팩터링 리팩터링 하는데 정의가 무엇일까? 정의는 다음과 같다. 소프트웨어의 겉보기 동작은 그대로 유지한 채, 여러가지 리팩터링 기법을 적용해서 소프트웨어를 재구성하다. 여기서 겉보기 동작은 그대로 유지한 채. 라는게 중요하다. 성능을 개선하고 기능을 추가하는 거은 리팩터링이 아니다. 우리는 커밋을 할때도 기능 추가와 리팩터링 두 개의 모자를 구분해서 바꿔써야한다. 대부분의 회사에서 하는일은 유지보수다. 그리고 기능추가를 하려고 하는데 코드가 지저분할 경우가 있을 것이다. 그럴때는 먼저 리팩터링을 하자. 대단한 리팩터링을 얘기하는 것이 아니다. 함수가 좀 크다면 함수를 나누고 변수명이 모호하다면 변수명을 바꾸고 이런 기본적인 것들이라도 먼저 적용하면 훨씬 깔끔해진다. 이 이후에 코드를 보면..

배경 라이브러리없이 밑바닥부터 개발하는 경험은 정말 소중하다. 1년전 우아한테크캠프를 통해서 이를 배웠으며 한번씩 기회가 될때마다 공부해왔다. 그리고 이제 좀 쓸만한? 리액트 비스무리한 라이브러리를 만든것 같아서 글을 적는다.(참고로 컴포넌트에 관한 3번째 글이다...) 사전지식 리액트를 만들어야하는데 리액트의 동작방식을 몰라서는 안된다. 최소한 공식문서는 정독하고 혼자서 가볍게라도 만들어보는 걸 추천한다. 이미 나와있는 자료들을 보고 내가 새롭게 만들어보는것도 좋은 방법이지만 아무것도 머리속에 넣지 않고서 머리를 쥐어뜯으면서 생각해보는 것이 더 도움이 된다고 생각한다. best practive를 찾아서 공부하는 건 좋은 방법이지만 그것만 쫓아서는 좋은 개발자가 될 수 없다고 생각한다. 혼자서 코딩해보고..