jun17183 님의 상세페이지[9팀 신홍준] Chapter 2-1. 클린코드와 리팩토링

과제 링크

https://jun17183.github.io/front_6th_chapter2-1/index.basic.html https://jun17183.github.io/front_6th_chapter2-1/index.advanced.html

과제 체크포인트

기본과제

  • 코드가 Prettier를 통해 일관된 포맷팅이 적용되어 있는가?
  • 적절한 줄바꿈과 주석을 사용하여 코드의 논리적 단위를 명확히 구분했는가?
  • 변수명과 함수명이 그 역할을 명확히 나타내며, 일관된 네이밍 규칙을 따르는가?
  • 매직 넘버와 문자열을 의미 있는 상수로 추출했는가?
  • 중복 코드를 제거하고 재사용 가능한 형태로 리팩토링했는가?
  • 함수가 단일 책임 원칙을 따르며, 한 가지 작업만 수행하는가?
  • 조건문과 반복문이 간결하고 명확한가? 복잡한 조건을 함수로 추출했는가?
  • 코드의 배치가 의존성과 실행 흐름에 따라 논리적으로 구성되어 있는가?
  • 연관된 코드를 의미 있는 함수나 모듈로 그룹화했는가?
  • ES6+ 문법을 활용하여 코드를 더 간결하고 명확하게 작성했는가?
  • 전역 상태와 부수 효과(side effects)를 최소화했는가?
  • 에러 처리와 예외 상황을 명확히 고려하고 처리했는가?
  • 코드 자체가 자기 문서화되어 있어, 주석 없이도 의도를 파악할 수 있는가?
  • 비즈니스 로직과 UI 로직이 적절히 분리되어 있는가?
  • 코드의 각 부분이 테스트 가능하도록 구조화되어 있는가?
  • 성능 개선을 위해 불필요한 연산이나 렌더링을 제거했는가?
  • 새로운 기능 추가나 변경이 기존 코드에 미치는 영향을 최소화했는가?
  • 코드 리뷰를 통해 다른 개발자들의 피드백을 반영하고 개선했는가?
  • (핵심!) 리팩토링 시 기존 기능을 그대로 유지하면서 점진적으로 개선했는가?

심화과제

  • 변경한 구조와 코드가 기존의 코드보다 가독성이 높고 이해하기 쉬운가?
  • 변경한 구조와 코드가 기존의 코드보다 기능을 수정하거나 확장하기에 용이한가?
  • 변경한 구조와 코드가 기존의 코드보다 테스트를 하기에 더 용이한가?
  • 변경한 구조와 코드가 기존의 모든 기능은 그대로 유지했는가?
  • (핵심!) 변경한 구조와 코드를 새로운 한번에 새로만들지 않고 점진적으로 개선했는가?

과제 셀프회고

매우 열 받는 코드

var PRODUCT_ONE = 'p1'
var p2 = 'p2'
var product_3 = 'p3'
var p4 = "p4"
var PRODUCT_5 = `p5`

너무 열 받는 코드입니다. 특히 가장 열 받는 부분은, 뒤늦게 알게 된 백틱. 헛웃음이 나오더라구요. 코드를 보며 다짐한 첫 번째는 어떻게든 이 코드를 물리치자라는 생각이었습니다. 이 코드를 물리치려면 익숙한 포맷으로 수정해야겠다고 판단하였고, 1주차 과제를 떠올리게 되었습니다.

1주차엔 pages와 components 폴더를 통해 ui를 그리는 부분을 나누었고, 옵저버 패턴을 위해 state 폴더를 두고 각 페이지와 컴포넌트에서 state를 구독하였습니다. 이 구조를 그대로 사용하되 준일 코치님의 솔루션을 참고하여 redux와 비슷한 구조로 리팩토링 하기로 했습니다.

그러나,,,


나도 모르는 내 코드

Pasted image 20250729212427

정신 차리고 보니 순식간에 많은 파일이 생겨났고, 각 파일이 어떤 역할인지 스스로도 잘 모르는 지경에 이르렀습니다. 1주차에서 AI에게 마구잡이로 명령을 내릴 때와 비슷한 상황이었습니다. 아무래도 무자비한 더티 코드에 압도되어 빨리 해결해야 한다는 마음이 컸던 것 같습니다.

(맛이 가버린 AI) Pasted image 20250730020424


가장 익숙한 걸 해보자

처음 과제를 시작할 때 익숙한 포맷으로 수정해야겠다고 생각했는데 어쩌면 1주차에서 사용했던 구조는 아직 익숙하지 않는구나 싶었습니다. 그래서 더욱 익숙한 포맷으로 빠르게 진행하기로 마음 먹었습니다. 항해에는 잘하시는 분들이 워낙 많고 다들 멋지게 리팩토링을 해내겠지만, 저는 욕심을 버리고 가장 익숙한 코드인 전 회사에서 일할 때 코드와 비슷하게 작성해 보기로 했습니다.

프론트엔드 프레임워크를 사용하지 않는 SI 환경에서는 주로 페이지 단위로 코드를 작성하게 됩니다. (업무 분담을 페이지 단위로 하는 경우가 많기 때문...) 그렇기 때문에 한 파일의 코드량은 많고 가독성이 좋지 않을 수도 있습니다. 하지만 특정 기능을 참고하고 싶다면 그 파일만, 혹은 그 폴더만 확인하면 되는 장점이 있습니다.

두 번째로 jQuery 기반의 환경에선 코드를 크게 데이터 관리, 화면 관리, 이벤트 관리 세 가지로 나누어 작성합니다. 그리고 이벤트가 일어나는 곳에서 데이터 업데이트와 화면 업데이트를 모두 진행합니다. 이 점이 상태를 업데이트하면 이에 따라 화면을 업데이트 하는 리액트와의 가장 큰 차이점이라고 생각합니다.

event -> state / event -> render 보다 event -> state -> render가 훨씬 좋은 구조라고는 생각하지만 이번 과제를 처치하기 위해 전자를 택했습니다.

image

큼직큼직하게 Hedaer, SelectBox, CartList, CartTotal, Manual로 나누었습니다. 아마 기존 방식이라면 장바구니에 상품을 추가할 때 state가 바뀔 거고 이를 바라보는 Header에선 상품 수 수정, CartList에선 상품 추가, CartTotal에선 총 가격 계산을 하게 됩니다. 이걸 ADD TO CART 버튼을 클릭하면 직접 해주어야 하는 겁니다.

image

이전 회사 스타일로 코드를 작성하니 적어도 나만큼은 이 코드에 대해 이해도가 높고 가독성이 좋았습니다. 다만 스스로도 좋은 구조가 아니라고 생각했기에 클린 코드에 대해 더 공부하고 이를 적용하고 싶었습니다. 하지만 이미 시간이 얼마 없는 상태라 심화 과제를 서둘러 진행하게 되었고, 이마저도 AI에게 거의 전부 맡기게 되었습니다.


과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?

이제 4주차지만 아쉬움이 가장 많이 남았습니다. 첫 번째론 클린 코드에 대한 학습을 결과적으로 많이 얻진 못했던 것 같습니다. 클린 코드란 무엇인지 좀 더 공부하고 알아보고 이를 직접 코드로 치며 적용해야 좋은 학습을 했다고 할 수 있을 텐데, 과제 해결을 위해 익숙함을 택하게 되었습니다.

두 번째도 같은 맥락인데, 심화 과제에서 AI 비중이 너무 컸습니다. 테스트 코드 작성부터 이를 통과하기 위한 코드까지 모두 AI만을 통해 진행했습니다. AI가 코드를 작성하고 이 코드를 분석하는 주객전도 상황이 펼쳐졌습니다. 이후 코드를 직접 읽어보며 추가 리팩토링을 진행하였지만 이 과정에서도 클린 코드에 대한 추가 학습 없이 기존에 가지고 있던 코드 스타일로 리팩토링 하였습니다.

아직 클린 코드 주차가 남았으니 더 공부하여 다음엔 멋드러진 코드를 작성하고 싶습니다.


리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)

1. 좋은 커스텀 훅은 무엇인지, 커스텀 훅은 어떤 식으로 작성해야 하는지 궁금합니다.

image

위 코드는 자동 할인을 다루는 훅입니다. 저는 번개 세일, 추천 할인은 같은 자동 할인이라는 카테고리로 묶을 수도 있으며 timer를 편하게 관리한다는 점에서 하나의 훅으로 작성했습니다. 하지만 작성하고 보니 코드 길이도 길고 가독성도 안 좋아 보입니다. 무엇보다 역할이 2개인 점에서 좋은 코드가 아닌 거 같다고도 생각했습니다.

위와 같은 경우 어떤 식으로 코드를 작성하면 좋은지 여쭤보고 싶습니다!

2. 컴포넌트는 어느 정도 단위로 나누어야 할까요?

image

위 장바구니 총합 부분만 보더라도 나눌 수 있는 항목이 굉장히 많아 보입니다. 상품 목록부터 Subtotal, Total, 할인, 포인트 등등 잘게 쪼개려면 모두 쪼갤 수 있을 거 같습니다. 하지만 이렇게 작은 규모인데도 나눌 부분이 많은데 위와 같은 항목을 모두 나누어 버린다면 오히려 프로젝트가 너무 비대해질 거 같습니다.

컴포넌트는 어떤 단위로 나누면 좋을까요? 프로젝트의 규모에 따라서도 달라질까요?


토요일) 코드 리뷰 받고 싶은 내용

1. basic > 기능은 render, data, event로 나누고 컴포넌트는 크게 Header, SelectBox, CartList, CartTotal, Manual로 큼직큼직하게 나눈 편인데 어떻게 생각하시나요??

image

2. 리액트 실무 경험이 없어서 여쭤보고 싶은데 컴포넌트 단위를 어느 정도로 나누는 편이신가요? 잘게 나누려면 정말 한없이 잘게도 나눌 수 있을 거 같아 헷갈리더라구요.

과제 피드백

홍준님 수고많으셨습니다!

Q. 좋은 커스텀 훅은 무엇인지, 커스텀 훅은 어떤 식으로 작성해야 하는지 궁금합니다.

일단 useAutoEvent 아이디어는 좋다고 생각합니다. 그리고 사실 답이 정해진 것은 아닐 것 같아요. 저라면 "번개세일", "추천할인"을 별도의 코드로 구분하지 않고 데이터로 활용할 것 같아요. . ...음 저라면 어떻게 할지 적으려니까 너무 많아지는 것 같아서요. 저라면 할 것을 요약하면..

구조적인 것보다는 코드를 리팩토링해서 중복되는 코드를 제거할 것 같아요. 핵심은 이벤트를 추상화해서 번개인지 추천할인인지는 데이터로 구분하겠다 입니다. 그리고 만들어진 이벤트 목록을 start, destory하는 인터페이스를 노출하게 될 것 같아요. 이렇게되면 n개의 타입을 가진 n개의 이벤트를 관리할 수 있게 확장할 것 같습니다. 왜냐하면 번개세일과 같은 프로모션 타입은 언제든지 늘어날 수 있으니까요. 이벤트라는 것을 추상화해서 이 이벤트가 어떤 타입인지를 아는 코드를 줄이겠다는 것이 큰 아이디어입니다.

Q. 컴포넌트는 어느 정도 단위로 나누어야 할까요?

A. 정답이 없는 것 같아요~ 다만 컴포넌트를 나누려고 나누기보다는 컴포넌트가 나눠달라고 신호를 보낼때 나눠도 충분하다는게 제 생각입니다 너무 나누는 것부터 시작하시지 마시고 큰 덩어리 컴포넌트 하나라도 괜찮으니 기본적이 아이디어로만 나누고 일단 시작하면서 코드가 보내는 신호를 보면서 그때그때마다 분리하고 혹은 반대로 합쳐도 됩니다.

그 신호는 로직의 그루핑이 될 수 있고, 코드의 재사용일 수도, 혹은 코드의 길이 일 수도 있습니다. 너무 나누는 것에 집착하실 필요 전혀 없습니다! 나누면 나눌수록 아시다시피 코드를 읽는 시간이 더 걸립니다!