Code Refactoring (코드 리팩토링)

1) 외부에서 본 프로그램의 동작은 변하지 않고, 

2) 프로그램 내부의 구조를 개선하는 것

따라서 debugging 이나 기능 추가와 같은 것은 리팩토링이라고 할 수 없다. 프로그램의 동작이 변하기 때문이다. 

그렇다면 Refactoring 의 목적은 무엇일까? 말했듯이, 디버깅 자체가 Refactoring 은 아니다. 하지만 리팩토링을 통해서 디버깅이 쉬워질 가능성이 있다. 복잡하고 어지러운 코드에서는 버그를 찾기 쉽지 않기 때문이다. 

기능 추가와 관련하여 다음 그림을 참고한다면 리팩토링의 장점을 알 수 있다. 

출처: http://www.hanbit.co.kr/preview/1511/sample_chapter0.pdf

당장은, 자기 생각대로 빨리 아무렇게나 코딩하는 것이 빠르다고 생각할지 모르겠지만, 처음부터 리팩토링을 생각하며 
코딩하는 것이 결국 전체적인 속도로 보았을 때에, 비교할 수 없을 정도의 차이를 낼 것으로 보인다. 리팩토링 없이 어지럽게 코딩을 마친 후 버그를 잡다가, 결국 전체적인 프로그래밍 설계를 모두 수정해야하는 사태까지 나올 수 있지 않을까 생각한다. 그런데 리팩토링을 하며, 보기 쉽고, 깔끔하게 정리하며 코딩을 하다 보면, 중간에 전체적인 설계가 잘못되어서 코드를 뒤집어야 한다고 하는 최악의 사태가 온다 하더라도, 빨리 판단하고 실행에 옮기게 되어 결국 전체적인 프로젝트 기간을 단축 시킬 수 있을 것 같다. 

다음은 언제 리팩토링을 해야하는가에 대한 펌 자료이니 참고하자. 
출처: http://outliers.tistory.com/entry/%EB%A6%AC%ED%8C%A9%ED%86%A0%EB%A7%81Refactoring

언제 리팩토링을 해야 하는가?

• 별도의 시간을 내는것이 아니라, 틈틈히 계속 해야 하는 것이다.
• 어떤 것을 할 때 비슷한 어떤것을 하게 되면 리팩토링을 한다.(책에서는 3번째 부터 하라고 나와있지만 바로 한다.)
• 기능을 추가할 때 리팩토링을 해라.
• 버그를 수정해야 할 때 리팩토링을 하라.
• 코드 검토(code review)를 할 때 리팩토링을 하라.
• 읽기 어려운 프로그램은 수정하기 어렵다.
• 중복된 로직을 가지고 있는 프로그램 수정하기 어렵다.
• 실행중인 코드를 변경해야 하는 특별한 동작을 요구하는 프로그램은 수정하기 어렵다.
• 복잡한 조건문이 포함된 프로그램은 수정하기 어렵다.

그러나 리팩토링을 지양해야할 때도 있다. 

언제 리팩토링을 하지 말아야 하는가?

• 코드를 처음부터 다시 작성해야 할때
• 마감일에 가까울 때
  

그렇다면 리팩토링과 디자인패턴 (design pattern) 과는 어떤 관계가 있을까? 

디자인패턴은 목표이고 리팩토링은 방법이라고들 말을 한다. 

다음은 디자인 패턴이 무엇인지 잘 정리되어있는 펌자료이다. 
출처: http://alleysark.tistory.com/entry/Design-pattern-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80

- 디자인 패턴이란?

클래스 구조를 갖는 프로그래밍을 하다보면 클래스간에 구조가 짜여지고 다양한 방법으로 객체가 생성되며 관계에 따라 여러가지 형태의 행동들이 나타난다. 그런데 기초 설계가 제대로 되어있지 않은 상태로 프로그래밍이 시작된다면 얼마 못가 클래스 관계가 꼬일대로 꼬여 누더기 진흙탕 코드덩어리로 변하게된다. 엄청나게 뛰어난 사람이어서 초기 요구에 맞춰 잘 짜여진 클래스관계를 만든다 해도 요구 사항이 바뀌게되면 쉽게 대응하지 못한다. 이미 갈 때 까지 간 코드를 뒤엎는건 그만큼 큰 비용을 감수해야하는 행동이다.

 

그런데 Object oriented programming은 이게 아니지 않은가? 분명 클래스 구조의 프로그래밍을 했는데도 프로젝트가 진행되다보면 데이터의 은닉과 캡슐화, 코드의 재사용성과 확장성 등은 누더기 코드에 가려 보이지 않는다. 제대로된 OOP를 하지 못했다는 이야기이다. 그렇다면 제대로된 OOP란 무엇을 말하는것인지 의문이 생긴다. 많은 사람들이 이에대해 고민했고 프로그램의 목적이 어떻든간에 프로그램안에 클래스들이 갖는 구조에는 일정한 '형태' 혹은 '패턴' 이 존재한다는 것을 인지하기 시작했다. 이를 바탕으로 클래스간의 관계, 클래스간의 행동양식을 분류하고 각각에 대해 객체지향적인 설계를 따르는 노하우들이 차곡차곡 정리되어 객체지향적으로 합당한 클래스 설계 형태를 정립하기 시작했고 이를 클래스 디자인 패턴 이라 이름붙이게 되었다.

 

클래스 디자인 패턴은 "'이러한 상황' 이라면 '이러한 형태의 클래스 디자인'을 하는게 대게 좋더라" 라고 말해주는것이다. 프로젝트 규모가 커지고 협업 인원이 많아질수록 이러한 기준은 일을 효율적으로 처리할 수 있게 만들어준다. 하지만 주의해야한다. 표준화된 작업은 여러가지 상황을 고려하며 만들어지기 때문에 대체로 효율성이 떨어지기 마련이다. 또한 패턴간의 관계를 생각하지 못하면 설계를 복잡하게 만드는 요소가 되어버린다. 그렇기 때문에 클래스 설계자는 분류된 디자인 패턴의 사용 목적, 장단점, 강점과 약점에 대한 충분한 이해와 패턴간의 융합에 발생할 수 있는 문제점들을 확실히 예상할 수 있어야 하며 이를 바탕으로 디자인 패턴을 적용해야한다. 무분별한 패턴의 남용은 오히려 프로그램을 망치게된다.

디자인 패턴이 리팩토링을 위한 방법이라고 말했듯이, 디자인 패턴들이 분명 유용하긴 하나, 디자인패턴이 너무 강조될 경우, 오히려 더 코드가 지저분해질 염려도 된다고 퍼온 자료의 저자는 말한다. 결국, 목적이 더 좋은 설계가 되어야지, 디자인 패턴 자체가 되어서는 안된다는 뜻으로 받아드리려고 한다. 

다음과 같은 펌자료 저자의 의견도 함께 첨부한다. 

만약 무분별 하게 디자인 패턴이 사용되고 패턴들이(클래스들이) 유기적으로 결합되지 못한다면 클래스 설계에 있어서 디자인 패턴은 필요악 되어버린다. 설계자는 패턴에 목메기보다는 설계원칙을 잘 생각하면서 이를 받쳐줄 검증된 방법론으로서 디자인 패턴을 고려하여야 할 것이다.

 

또 한가지는 프로그램의 구동 환경에 있다. PC 어플리케이션이라면 디자인패턴이 가져오는 퍼포먼스에 대한 결점은 큰 문제가 되지 않을 것이다. 하지만 안드로이드 같은 모바일 환경이나 임베디드 환경이라면 디자인패턴은 사치품에 지나지 않는다.

 

마지막으로 프로그램의 구동 목적이 고려되어야 한다. 구동에 큰 설계가 필요하지 않거나 명확한 클래스구조를 갖고 코드의 변경을 고려하지 않아도 된다면 디자인패턴은 쓸데없는 비용을 늘리는 요소가 된다. 그리고 게임프로그램, 서버프로그램과 같은 고성능의 실행환경을 요구하는 프로그램이라면 퍼포먼스를 낮추는 디자인패턴은 필요성에 대해 신중에 신중을 기할 필요가 있다.

[전체 출처 : http://egloos.zum.com/johnny1984/v/9072065 ]