[Refactor] 리팩터링에 순서가 존재할까?

완성된 프로젝트나 작성된 코드를
객체지향 프로그래밍을 적용해서 리팩터링 하려 한다.

 

리팩터링을 진행하려고 할 때, 어디서부터 시작하여 마무리해야 할까?
특별한 순서나 규칙, 절차는 존재하지 않는 것 같다.

 

하지만 리팩터링도 단계별로 적용하는 것이,
유지보수가 쉬운 형태로 만들어 나갈 수 있다고 생각한다.

 

단계별 프로그래밍, 작은 단위부터 기능을 구현한 경험을 바탕으로
리팩터링을 하기 전 점진적 단계를 구성해 보자.

 

단계별 프로그래밍 경험 + 리팩터링 단계 설정

1. 코드 이해

먼저 코드베이스를 깊게 이해하고 어떤 부분이 수정되어야 하는지 파악해야 한다.
요구사항을 정확히 준수한다.

• README를 재검토한다.
  • 정상적인 경우, 예외적인 상황 정리

2. 테스트 추가

코드베이스에 예외 테스트가 부족하다면, 리팩터링 하기 전에 적절한 테스트를 추가한다.

• 이는 코드가 변경되어도 기존 기능이 올바르게 작동하는지 확인하는 데 도움이 된다.

발생할 수 있는 예외 상황에 대해 고민한다.

3. 불변성 적용

작은 단위부터 불변성을 적용하고 싶은 클래스나 메서드를 식별하고, "final" 키워드를 사용하여 필요한 부분을 수정한다 (record 활용)

• 인스턴스 변수의 접근 제어자는 private으로 구현

필드를 불변으로 만들어서 변경을 방지하거나, 필요한 경우 변경을 최소화하여 불변성을 유지한다.

4. 중복 코드 제거

중복 코드를 찾아서 메서드나 클래스로 추출하여 중복을 제거하자.

• 중복 코드는 유지보수를 어렵게 만들 수 있다.

5. 네이밍 개선

코드의 가독성을 높이기 위해 변수, 메서드, 클래스 등의 이름을 명확하고 의미 있게 변경한다.

• 이름을 통해 의도를 드러내자.

6. 클래스 및 메서드 분리

단일 책임 원칙에 따라 클래스와 메서드를 분리하고 각각의 역할을 명확하게 정의한다.
일급 컬렉션으로 표현할 수 있는지 검증한다.
필드(인스턴스 변수)의 수를 줄일 수 있는지 검증한다.

7. 의미 있는 주석 추가

코드의 의도를 설명하는 주석을 추가하거나, 불필요한 주석을 제거하자.

8. 함수 및 메서드 크기 줄이기

함수와 메서드가 너무 크다면, 이를 더 작은 단위로 나누어 가독성을 향상한다.

• private 함수를 테스트하고 싶다면 클래스(객체) 분리를 고려해야 한다.
• 람다식을 이용한다면 depth를 줄이고 직관성을 높일 수 있는지 파악한다.

메서드의 depth 라인을 15라인을 넘어가지 않는지 검증한다.

• 함수(또는 메서드)가 한 가지 일만 하는지 파악하자.

9. 불필요한 코드 제거

사용되지 않는 변수, 메서드, 클래스 등을 식별하고 제거한다.

10. 성능 개선 및 최적화

성능 개선을 위해 비효율적인 알고리즘을 최적화한다.
다만, 반드시 성능 테스트를 통해 변경이 필요한지 확인해야 한다.

11. 코드 스타일 통일

일관된 코드 스타일을 유지하고, 프로젝트 내에서 사용되는 코드 스타일 규칙을 준수하자. (IDE 우테코 스타일 적용)

• 공백 라인을 의미 있게 사용한다. (공백도 코딩 컨벤션이다.)
• 한 메서드에 오직 한 단계의 들여 쓰기만 한다.
• 한 줄에 점을 하나만 찍는다.
• 구현 순서도 코딩 컨벤션이다.

 

정리

리팩터링은 작은 단위부터 시작하여 점진적으로 진행하는 것이 좋다고 한다.
이러한 단계를 차례대로 진행하면서 코드를 더 깔끔하고 유지보수가 쉬운 형태로 만들 수 있을 것 같다.
리팩터링을 적용해 보고 추가사항이나 수정할 부분을 확인해 보자.