배포 링크
https://soyalattee.github.io/front_6th_chapter2-1/
과제 체크포인트
기본과제
- 코드가 Prettier를 통해 일관된 포맷팅이 적용되어 있는가?
- 적절한 줄바꿈과 주석을 사용하여 코드의 논리적 단위를 명확히 구분했는가?
- 변수명과 함수명이 그 역할을 명확히 나타내며, 일관된 네이밍 규칙을 따르는가?
- 매직 넘버와 문자열을 의미 있는 상수로 추출했는가?
- 중복 코드를 제거하고 재사용 가능한 형태로 리팩토링했는가?
- 함수가 단일 책임 원칙을 따르며, 한 가지 작업만 수행하는가?
- 조건문과 반복문이 간결하고 명확한가? 복잡한 조건을 함수로 추출했는가?
- 코드의 배치가 의존성과 실행 흐름에 따라 논리적으로 구성되어 있는가?
- 연관된 코드를 의미 있는 함수나 모듈로 그룹화했는가?
- ES6+ 문법을 활용하여 코드를 더 간결하고 명확하게 작성했는가?
- 전역 상태와 부수 효과(side effects)를 최소화했는가?
- 에러 처리와 예외 상황을 명확히 고려하고 처리했는가?
- 코드 자체가 자기 문서화되어 있어, 주석 없이도 의도를 파악할 수 있는가?
- 비즈니스 로직과 UI 로직이 적절히 분리되어 있는가?
- 코드의 각 부분이 테스트 가능하도록 구조화되어 있는가?
- 성능 개선을 위해 불필요한 연산이나 렌더링을 제거했는가?
- 새로운 기능 추가나 변경이 기존 코드에 미치는 영향을 최소화했는가?
- 코드 리뷰를 통해 다른 개발자들의 피드백을 반영하고 개선했는가?
- (핵심!) 리팩토링 시 기존 기능을 그대로 유지하면서 점진적으로 개선했는가?
심화과제
- 변경한 구조와 코드가 기존의 코드보다 가독성이 높고 이해하기 쉬운가?
- 변경한 구조와 코드가 기존의 코드보다 기능을 수정하거나 확장하기에 용이한가?
- 변경한 구조와 코드가 기존의 코드보다 테스트를 하기에 더 용이한가?
- 변경한 구조와 코드가 기존의 모든 기능은 그대로 유지했는가?
- (핵심!) 변경한 구조와 코드를 새로운 한번에 새로만들지 않고 점진적으로 개선했는가?
과제 셀프회고
과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?
이번 과제에서 가장 신경 쓴 부분은 관심사 분리 원칙을 적용해 코드 구조를 개선하는 것이었습니다. 기존에는 모든 기능이 하나의 파일에 몰려 있어 가독성과 유지보수성이 떨어졌습니다.
역할 기반 모듈화
기능을 다음과 같이 역할별로 나누어 파일을 분리했습니다.
- eventHandlers: 이벤트 리스너 정의
- renderUI: UI 렌더링 관련 함수
- constants: 상수 정의
- discountEvent: 할인 알림 처리
또한 유저 액션에 따라 화면을 업데이트하는 함수는 update{화면이름}.js 패턴으로 파일명을 통일해 구조화했습니다. 이러한 리팩토링을 통해 코드의 응집도를 높이고 결합도를 낮추어 특정 기능을 수정할 때 관련된 파일만 집중해서 볼 수 있도록 구조를 개선했습니다.
가독성 향상
이번 과제를 하며.. 축약형 변수들이 얼마나 이해하는데 시간이 소요되며, 휴먼 에러를 발생시키는 원인이 될 수 있음을 몸소 느꼈습니다. 축약형 변수(p1, val, q)는 의미를 파악하기 어려워 휴먼 에러의 원인이 되기도 했습니다. 이에 따라 PRODUCT_1, price, quantity처럼 의미가 명확한 이름으로 변경하여 코드 이해 시간을 줄이고 오류 가능성을 줄였습니다.
데이터와 로직 분리
JavaScript 코드 내에 하드코딩되어 있던 상품 데이터를 products.json 파일로 분리했습니다.
이를 통해 데이터 관리의 유연성을 높이고, 로직은 데이터의 형태에만 의존하도록 만들어 코드의 재사용성을 높였습니다.
과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?
로직 분리를 위한 커스텀 훅
App 컴포넌트에 있는 번개세일과 추천 할인 타이머 로직은 컴포넌트를 복잡하게 만들고 있었습니다.
이를 커스텀 훅으로 분리했더라면 UI와 로직의 관심사가 분리되어 컴포넌트가 더 명확한 책임을 가질 수 있었을 것입니다.
그 외에도 시간이 부족해 대부분의 컴포넌트들을 UI와 로직을 분리하지 못해 아쉬움이 남습니다.
시간관리
기본 과제에서 너무 많은 시간을 들인 나머지, 심화 과제를 급하게 마무리하게 된 점이 아쉬웠습니다. 다음에는 리팩토링 기준을 명확히 정하고, 시간을 분배하여 기본 과제를 일정 수준에서 마무리하고 심화 과제에 집중할 수 있도록 하겠습니다.
테스트 코드의 부재
가장 아쉬운 부분은 심화과제에서 테스트 코드가 없었다는 점입니다. 리팩토링 후에도 기존 기능이 동일하게 동작함을 검증할 수 있는 가장 확실한 방법은 테스트 코드라고 생각합니다. 바로 개발에 들어갔다가 기존버전과 기능을 일일이 비교하며 시간을 많이 쏟아 뒤늦게 후회했습니다.. 다음 과제에서는 **테스트 우선 개발(TDD)**을 시도해 보고 싶습니다.
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)
이번 과제에서는 리팩토링에 시간을 들이다 보니 시간 관리가 아쉬움으로 남았습니다. 실무에서도 리팩토링에 어느 정도 시간을 들여야 할지 항상 고민이 되는데요, 리팩토링 범위나 기준에 대해 조언해주실 부분이 있다면 듣고 싶습니다!
과제 피드백
고생하셨습니다 소연님! 꽤 과제양이 많았던 것 같은데 그래도 마무리를 잘 해주셨네요! 전반적으로 작성해주신 코드를 보면 아직까지는 조금 더 개선할 여지가 많이 남아있는 것 같아요! 한 함수 또는 컴포넌트에서 너무 많은 책임을 갖고 있는 부분도 보이고 절차적으로 쭉 나열이 되어있다보니 가독성 측면이나 추후 유지보수를 하는데 있어서도 아쉬운 부분도 있구요!
회고에 작성해주신 것 처럼 리팩토링에 시간을 많이 들이다보니 전반적인 시간 관리가 아쉬웠다고 말씀을 해주셨는데요. 사실 현업에서 이런 전체적인 리팩토링을 1주일안에 모두 마무리 하는 경우는 크게 없죠 ㅎㅎㅎ 큰 수정인 경우 명확한 검증이 뒤따라야 하니까요. 다만, 경험적인 측면에서 그리고 리팩토링 기법을 훈련한다는 측면에서 작게작게 단위를 나눠보면 좋을 것 같아요. 이런 주제들은 테오가 피피티 또는 블로그를 통해 공유해주신 글들을 참고하면 좋을 것 같은데요. 여기서 등장하는 하나의 소제목 대제목들을 내가 이번 리팩토링 기한내에 이번 모듈에서 해결한다는 관점에서 가는거죠. 요즘은 AI를 활용할 수 있으니 모듈의 범위를 좀 더 넓게 잡고 한번에 개선하고 검토하는 것도 방법이 될 수 있겠죠?
개인적으로는 이런 주제를 전부 AI에게 던지고 수정을 맡기는것보다는 어떤 과정으로 작업을 진행할 지 물어보고 검토를 하면서 수정을 진행하는 형태나 작게 작게 명확한 작업 지침을 주고 검토하는게 작업속도 측면에서 아직 괜찮더라구요. 아니면 rules를 매우 구체적이게 주는 것도 방법일 수 있구요.
아무튼 말이 길었는데, 정리하면 리팩토링의 단위는 작게 그리고 검증 이에 따른 반복이 핵심입니다. 작성해주신 것 처럼 검증 단계를 명확하게 하는 연습이 필요합니다.
담주도 화이팅입니다~