jtwjs Dev Wiki
  • DEV_ROAD
    • 💪🏻 생존하기
    • Week 1
      • 개발 환경 세팅
      • 타입스크립트
      • 리엑트
      • Testing Library
      • Parcel & ESLint
    • Week 2
      • JSX
      • Virtual DOM
    • Week 3
      • React Component
      • React State
    • Week 4
      • Express
      • Fetch API & CORS
      • React Hook
      • useRef & Custom Hook
    • Week 5
      • TDD
      • React Testing Library
      • MSW
      • Playwrite
      • Snapshot
    • Week 6
      • Separtion of Concerns
      • Principle
      • DI, (Dependency Injection)
      • Reflect-metadata
      • TSyringe
      • External Store
      • Follow Redux
      • usestore-ts
      • useSyncExternalStore
    • Week 7
      • Routing
      • Routes
      • Router
      • Navigation
    • Week 8
      • Design System
      • Style Basics
      • CSS-in-JS
      • Styled-Components
      • Global Style & Theme
    • Week 9
      • 개발하기 전 준비
      • 상품 목록 페이지
      • 상품 상세 페이지
      • 장바구니 페이지
    • Week 10
      • 로그인
      • 로그아웃
      • 회원가입
      • 주문 목록 & 주문 상세
    • Week 11
      • 배송 정보 입력
      • 포트원 결제 요청
      • 배송 및 결제 정보 전달
    • Week 12
      • 관리자 웹사이트개발시작
  • DEV_NOTE
    • TypeScript
      • 기본적 문법
        • Enum
        • 다형성
          • Untitled
        • 구조적 타이핑
        • 제너릭 타입
        • 컨디셔널 타입
        • 함수 메서드 타이핑
        • infer로 타입스크립트의 추론 직접 활용
        • 재귀 타입
        • 템플릿 리터럴 타입
        • 추가적인 타입 검사 satisfies 연산자
        • 타입스크립트 건망증
        • 원시 자료형에도 브랜딩 기법 사용 가능
        • 타입 좁히기
        • 유용한 타입 만들기
        • 데코레이터 함수
        • 앰비언트 선언도 선언 병합이 된다.
        • 앰비언트 선언도 선언병합이 된다.
    • Testing
      • Unit Testing
      • 단위 테스트의 두 분파
      • 좋은 단위 테스트를 구성하는 4대 요소
      • 테스트 대역과 식별할 수 있는 동작
      • 단위 테스트 스타일
      • 가치 있는 단위 테스트를 위한 리팩토링
      • 통합 테스트
      • Cross Browsing Testing
      • 기능 테스트 종류
      • React Testing Pattern
      • 프론트엔드 테스트 입문
        • 테스트 범위
        • 단위 테스트 검증
        • Mock
        • UI 컴포넌트 테스트
        • 테스트 커버리지
        • 웹 통합 테스트
        • MSW
        • 스토리북
        • 시각적 회귀 테스트
        • E2E 테스트
        • Github Actions 설정
        • 깃허브 액션에서 E2E
      • 시프트 레프트
        • 테스트 기본중의 기본
        • 단위 테스트
        • 코드 복잡도
        • 리팩터링
        • 코드 리뷰
        • 통합 테스트 패턴
        • 시스템 테스트의 자동화
        • 탐색적 테스트
      • Test Tip
      • vitest
      • playwright
      • Test Data Generator
      • MSW
    • Algorithm
      • coding test
      • Data Structure
    • Next.js
      • Data Fetching
      • Hydration
      • Next 13
      • Optimization
      • Next 15
        • ETC.
    • Tailwind
      • Tailwind CSS
      • Theme
      • Directives
      • Tool
      • Design System
      • Shadcn UI
    • Storybook
      • Storybook
      • CSF3
      • CDD
      • Headless Component
    • Funtional Programming
      • 함수형 프로그래밍
      • 참조 투명성
      • 부수효과
      • 함수 합성
      • 제너릭 타입 활용하기
      • 암묵적 입출력
      • 액션과 계산, 데이터
      • 계층형 설계
      • 호출 그래프
      • 함수형 설계
      • 불변성
      • 일급 함수
      • 함수형 도구
    • Git
      • Github Actions
      • Conflict
      • Branch 전략
    • Contents Format
      • Audio
    • 3D Graphic
      • 3D keyword
      • Three.js
      • Geometry
      • Material
      • Light
      • Camera
      • Decal
      • Rotation
      • Text
      • Shadow
      • Fog
      • Post Processing
      • Animation
      • Math
        • Vector Space
        • 벡터의 연산
        • 회전 계산
      • 3D 컨텐츠가 만들어지는 과정
      • R3F
      • Env
      • Scene
      • Transform
      • R3F
      • Interaction & Raycast
      • Rendering Algorithnm
      • Blender
    • Accessibility
      • 접근성이란
    • Interactive Web
      • Parallax
      • Canvas
      • requestAnimationFrame
      • Effect
      • HSL
      • React.js + Canvas
      • Matter.js
    • AWS
      • DevOps
      • Amplify
      • S3
      • 클라우드 컴퓨팅
        • 온프레미스와 클라우드
        • 클라우드 도입효과
        • 클라우드 컴퓨팅의 범위
        • 컴퓨팅 옵션
          • EC2 - Virtual Machin
          • ECS, EKS - Container
          • Lambda - Serverless
        • 네트워크 가상화
        • 스토리지
        • 데이터베이스
        • 데이터 수집
        • 머신 러닝 영역
        • IoT 영역
        • 블록체인 영역
      • 클라우드 아키텍처 설계
    • Network
      • Web Server & WAS
    • System Design
      • System Design
      • Component
      • 의존성을 배제한 개발
      • Error Handling
      • Architecture
        • 모노로틱 아키텍처
        • Clean Architecture
        • Layered Architecture
        • 이벤트 기반 아키텍처
      • 상황을 파악하는 메타인지
      • 중복 문제 해결하기
      • Monorepo Arhitecture
        • 모노레포 운영과 트러블슈팅
        • Module Federation
      • 코드 병목지점
      • API 대응
      • 공통 코드
      • Infra 구축
      • 모듈 기반의 개발 방식
      • Design System
        • 최소 수준의 아키텍처 설정
        • 더 효율적인 디자인시스템 만들기
        • 디자인 시스템과 UI 라이브러리 목적
        • 디자인 토큰
      • 효율적인 업무
        • 업무 프로세스 병목 파악
      • Clean Code
      • Design Pattern
        • CQRS Pattern
        • Strangler Fig Pattern
        • 데코레이터 패턴
        • 커맨드 패턴
        • 전략 패턴
        • 옵저버 패턴
      • A/B 테스팅
      • 대규모 리엑트 웹앱 개발
        • 복잡성 관리
        • 모듈성
        • 성능
        • 디자인 시스템
        • 데이터 패칭
        • 상태 관리
        • 국제화
        • 코드 조직화하기
        • 개인화 A/B 테스팅
        • 확장 가능한 웹 아키텍처
        • 테스팅
        • 툴링
        • 기술적 마이그레이션
        • 타입스크립트
        • 라우팅
        • 사용자 중심 API 디자인
        • 리액트 미래
    • Performance
      • React DevTools
      • Component 최적화
      • Page Load
      • API
    • MFA
      • MSA
      • MFA 도입하기
      • Monorepo
        • Monorepo Tool
        • Yarn Berry Workspace
        • Turborepo
      • MFA Composition
      • SPA 통합
      • Design System
      • Package Manager
        • Yarn
        • pnpm
      • Transpiler & Bundler
        • Babel
        • Rollup
        • esbuild
        • swc
        • Webpack
        • Vite
      • 분해와 통합을 위한 여러 기술 비교
    • State Management
      • Zustand
    • React v18
      • Automatic batching
      • Suspense
      • Transition
    • SEO
      • Search Engine Optimization
      • Open Graph Element
      • Metadata
    • FE Develop
      • User Scenario
      • Optimization
      • Browser API
        • Scrubbing
        • Clipboard
      • Folder Structure
      • API First Design
      • 통합 테스트
      • 테크 스펙
      • 이슈 관리 with Jira
    • Refactoring
      • 리팩토링 깊게 들여다보기
      • 긴 코드 조각내기
      • 타입 코드 처리하기
      • 유사한 코드 융합하기
      • 데이터 보호
      • 코드 추가 및 제거
    • OAuth 2.0
    • Analytics
      • Mixpanel
    • ETC
      • VSCode
    • React Hook In Action
      • useContext & Provider
      • 커스텀 훅
      • 코드 분할하기 with Suspense, lazy
      • Suspense와 이미지 적재하기
      • useTransition, uesDeferredValue
      • SuspenseList
    • AI
      • Cursor
    • UI library
      • vanila-extract
      • Headless
      • 테스트 코드
      • 문서화
Powered by GitBook
On this page
  • 리팩토링이란
  • 리팩터링을 해야하는 이유
  • 규칙
  • 리팩토링 패턴
  1. DEV_NOTE

Refactoring

높은 품질의 코드는 유지 관리 비용을 절감하고, 오류를 줄이며, 개발자의 만족도를 향상시킨다. 높은 품질의 코드를 얻는 가장 일반적인 방법이 바로 "리팩토링"이다.

리팩토링이란

리팩터링은 '기능을 변경하지 않고 코드의 가독성과 유지보수가 쉽도록 코드를 변경하는 것'

  • 리팩터링을 수행하려면 리팩터링 대상을 식별하는 스킬과 리팩터링 단계를 명시적으로 가진 문화, 리팩터링을 돕는 도구의 조합이 필요하다.

리팩터링을 해야하는 이유

  • 코드를 더 빠르게 만들기 위해

  • 더 작은 코드를 만들기 위해

  • 코드를 더 일반적이거나 재사용 가능하게 하기 위해

  • 코드의 가독성을 높이고 유지보수를 용이하게 하기 위해

좋은 코드란 사람이 읽기 쉽고, 유지보수가 용이하며, 의도한 대로 잘 동작하는 코드

더 자세히 풀어보자면

  • 코드를 작성하는 시간보다 코드를 읽고 이해하는데 더 많은 시간을 보내게 된다.

    • 복잡한 분야에서 작업하기에 이해 하지 못하고 변경하게되면 치명적인 장애가 발생할 수 있기 때문

  • 코드베이스의 가독성을 높이면 새로운 기능을 구현하기 위한 시간을 확보할 수 있게된다. (경제적인 이유)

  • 유지보수가 용이해지면 버그 발생이 줄어들고 수정이 쉬워진다.

  • 좋은 코드베이스는 생각하기 편하기 때문

    • 디버깅이 지옥인 이유는 우리가 코드를 읽을 때 코드가 하는 일에 대해 머릿속으로 해석하게되는데 머릿속에서 한 번에 많은 것을 기억해야 할수록 더 지치게 된다.

개발 작업 절차

  1. 탐색(Explore): 무언가 만들어야 할지 확신이 안서거나 또는 문제를 해결할 수 있을지조차 모르는 경우엔 항상 실험부터 시작해야 한다. 무언가를 신속하게 구현하면 고객이 무엇을 필요로하는지 함께 확인할 수 있게된다.

  2. 명세화(Specify): 무엇을 만들지 알게 되면 그것을 명세화한다. 최적의 경우 이것은 자동화된 테스트의 형태가 된다.

  3. 구현(Implement): 코드를 구현

  4. 테스트(Test): 코드가 2단계의 명세(사양)를 따르는지 확인

  5. 리팩터링(Refactor): 코드를 전달하기 전에 다음 사람이 쉽게 작업할 수 있는지 확인(다른 사람이 내가 될 수 있음)

  6. 전달(Deliver): 가장 일반적으로 PR(pull request) 또는 특정 브랜치로 push하는 작업

레거시 시스템에서의 리팩터링

  • 대규모 레거시 시스템에서 리팩터링을 시작할 때 모든 것을 중단한 후 코드베이스 전체를 먼저 리팩터링할 필요없이 일상 업무에 결합할 수 있는 좋은 방법은 "우선 변경하기 쉽게 만든 후 변경하라 - 켄트 백"

  • 새로운 것을 구현할 때마다 새 코드를 쉽게 추가할 수 있게 리팩터링을 먼저 한다.

규칙

일반적으로 코드 스멜은 리팩터링 대상을 설명하는데 쓰인다. 하지만 이것들은 모호해서 주니어들이 내면화하기 어렵기 때문에 코드 스멜을 대체할 구체적인 규칙을 제공한다.

  • 다섯 줄 제한: 메서드는 사용하는 데이터 구조를 탐색하는데 필요한 것보다 더 많은 코드로 구성돼서는 안된다.

  • 호출 또는 전달, 한가지만 할 것: 함수 내에서 객체에 있는 메서드를 호출하거나 객체를 인자로 전달할 수 있지만 둘은 섞어 사용해서는 안된다.

  • if 문은 함수의 시작에만 배치: if 문이 있는 경우 해당 if 문은 함수의 첫 번째 항목이어야 한다.

  • if 문에서 else를 사용하지 말 것: 프로그램에서 이해하지 못하는 타입(형)인지를 검사하지 않는 한 if문에서 else를 사용하지 않기

  • switch를 사용하지 말 것: default 케이스가 없고 모든 case에 반환 값이 있는 경우가 아니라면 switch를 사용하지 않기

  • 인터페이스에서만 상속받을 것: 상속은 클래스나 추상 클래스가 아닌 오직 인터페이스를 통해서만 받는다.

  • 순수 조건 사용: 조건문의 조건식에서는 변수에 값을 할당하거나 예외를 발생시키거나 I/O와 상호작용해서는 안된다.

  • 구현체가 하나뿐인 인터페이스를 만들 지 말 것: 구현체가 하나뿐인 인터페이스를 사용하지 말기

  • getter와 setter를 사용하지 말 것: 부울이 아닌 필드에 setter나 getter를 사용하지 않기

  • 공통 접사를 사용하지 않기: 코드에는 공통 접두사나 접미사가 있는 메서드나 변수가 없어야 한다.

리팩토링 패턴

  • 메서드 추출: 한 메서드의 일부를 가져와 고유한 메서드로 추출

  • 클래스로 타입 코드 대체: 열거형을 인터페이스로 변환하고 열거형의 값을 클래스로 만든다.

  • 클래스로의 코드 이관: 기능을 클래스로 옮기기 때문에 클래스로 타입 코드 대체는 클래스로의 코드 이관으로 자연스럽게 이어진다.

  • 메서드 인라인화: 프로그램의 가독성에 더 이상 도움을 주지 않는 메서드를 제거

  • 메서드 전문화: 메서드에 불필요하고 문제가 있는 일반성을 제거

  • 삭제 후 컴파일하기: 인터페이스와 클래스의 전체 사용 범위를 알고 있는 경우 사용하지 않는 메서드를 인터페이스와 클래스에서 제거

  • 유사 클래스 통합: 일련의 상수 메서드에서 서로 다른 두 개 이상의 클래스를 통합

  • if 문 결합: 동일한 본문을 가진 if문이 이어진 경우 if 문의 분기들을 결합해서 중복을 줄임

  • 전략 패턴의 도입: if문을 사용한 분기를 클래스를 인스턴스화하는 것으로 대체

  • 구현에서 인터페이스 추출: 클래스에 대한 종속성을 인터페이스로 바꿈

  • getter와 setter 제거하기: 기능을 데이터에 더 가깝게 옮겨 getter와 setter를 제거

  • 데이터 캡슐화: 변수와 관련된 불변속성을 지역화하고 응집력을 더 명확히 한다.

  • 순서 강제화: 특정 순서대로 작업을 수행하는 것을 컴파일러가 보장하게 한다.

Previous이슈 관리 with JiraNext리팩토링 깊게 들여다보기

Last updated 1 year ago