728x90

리팩토링을 어떨 때 시작하고 어떨 때 그만둬야 할지 판단을 해야하는데, 그것은 사실 상 경험을 많이 해봐야 하는 부분일 것이다.



그냥 가볍게 보통 이럴 때 리팩토링을 어떻게 하고, 이럴 때에는 이렇게 하는게 좋구나... 이 정도만 생각하도록 하자.




1. 중복 코드

리팩토링을 꼭 해야 하는 상황은 중복 코드가 여러 곳에 있을 때이다. 이런 중복 코드는 하나로 통일을 해서 프로그램을 개선해야 한다. 


2. 장황한 메서드

최적의 상태로 장수하는 객체 프로그램을 보면 공통적으로 메서드의 길이가 짧다. 메서드의 길이가 길수록 이해하기 어렵다는 점은 많은 프로그래머들은 알고 있다. 이를 위해서 메서드를 과감하게 쪼개야 한다. 

메서드명은 기능 수행 방식이 아니라 목적(기능 자체)을 나타내는 이름으로 정해야 한다.


3. 방대한 클래스

기능이 지나치게 많은 클래스에는 보통 엄청난 수의 인스턴스 변수가 들어있다. 클래스에 인스턴스 변수가 많으면 중복 코드가 존재하기 마련이다. 클래스들을 추출하면 수많은 인스턴스 변수를 하나로 묶을 수 있다. 서로 연관된 변수를 골라서 클래스로 빼내면 된다. 


4. 과다한 매개변수

매개변수가 간결하다는 것은 장점이다. 매개변수가 길면 서로 일관성이 없어지거나 사용이 불편해지고, 더 많은 데이터가 필요해질 때마다 계속 수정해야 하기 때문에 그 매개변수들을 이해하기 힘들다. 웬만하면 객체를 넘기면 많은 문제가 해결 된다.


5. switch 문

객체지향 코드의 확연한 특징 중 하나는 switch ~ case 문이 비교적 적게 사용된다는 점이다. 

switch 문의 단점은 반드시 중복이 생긴다는 점이다. 같은 switch 문이 프로그램 곳곳에 있을 때가 많다. 그렇기 때문에 switch 문에 새 코드를 추가하려면 여기저기에 존재하는 switch 문을 전부 찾아서 수정해야 한다. 

이 문제를 해결하려면 객체지향 개념 중 하나인 다형성, 즉 재정의를 이용하는 것이다. 대부분의 switch 문은 고민할 필요없이 재정의로 바꿔야 한다. 


6. 인터페이스가 다른 대용 클래스

기능은 같은데 시그너처가 다른 메서드에는 메서드명 변경을 해야 한다. 클래스에 여전히 충분한 기능이 구현되어 있지 않기 때문에 대체로 이 방법만으로는 충분하지 않다. 프로토콜이 같아질 때까지 메서드 이동을 해서 기능을 해당 클래스로 옮겨야 한다. 단 코드를 너무 여러번 옮겨야 한다면 상위클래스 추출을 하면 된다.


7. 불필요한 주석

주석은 많이 사용할 수록 좋다. 하지만, 여기서부턴 이 기능, 여기서부턴 저 기능이라는 주석이 있다면 그것은 다른 메서드로 빼는 것이 좋다. 그 주석들은 불필요하다.


8. 변수명 수정

굳이 변수명을 수정하는 것이 왜 리팩토링이냐고 생각을 할 수도 있다. 하지만, 좋은 코드는 그것이 무슨 기능을 하는지 분명히 들어나야하는데, 코드의 기능을 분명히 드러내는 열쇠가 바로 직관적인 변수명이다.



9. 임시 변수 없애기

임시 변수로 인해 문제가 생길 수 있다. 임시 변수는 자체 루틴 안에서만 효력이 있다 보니, 점점 더 많은 임시변수를 사용하게 되어 코드가 복잡해지기 쉽다. 그렇기 때문에 임시 변수는 질의 메서드(Query Method)로 변경해주는 것이 좋다.



10. switch ~ case 문의 조건문 확인

만약 다른 객체의 속성을 switch 문의 인자로 사용하고 있다면 나쁜 방법이다. switch 문의 인자로는 타 객체 데이터를 사용하지 말고 자신의 데이터를 사용해야 한다.




728x90

'Basic Programming > Refactoring' 카테고리의 다른 글

Refactoring - 리팩토링 관련 문제들  (0) 2017.09.14
Refactoring - 리팩토링 이란 ?  (0) 2017.09.14
728x90

리팩토링을 진행하는 것도 좋지만, 리팩토링으로 인해 발생할 수 있는 문제점들 혹은 리팩토링이 어려운 상황에 대해 알아두는 것도 중요하다.




리팩토링으로 인해 발생할 수 있는 문제점들...



- 데이터 베이스

리팩토링에서 문제가 되는 부분 중 하나가 바로 데이터 베이스이다. 많은 비즈니스 어플리케이션은 바탕이 되는 데이터 베이스 스키마와 강력히 결합되어 있다. 이 때문에 데이터 베이스 수정이 어려워진다.


아무리 데이터 베이스 스키마와 객체 모델의 상호 의존성을 최소화하려고 시스템을 꼼꼼하게 계층 구조로 제작했더라도, 데이터 베이스 스키마를 수정하면 데이터도 이전해야 하는데, 이것은 시간도 오래 거릴 뿐 아니라 위험성도 높다.


이 문제를 해결하기 위해서 객체 모델과 데이터 베이스 모델 사이에 별도의 소프트웨어 계층을 두는 방법이 있다.

이렇게 하면 두 모델에 생긴 변경 사항을 따로 유지할 수 있어서 한 모델을 수정할 때 다른 모델은 수정할 필요 없이 그저 중개 계층만 수정하면 된다. 



- 인터페이스 변경

객체의 중대한 장점 중 하나는 인터페이스를 건드리지 않고 내부의 구현 코드를 수정할 수 있다는 점이다.

객체를 이용하는 부분을 수정하지 않고도 객체의 내부 구조를 안전하게 수정할 수 있지만, 인터페이스를 수정하면 어떤 문제가 발생할지 알 수 없으므로 인터페이스를 건드리지 않는다는 것은 큰 장점이다.


리팩토링에서 불안한 점은 상당수의 리팩토링이 인터페이스를 수정한다는 것이다.

함수명 변경도 그 자체가 인터페이스를 수정하는 작업이다.


특히, 이미 배포를 한 프로그램이고 내부 함수명을 수정했다면 그 인터페이스를 사용하는 측에서도 수정을 해야하므로 더 복잡하게 수정해야만 할 수도 있다.


위 문제를 해결하기 위해선 기존 인터페이스가 새 인터페이스를 호출하게 수정하면 간단하게 해결이 된다.





리팩토링을 하면 안되는 상황.



- 코드를 처음부터 새로 작성해야 할 때

코드가 돌아가지 않는다면 그건 완전히 새로 작성을 하라는 신호이다. 테스트만 하려다 코드가 버그 투성이라 안정화할 수 없음을 알게 될 경우가 바로 그 때이다. 


코드가 제대로 돌아가는 것이 가장 중요하다. 리팩토링은 그 이후의 일임을 반드시 명심하자.



- 납품일이 임박했을 때

납품일이 가까운 시점에 리팩토링을 해봤자 그로 인한 생산성은 납기가 지난 후에나 가시화될 테니 쓸데 없다.


하지만, 납품일이 임박한 경우가 아니면 시간이 없다는 핑계로 리팩토링을 미루면 안 된다.




728x90

'Basic Programming > Refactoring' 카테고리의 다른 글

Refactoring - 리팩토링을 해야 할 때  (0) 2017.09.14
Refactoring - 리팩토링 이란 ?  (0) 2017.09.14
728x90

리팩토링은 조금씩 조금씩 단계적으로 수정을 하고, 수정을 했으면 항상 신뢰도 높은 각종 테스트를 해야 한다.

그리고 각종 테스트는 반드시 자체 테스트가 되게 만들어서 테스트를 해서 시간을 단축하는게 좋다.




리팩토링이란?

1) (명사) 겉으로 드러나는 기능은 그대로 둔 채, 알아보기 쉽고 수정하기 간편하게 소프트웨어 내부를 수정하는 작업.

2) (동사) 리팩토링 기법을 연달아 적용해서 겉으로 드러나는 기능은 그대로 둔 채 소프트웨어 구조를 변경.



리팩토링과 최적화는 다른 작업이다.

리팩토링은 소프트웨어의 유지보수를 조금 더 쉽게할 수 있게 하고, 코드 가독성을 올리며 기능 추가를 더 쉽게 할 수 있게 하여 오히려 성능이 더 떨어질 수도 있다.

하지만 최적화 작업은 성능은 올라가더라도 코드의 가독성이 더 떨어질 때가 많다.



리팩토링에 대한 명언

리팩토링을 적용할 때에는 버그도 그대로 있어야 한다.



리팩토링을 하는 이유

1) 소프트웨어의 설계 개선. (중복 코드 제거)

2) 소프트웨어를 이해하기가 더 쉬워진다. (유지보수)

3) 버그를 찾기 쉬워진다.

4) 프로그래밍 속도가 빨라진다.



리팩토링을 하는 시기

한달에 하루 이런식으로 날잡고 하는게 아니라 개발과정에서 틈틈이 작업을 해야한다.


1) 같은 작업의 3진 아웃 때 

어떤 작업을 처음 할땐 그냥하고, 두 번째 작업할 땐 조금 찝찝하더라도 그냥 하고, 세 번째 하게 되면 그때 리펙토링을 실시하는 것이다.


2) 기능을 추가할 때

(1) 코드를 이해하기 쉽게 만들기 위해서 기능을 추가할 때 리팩토링을 해야한다.

(2) 설계가 지저분해서 어떤 기능을 추가하기 힘들 때에는 망설이지 말고 리팩토링을 진행해야 한다.


3) 버그를 수정할 때

코드의 기능을 파악하려다 이해하기 힘들다면 이해하기 쉽게 만들기 위해 리팩토링을 진행해야 한다.

리팩토링을 하고 나면 버그를 찾기 쉬워질 것이다.

버그 리포트가 입수되었을 때에도 리팩토링을 진행해야 한다. 왜냐하면 버그 리포트를 받을 때까지 버그가 있는 줄도 모를 정도면 그 코드가 엄청 지저분하다는 반증이기 때문이다.


4) 코드를 검수할 때

자신의 코드는 자기가 볼 땐 쉬울지 몰라도 다른 팀원이 볼 때에는 알아보기 힘들 수도 있다. 

리팩토링을 진행하면 다른 사람이 개발한 코드를 검수하기도 쉬워진다. 







728x90

+ Recent posts