5주간의 여정

끝난 후기

• 기초를 다잡고 주니어 개발자로서 어떻게 공부를 시작해야 하는지, 다른 사람들은 어떻게 공부를 하고 있는지 경험해보고 싶다면 추천!
• 사람이 완벽해질순 없지만 최소한 이런 코드는 짜지말자 <- 이 말에 공감한다면 추천!

얻은 것

클린코드의 예시, 추상화, 선언형 프로그래밍

before

• 클린코드는 막연히 깔끔하게 보기 좋은 코드
• 추상화는 로직이 앞에서 보이지 않게 제목만 남기고 숨기는 것
• 선언형 프로그래밍은 리액트가 잘 해준다.

after

• 클린코드는 추상화와 선언형 프로그래밍 등을 적절하게 사용하여 사람이 보기 좋은 코드, 협업하기 좋은 코드에 대한 총칭.

• 추상화는 코드를 실체와 유리시켜서 재사용성과 범용성을 높이는 것, 로직이 앞에서 보이지 않게 하는 것은 선언형 프로그래밍과 추상화 단계 쪽이 관련 있다.

• 선언형 프로그래밍이란 하부의 코드들 없이도 제목만 보고도 파악할 수 있게 코드를 짜는 것. 내가 자주 쓰는 커스텀 훅 = 선언적 프로그래밍.
  훅 안에 뭐가 들어있는지 몰라도 변수와 훅 이름으로 로직을 짤 수 있고 불러오는 페이지를 보면 코드의 전체를 파악할 수 있는... 클린코드와도 관련있는 개념.

충돌 없는 협업, 설명이 덜 필요한 코드

before

• 내가 보기 좋은 코드를 짜고 정리함
• 충돌이 발생하지 않게 영역을 철저히 나눔
• 내 코드에 대해 설명'만' 해봄

after

• 다른 사람이 이해할때까지 설명하는 작업보다 다른 사람이 이해할만하게 코드를 짜는게 더 쉽다는 것을 깨달음.

• 변수 이름만 잘 지어도 설명시간 30분 정도가 줄어듦.

• 짧은 기간 동안 협업해야 했기에 작업동선이 많이 겹쳤음, 기존에는 한 파일에 몰아넣던 것을 철저히 훅으로 분리해 충돌을 막고, 컴포넌트를 쪼개는 기준에 대해 논의하는 등 좁은 공간에서 협업하는 법을 익힘.

• 시간을 들여 설명을 한다는 것 자체는 그렇게 중요하지 않고, 이 코드를 1분 전에 처음 본 사람도 그것을 이해할 수 있게 만든다는 결과가 중요함.

• 3시간을 들여서 짠 코드를 설명하는데 3시간이 걸린다면 결과적으로 내 6시간 뿐만 아니라 다른 사람이 그 시간에 할 수 있었던 3시간의 기회비용까지 팀에 청구되는 것.

• 문서화, 시청각 자료 등 적은 단어로 빠른 이해를 가져올 수 있게 하는 스킬이 중요하겠음.

타입스크립트의 사용법

before

• 타입스크립트를 도전했다가 무겁고 불편하고 에러가 엄청 나서 그만둠.
• 면접에서 타입스크립트에 대해 물어봤을때 불편했다고 대답함.

after

• 타입스크립트로 팀 프로젝트를 3개나 완성해봄 + 코스 끝나고 개인프로젝트 1개 더.

• json-server로 백엔드 부분을 구현해놓고 작업하니 전역에서 인터페이스로 사용할 필요성을 느끼고 파일을 분리하게 됨

• 이제 타입스크립트의 장점을 3개는 말할 수 있음

  • 타입 추론이 되었거나 타입을 잘 맞춰서 빨간색이 안떴을때 기분이 좋다.
  • 마우스를 함수나 변수에 호버하면 타입지정해둔 변수나 객체 안에 들어있는 자잘한 이름들이 다 뜨고 자동완성도 잘되어서 db나 명세서를 찾아갈 필요가 없다.
  • 실수로 문자열대신 Date객체를 바로 넣거나 하면 바로 에러가 떠서 넣을때 꼼꼼하게 넣어줘야 하기에... 디버깅타임이 줄어든다.

다른 사람들이 쓰는 스택들, 새로운 스택들

before

• 리덕스 배웠으니까 무조건 리덕스(+툴킷)
• axios는 instance설정 정도만 해주고 리덕스에서 api로직을 관리
• css는 스타일드 컴포넌트 or inline(TailwindCSS)
• 간단한 전역상태를 관리하고 싶을땐 +컨텍스트API

after

• 리코일의 위대함. 리코일을 전역 useState로 보는 관점이 정말 많은 보일러플레이트를 없애줌.

• 이렇게 간단하지만 아직 공식문서의 1/10도 소화 못한거라는게 1차 놀라웠고 이것만으로 기존에 리덕스가 하던 수많은 일들을 대체할 수 있다는게 2차 놀라움.

• 리덕스를 쓰든 리코일을 쓰든 내가 이걸 왜 썼는지에 대해서 자세하게 설명할 수 있는 개발자가 되자.

• axios를 instance화 한 후 이를 다시 api Request로 받아와서 리덕스가 아닌 다른 폴더에서 관리하기. 프론트엔드에서 api 로직만 잘 분리해도 관심사 분리의 50%는 완료된거라고 함.

• SCSS에서 전역 스타일을 지정하고 이를 변수화해서 관리하는 것 또한 많은 매력을 가지고 있는 것 같음. 특히 테일윈드를 많이 사용하면서 가상선택자만 쓰고 네스팅을 거의 버리다시피 했는데 다른 코드들을 보면서 템플릿형의 커스텀 한계에 대해서 한번 더 생각해보게 되었음.

잘 배우는 법, 잘 찾는 법

before

• 공식문서
• 블로그 정리들
• 스택 오버플로우
• codeSandBox
• codePen

after

• 물론 저것들도 여전히 유용하지만 github 자체가 매우 중요하다는 것을 알았음

• 어떤 라이브러리를 쓰다가 에러가 났을때
  - 해당 npm패키지 -> 깃헙페이지 -> 이슈에 가면 있는 경우가 많다.

• 리액트쿼리 등 신기술을 쓰고 싶을때
  - 해당 스택을 깃헙에 검색하면 다양한 상황에서의 레퍼런스가 나온다.

  • 왜 동작하는지에 대해선 여전히 before 애들이 필요하지만 일단 동작은 하는 경우가 많다.

• 어떤 라이브러리를 커스텀하고 싶을 때, 일부만 떼어오고 싶을 때
  - 해당 npm패키지 -> 깃헙페이지에 가서 소스 코드를 보고 필요한 부분만 뜯어오거나 리드미에 써있는 커스텀 옵션을 확인한다.

좋은 UI !== 예쁜 UI

before

• 버튼, 스피너, 드롭다운, 아코디언 등 1차원적인 인터랙션
• 라이브러리를 적극적으로 사용

after

• 스켈레톤, 노티피케이션, 휠다운, 데이트픽커 등 짧은 시간에 다양한 레퍼런스를 찾고 또 그걸 자체구현하는 것을 보면서 단순히 같은 기능에 예쁜 모양을 얹는게 아니라 기능 면에서도 선택의 폭을 넓힐 수 있다는 인사이트를 얻음.

• ui를 잘하는 건 선택이 아니라 필수 <- 기본

• 라이브러리는 편리하지만 커스텀이 안된다. 로열티 문제도 있을 수 있다. 라이브러리 또한 누군가가 만든 것이고 적절한 크롬 개발자도구의 도움만 있다면 사이트 소스를 뜯어보면서 따라 만들 수 있다.

쓴 것

• 5주 간의 시간. 충분히 가치있었다고 생각한다.