[개념] 리팩토링이란?

코딩을 하다 보면 처음 기획과 달라지는 경우가 발생합니다. 기획의 변경, 성능문제 등 여러 요인이 있는데 이 중에서 추가 개발을 하거나 어느정도 텀을 둔 뒤 개발을 하게 되거나 남의 코드를 이어받아 개발을 할 때 보통 문제가 발생합니다.

 

이 문제를 해결하기 위해 리팩토링이 필요합니다.

 

리팩토링을 하는 이유로는 

 

1. 나 또는 다른사람이 이해하기 쉽고 수정이 편리하도록 (과도한 코드를 제거)

2. 새로운 기능개발을 쉽게 하기 위해

3. 내가 작성한 코드를 쉽게 기억하기 위해

등이 있습니다.

 

bad smell이란 버그는 아니지만 문제를 유발할 수 있거나 코드의 복잡성이 높거나 이해력에 문제를 야기하는 것들입니다.

 

종류로는 

 

중복코드 - 비슷한 동작을 하는 코드인데 일일히 구현되어있음(따로 함수나 메서드로 빼야함)

길이가 긴 메서드(5~10줄이 적당) - 하는 역할 분리 추상화레벨 ++

복잡한 조건문 - 이해하기 어렵고 나중에 확장하기 어려워짐.

원시적 집착 - 기본 자료형으로 너무 많은것을 표현하고자 하는 경우.ex)_ 문자열로 이름, 주소, 주민번호, 전화번호등 여러 자료를 저장하려 할 때

과도한 노출 - 정보 은닉이 필요한 정보를 노출하는 경우

무질서한 솔루션 - 하나의 문제를 해결하기 위해 다양한 클래스를 동원하는 경우, 이 경우 하나의 클래스로 병합

대체 클래스가 다른 인터페이스 사용 - 클래스가 다르면 인터페이스도 달라야함. 하지만 동일한 임무를 수행하는 클래스는 인터페이스가 같아야 함

게으른 클래스 - 하는 일이 없어서 다른 클래스로 통합되어야 하는 클래스

거대한 클래스 - 게으른 클래스를 많이 합치다보면 너무 많은 임무를 갖게 되어 분할해야 하는 클래스

복잡한 SW Control - switch문, if then else문 등 제어문이 복잡한경우 제거

너무 많은 기능 종합 - 특정 작업을 위해 너무 많은 메서드를 사용하는 경우 기능별 분할

하나의 문제, 다양한 해결 방법 - 동일한 문제를 해결하는 기능은 하나여야 함

 

등이 있습니다.

 

저 같은 경우 지역 추천 서비스를 추천서비스와 추천하기위해 계산에 필요한 데이터를 가져오는 서비스로 분리해서 구현했었는데 여러 추천 요소들을 추가하면서 추가의 어려움과 기존코드의 이해의 문제와 클래스의 책임이 너무 커짐을 느꼈습니다.

 

그래서 각 추천 계산하는 추상 클래스로 만들고 각 구현체에서 해당 기능들을 계산하도록 하고 그 계산을 위해 필요한 데이터도 데이터를 가져오는 추상 클래스로 분리해서 클래스의 책임들을 쪼개는 계획을 세웠습니다.

 

이 방법을 사용할 경우 추후 새로운 기능을 추가하더라도 기존 기능에 영향을 주지 않기 때문에 유연성이 증가하고 각 기능들의 수정이 용이해서 재사용성이 증가합니다. 또한 각 기능들을 독립적으로 테스트 할 수 있게 됩니다.

 

다만 데이터의 흐름이 많아지기 때문에 성능에 대한 측면을 고려할 수 있어야 하고, 클래스의 수가 많아지므로 관리하기 어려워 질 수 있습니다.