Refactoring이란?

No Image

리팩토링이란 무엇인가?

  • 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법입니다.
  • 코드가 작성된 후에 디자인을 개선하는 작업입니다.
  • 모든 것을 미리 생각하기보다는 개발을 하면서 지속적으로 좋은 디자인을 찾는다.
  • 메소드 내의 지역변수와 parameter를 주의 깊게 볼 필요가 있다.
  • 값이 수정되지 않는 변수는 파라미터로 넘길 수 있다.
  • 값이 수정되는 변수는 주의가 필요하다. 변화되는 부분을 함수로 추출하여 리턴 값으로 돌려줄 수 있다.

리팩토링은 작은 단계로 나누어 프로그램을 변경한다.

  • Naming 중요성. 컴퓨터가 이해하는 코드는 누구나 작성할 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 작성한다.
  • 클래스의 메소드는 클래스의 변수를 사용해야 한다. 클래스의 정보를 사용하고 있지 않는다면 사용하고 있는 변수쪽으로 메소드는 움직여야 한다.
  • 임시변수는 가능하면 제거하는 것이 좋다. 임시변수는 종종 쓸데없이 많은 파라미터를 만드므로 문제가 된다.
  • 임시변수를 하나의 메소드로 구현하여 리팩토링 하자.
  • 리팩토링하는 과정에서 알고리즘적으로 성능이 더 안 좋아 질 수 있다. 하지만 어느 알고리즘 부분이 수정되어야 하는지 명확하게 보이게 되어 최적화하기 더 쉬운 형태로 변경되는 장점이 있다.
  • 다른 객체의 속성을 기반으로 한 switch문은 좋지않다. 그 부분을 함수로 추출하여 자신의 데이터를 사용하는 것으로 리팩토링해야한다.
  • 메소드에서 두개의 클래스 변수를 사용하고 있다면 변화하기 쉬운쪽으로 메소드를 이동시켜 변화의 폭을 최대한 작게 하자.
  • 기능이 한쪽으로 모여진 클래스를 추상화하여 상속관계로 표현할 수 있다.
  • [state 패턴 / strategy패턴] 상태를 나타내는가? 알고리즘을 나타내는가에 따라 이름이 바뀔 수 있다.
  • 테스트 -> 리팩토링 -> 테스트 -> 리팩토링 -> 테스트.. 점진적인 개선

리팩토링의 원리.

  • 리팩토링 하다(Refactoring) - 일련의 리팩토링을 적용하여 겉으로 보이는 동작의 변화 없이 소프트웨어 구조를 바꾸다.

    소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것

목적

  • 리팩토링의 목적은 소프트웨어를 보다 이해하기 쉽고, 수정하기 쉽도록 만드는 것이다.
  • 리팩토링은 겉으로 보이는 소프트웨어의 기능을 변경하지 않는다는 것이다.

두 개의 모자

  • 두가지 구별된 작업(기능 추가와 리팩토링)을 위해 시간을 나눠야 한다
  • 기능을 추가할 때는 기존 코드를 건드려서는 안되고 단지 새로운 기능만 추가해야 한다
  • 리팩토링을 할 때는 기능을 추가해서는 안되고 단지 코드의 구조변경에만 신경써야 한다.

왜 리팩토링을 해야 하는가?

  • 코드의 구조가 망가지는 효과는 누적된다.
  • 코드의 디자인을 유지하도록 도와준다.
  • 중복을 제거함으로써 각각의 작업에 대한 코드가 오직 한 곳에만 있게 할 수 있다.
  • 소프트웨어의 디자인을 개선시킨다.
  • 소프트웨어를 더 이해하기 쉽게 만든다.
  • 버그를 찾도록 도와준다.
  • 프로그램을 빨리 작성하도록 도와준다.

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

  • 삼진 규칙(3번의 중복 / 3번의 같은 행위를 한다면 리팩토링을 진행하자.)
  • 기능을 추가할 때 리팩토링을 하자.
  • 버그를 수정해야 할 때 리팩토링을 하라.
  • 코드 검토(Code Review)를 할 때 리팩토링을 하라.

리팩토링을 할 때의 문제

  • 의도했던 것보다 짧고, 불확실하다.

데이터베이스

배경

  • 비즈니스 어플리케이션은 데이터베이스 스키마와 밀접하게 결합되어 있다.
  • 데이터베이스의 변경을 어렵게 하는 이유중의 하나.

어떻게 해결하려고 노력했을까..?

  • 객체 모델과 데이터 베이스 모델 사이에 Layer를 추가하여 결합도를 낮춘다.

Benifit

  • 객체 모델과 데이터 베이스 모델 각각의 독립성을 보장한다.

Disadvantage

  • 복잡도가 높아질 수 밖에 없다.

인터페이스 변경

  • 기존의 Method를 변경하는 건 호출하는 부분을 찾아서 일일이 바꾸면 가능하다.
  • 하지만 interface는 변경되야 하는 부분이 매우 크다.
  • 기존의 interface를 유지하면서 새로운 interface를 유지할 수 있다.
  • @deprecated를 사용하면 사용자에게 쉽게 알려줄 수 있다.
  • 이런 문제를 해결하기 위해서는 인터페이스를 공표하지 않는 것이다.
  • 완벽하게 안정화된 인터페이스만 공표를 진행하고. 나머지는 공표를 하지 않는 것을 추천한다.

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

  • 현재의 코드가 작동하지 않는다면 확실히 재작성이 필요한 경우이다.
  • 리팩토링을 하기 전에 코드가 제대로 작동해야 한다는 것을 기억하기 바란다.
  • 또한 마감일에 가까운 경우에는 리팩토링을 피해야 한다.
  • 어떤 작업을 하는데 계속 시간이 부족한 듯 느껴진다면, 보통 리팩토링이 필요하다는 신호이다.

리팩토링과 디자인

  • 리팩토링은 디자인을 보완하는 특별한 역할을 한다.
  • 프로그래밍을 하기 전에 미리 디자인에 대해 생각해보는 것이 비용이 많이 드는 재작업을 피하도록하는데 도움이 된다는 것을 알게 되었다.

시스템이 어떻게 돌아가는지 정확하게 알고 있다 하더라도, 추측만 하지 말고 실제로 퍼포먼스를 측정해보라. 무엇인가 배울 것이고, 십중팔구는 추측이 틀렸을 것이다.

리팩토링과 퍼포먼스

  • 퍼포먼스는 중요한 부분이다.
  • 하지만 후반부에서 진행해야 할 부분이고 자주 사용하는 함수들 위주로 성능 최적화를 진행해야 한다.
  • 그러기 위해서는 프로파일러를 통해 어느 부분이 Hot-spot인지 알아내기도 한다.
  • 리팩토링을하는 동안 단기적으로는 소프트웨어를 느리게 하지만, 최적화 단계에서는 소프트웨어를 튜닝하는 것을 더 쉽게 한다. 결국 이익이 된다.
0%