이 강의를 선택하게 된 이유

이 강의를 듣기 전까지는 사실 output을 내는 것에만 집중했다. 내 손으로 뚝딱뚝딱 만들어지는게 재밌어서 뭐든 만들어보고 싶었다. 그래서 회사 프로젝트가 조금 여유로워질때면 사이드 프로젝트를 진행했는데, 부족한 실력이었기에 input과 output 두 마리 토끼를 모두 잡으면서 결과물을 내는 것이 쉽지 않았다. 기술적인 개념들의 정확한 이해와 코드 품질에 대한 개선은 신경쓰지 못했고 우선 어떻게든 돌아가게 만드는 것에 집중했다.

그런데 문제는 열심히 만든 결과물이 보기에는 그럴싸했는데 코드를 보여주는 순간 한 없이 작아지는 나를 발견했다. 회사에서는 내가 작업한 파일을 동료가 수정해야할 때 "아... 그거 좀 복잡할거에요"라는 말이 우선 나오며, 사이드 프로젝트의 코드도 중구난방 복잡했다.

다른 사람들이 읽기 쉬운 좋은 코드란 무엇인가? 내가 짜는 코드가 과연 안전한 것일까? 이런 궁금증들을 가지게 되었다. 그러다 친한 지인의 추천으로 넥스트스텝의 클린코드 강의를 알게 되었고 내 고민들에 대한 정답을 찾을 수 있을 것 같아 신청하게 되었다.

강의 진행 방식

넥스트 스텝 링크

일주일에 한번씩 강의가 있고, 코드리뷰를 해주는 미션이 3가지(온보딩 미션 1개 + 공식 미션 2개) 있고 이에 따라 리뷰어 분도 바뀐다. 그래서 여러 시각으로 리뷰를 받을 수 있었고 빅테크 개발자들은 어떤 생각을 가지고 코드를 짜는지 직접 물어보고 답변을 들을 수 있었기에 코멘트 하나하나가 정말 값지다고 느꼈다.

그리고 일주일에 한 번씩 있는 강의도 정말 좋았는데 리액트에 대한 중요한 개념 + 프론트엔드 개발자가 현실적으로 고민해야하는 부분들을 많이 일깨워주셨다.

아래는 진행된 미션 PR 링크들이며 각 미션별로 step3까지 있다.

페이먼츠 미션

https://github.com/next-step/react-payments/pull/55

https://github.com/next-step/react-payments/pull/88

https://github.com/next-step/react-payments/pull/97

쇼핑카트 미션

https://github.com/next-step/react-shopping-cart/pull/3

https://github.com/next-step/react-shopping-cart/pull/25

나는 무엇을 알게 되었나?

가독성 좋은 코드를 짜는 방법

좋은 개발자의 조건 중 하나가 글을 잘 쓰는 것이다. 글을 잘 쓴다는 것은 읽는 사람의 입장에서 술술 잘 읽히고 이해가 잘 된다는 것이며 개발에서도 비슷한 맥락으로 이해할 수 있다. 코드를 처음 보는 사람도 어떤 코드인지 이해가 잘 되는 코드가 클린코드, 즉 가독성이 좋은 코드이다.
그래서 미션을 할 때 리뷰어님에게 편지를 보낸다는 느낌으로 많은 고민을 하며 코드를 짰다.

• 네이밍을 어떻게 하면 한눈에 내 의도를 파악할 수 있을까?
  • 무조건 짧은 것이 좋은 건 아니다. 길더라도 파악하기 좋은 네이밍으로!
  • 매직넘버는 상수로 그 숫자의 의미 알 수 있도록 하기.
• 코드를 모듈화 시키면 리뷰할 때 더 보기 편하지 않을까?
  • constant, util, type 등 파일들은 같은 관심사 묶기
• 관리하기 쉽도록 하려면 어떻게 해야하지?
  - 관리포인트가 여러군데라면 상수, 모듈화를 통해 관리 포인트 줄이기!
  • ex) router path를 상수로 만들어두면 수정시 매우 편함. 하나만 수정하면 되니깐!

그리고 이런 고민들이 보여서 재밌었다는 리뷰어님의 코멘트에… 한글로 쓴 것도 아닌데 코드에 녹아져있는 생각이 보였다는게 정말 신기했다. 코딩은 글쓰기와 비슷하다는 것을 정말 많이 깨달았다.

Context API, reducer 잘 활용하기

Context API는 일정 구간의 컴포넌트 트리에서 상태를 간편하게 공유할 수 있도록 도와주는 API이다. props drilling이나, 동일한 props를 많은 컴포넌트에 공유해야 할 때의 불편함을 해결할 수 있다.

reducer는 상태 로직을 업데이트하는 함수들을 하나로 관리할 수 있게 도와준다. 하나의 상태를 업데이트하는 로직이 다양할 때 reducer로 로직의 type을 정해서 관리할 수 있다.

그리고 이러한 두 가지 도구는 궁합이 좋아서 함께 사용하면 상태 관리가 명료하고 간단해지는 장점이 있는데 명심할 점은 두 가지가 꼭 세트가 아니라는 것..!

CDD를 위해 스토리북은 어떻게 잘 활용할 수 있을까?

CDD란 Component Driven Development로 UI 컴포넌트를 중심으로 개발하는 방법이다. 스토리북은 CDD 개발의 최적화된 도구이며 실제 프로젝트와 독립된 환경에서 컴포넌트 단위로 UI를 만들어 문서화하고 테스트 할 수 있다.

CDD는 디자인 시스템에는 거의 필수이나 현실적으로 일정이 촉박한 일반 프로젝트에서는 CDD를 완벽하게 따라가기에는 어려움이 있다. 그래도 디자인 시안에서 보이는 공통된 input, button 등은 재사용할 수 있도록 같이 작업하는 것이 좋을 것 같다는 생각이 든다.

Controlled & uncontrolled components

controlled, uncontrolled component는 각자의 장단점이 있기 때문에 상황에 따라 선택하는 것이 좋다.

controlled component는 react의 useState를 사용해서 상태를 제어하는 것이다. 그렇기 때문에 React의 렌더링 주기에 들어가 있어 예측 가능한 코드 작성이 가능하며, 사용자가 입력하는 값을 UI에 즉시 업데이트할 수 있기 때문에 UX적인 측면에서도 좋다. 그러나 복잡한 UI에서는 리렌더링으로 인해 성능이슈가 있을 수 있기 때문에 주의해야한다.

uncontrolled component는 브라우저에 있는 form 요소의 value값을 직접 사용자가 변경하고 그 값을 가져오도록 구현하는 방식이다. react의 상태를 사용하지 않기 때문에 리렌더링이 없고 빠르다.

컴포넌트를 컴포넌트 답게 사용하기

컴포넌트를 재사용가능하게 만들기 위해서는 사이드이펙트가 없어야한다. 즉 순수함수로 만들어서 어디서든 재사용가능하도록 만드는 것이다.
그리고 컴포넌트의 목적에 대해서도 생각해보아야 한다. 그 목적에 따라 사이드 이펙트를 어디까지 허용할 것인지 정하는 것도 필요하다.

프론트엔드 개발자에게 필요한 테스트

기능, 디자인 수정요청이 쏟아져도, 앞의 일정이 늘어나도 개발 일정은 그대로인 상황이 나만 그런게 아닌 프론트엔드 개발자의 숙명이라는 걸 알게 되었고, 이에 대응하기 위해서 프론트엔드 개발자는 가만히 있어선 안되고 개발 일정을 맞추기 위한 테스트를 수행해야한다. 프론트엔드에서 현실적인 테스트는 스토리북을 사용해 재사용가능한 컴포넌트를 만들어 UI 테스트를 해볼 수 있으며, 백엔드 API가 완성될떄까지 가만히 있는 것이 아니라 MSW로 직접 API 테스트를 해볼 수도 있다.

느낀점

이 과정을 통해 평소 실무에서 본능적으로 하고 있었던 것들에 대해 구체화할 수 있었고 몰랐던 것들도 많이 깨달을 수 있었다. 그리고 넥스트 스텝의 교육 퀄리티도 정말 좋았는데 강사님, 리뷰어 분들께 얻는 인사이트도 크고, 같은 미션을 하는 참가자들의 코드를 함께 볼 수 있는데 거기서 얻는 꿀팁들도 꽤 많았다.

그리고 "왜?"의 중요성을 새삼 다시 한번 깨달을 수 있었는데 이러한 질문을 통해 깊이 있는 공부가 가능해지고, 궁금증을 통해 흥미가 더 생기는 나 자신을 볼 수 있었다.

아쉬운 부분

2달이라는 시간동안 좀 더 집중해서 했어야하는데 회사와 병행하는 것이 시간적으로 부족했고 체력적으로도 힘들었다. 그래서 마지막 미션을 제대로 마무리하지 못한 상태라 아쉬움이 크다... 미루지 말고 제때 해야한다는 것을 또 한번 깨닫는다.

앞으로의 계획

클린코드 리액트에서 배운 것을 토대로, 혼자서 프로젝트를 하나 해보려 한다. 부족한 react 개념과 깊이 있는 학습을 통해 프로젝트 하나를 제대로 완성해보고 싶어졌다.