[6팀 이지현] Chapter 2-1. 클린코드와 리팩토링

[j2h30728]

과제 체크포인트

• https://j2h30728.github.io/front_6th_chapter2-1/

기본과제

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

심화과제

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

과제 셀프회고

과제 코드를 보자마자 너무 놀라 까무라쳤습니다. 정말 더러운 코드라고 걱정해줬던 테오가 바로 생각 나더라구요.

더럽다는 기준은 주관적이라고 생각합니다.
그렇기 때문에 '어쩌면 내 코드가 누군가에게는 이렇게 더러운 코드이지 않을까?' 라는 산뜻한 마음으로 과제를 시작했습니다.

물론 생각보다 양이 많고 방향 잡기가 어려웠지만, AI에게 내가 원하는 방향을 지시하는 경험을 해보니 그 또한 새롭고 즐거웠습니다.

과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?

1. 리팩토링 우선순위

var를 let와 const로, 재할당하지 않는 변수를 const로 리팩토링하면서 문득 1주차 과제가 생각났습니다.

1주차에서 더티코드를 작성하고 리팩토링을 해야겠다는 다짐을 했었습니다.
그러면서 코치분들께 리팩토링 순서에 대해서 조언 받았었습니다.
상태관리 → 라이프사이클 → 이벤트시스템 였으며, 이번과제를 진행하면서 해당순서대로 시도했습니다.

• observer 패턴과 store패턴을 기반으로 상태관리 시스템
• (Element) WeakMap > (Event Type) Set > (handler) Map 의 자료구조와 이벤트 위임을 가지는 이벤트 시스템

또한, 1챕터에서 배웠던 내용을 가져와 AI에 지시하여 리팩토링을 진행했습니다.
정말 깔끔하고 멋진 코드를 만들지는 못했지만, 이미 완성된 코드를 이전 챕터의 내용을 복습하면서 리팩토링 해보는 경험은 무지 즐거웠습니다.

2. 편리한 컨벤션 통일

페어2팀은 과제 시작전에 함께 팀의 컨벤션과 pretttier, eslint 설정을 맞추고 시작했습니다.

좋은 팀원들 덕분에 pretteir와 eslint 설정을 편하게 할 수 있었습니다.

하지만, 익스텐션에 의존하기보다는 프리커밋훅을 사용하여 커밋시에 린트와 타입체킹을 하여 컨벤션 뿐만 아니라 안정성을 지키는 것을 제안하고 설정을 공유했습니다.

과제 진행에 벅차, 해당 프리커밋 훅을 모든 팀원들이 적용하지는 못한 아쉬움은 있지만 의도에 맞게 역할을 한 것같아 기뻤습니다.

3. 테스트 코드

테스트 코드의 중요성을 체감했습니다. 리팩토링을 진행하면서 basic.test.js 테스트 코드로 기능 유지를 안정성을 보장할 수 있었습니다.
리액트로 마이그레이션을 진행하는 심화과제에서는 AI의 도움을 받아서 basic.test.js와 유사한 (당시 질문할때 88%이상) advanced.test.tsx 테스트코드를 작성하였습니다.
덕분에 기본 기능을 유지한채로 원하는 방향으로 리팩토링할 수 있었습니다.

리팩토링 및 기능 추가/수정 시에 사이드 이펙트를 막기위해 테스트 코드가 중요한 것을 이론으로만 알고있었습니다. 기본과제와 심화과제를 통해 해당 부분을 더 체감할 수 있어 즐거웠습니다.

4. 폴더구조

Vanilla JS에서의 고민:
항상 리액트에서만 코드를 작성하고 폴더구조를 고민하다보니 바닐라 자바스크립트에서의 좋은 폴더구조는 무엇인지 감이 오지않았습니다.

선택한 구조와 이유:

• features/ 중심 구조를 선택한 이유: 도메인별 응집도를 높이고, 관련 기능끼리 모아두어 찾기 쉽게 하기 위함
• 각 feature 내부에서도 계산 로직(calculationService.js)과 UI 로직(uiUtils.js)을 분리하여 관심사 분리 원칙 적용

src/basic/
├── features/           # 기능별 모듈화
│   ├── cart/
│   ├── product/
│   ├── discount/
│   └── ui/
├── components/         # UI 컴포넌트
├── utils/             # 유틸리티
└── constants/         # 상수

React에서의 구조:
팀컨벤션 기준으로 네이밍을 지정하였으며, 익숙한 구조로 정리했습니다.

• lib/: 순수 비즈니스 로직 (React와 독립적)
• hooks/: 상태 관리 로직 (React 종속적)
• components/: UI 컴포넌트 (도메인별 분리)

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

1. 기준

기본과제는 어디까지 리팩토링을 해야하는 지 기준을 잡지 못해 아쉬운 점이 많습니다.
AI를 적극 활용하면서 진행했지만, 세부적으로 마음에들지 않는 부분이 있습니다.

다시 해본다면 큰틀을 먼저 잡고 클린코드 및 깔끔한 설계를 위해 좀더 고민하고 세부적으로 조정해 볼 것같습니다.

2. 페어 프로그래밍

시작은 페어 팀의 팀원분들과 페어프로그래미을 해보는 것이 목표였습니다.
하지만, 서로 시간과 진도가 맞지않아서 팀에서의 최선의 방법을 선택했습니다.

동일한 리액트 보일러플레이트, eslint, prettier, husky를 설정한뒤에 원하는 방식으로 리팩토링을 하고난 뒤, 코드리뷰를 진행하는 것입니다.
아직, 시간여유가 없어서 코드리뷰를 원활하게 하지는 못했지만 팀원분들과 함께 서로 코드리뷰를 할 계획입니다.

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

테오라면 이 과제의 리팩토링에서 제일 중점적으로 볼 것 같은 요소가 있을까요?
물론, 변수 선언과 중첩 if 문 등 많은 것들이 중요하다고 생각합니다.
컨벤션, 설계, 구조 등 어떤 부분을 제일 중요하게 여기고 리팩토링시에 집중하실 것인 가요?

[k-sang-soo]

고생하겼습니다 지현님!!!!!