리팩토링 (3)
언제 리팩토링을 해야하는 것인가.
저자는 틈틈히 하라고 말한다. (몇일마다 한다 몇주마다한다 이러지 말고 그냥 하면서 틈틈히다.)
책에서는 Don Roberts란 사람이 저자에게 알려준 삼진 규칙이 있다고 소개한다.
(뭐 그냥 규칙이라고 이름 지엇지만 내용은 단순한거 같다.)
처음 시작할때는 그냥 한다. 두번째로 비슷한 어떤 것을 하게 되면, 중복 때문에 주춤하지만 그냥 중복되도록 한다. 세번째로 비슷한 것을 하게 되면, 그때 리팩토링을 한다.
라는 내용이다. 음.. 뭐랄까.. 중복된 내용을 하게되면 그 부분을 때내서 재사용 할 수있도록 분리하기가 용이해서 인가?? 그건 잘 모르겠다. 세개를 넘어가면 아무래도 개발자 입장에서는 이걸 모듈 단위로 쪼개서 구현하고 싶어질 것도 같지만.. 나는 아직 여기까지만 생각한다.
리팩토링하는 시점은
-
기능을 추가할 때 리팩토링을 하라.
-
버그를 수정해야 할 때 리팩토링을 하라.
-
코드 검토 (code review)를 할 때 리팩토링을 하라.
인디렉션과 리팩토링
* 컴퓨터 과학은 인디렉션 계층을 한 단계 더 만들면 모든 문제를 풀 수 있다고 믿는 학문이다. *
- Dennis DeBruler
Indirection 책에선 간접적인 방법에 의한 참조를 indirection이라고 표현하고 있다.
책에서는 인디렉션은 양날의 칼과 같다고 한다.
하나를 둘로 나누게되면 그만큼 관리해야 하는 것이 많아지고, 한 객체가 다른 객체에 위임하고 그 객체는 다른 객체에 위임하고 이런식으로 된다면 프로그램을 이해하기 어렵게 할 수 있다.
- 로직의 공유.
ex) 다른 두 곳에서 호출되는 서브메소드나, 모든 서브클래스에서 공유되는 수퍼클래스의 메소드가 있다.
- 의도와 구현을 분리하여 설명.
ex) 클래스의 이름과 메소드의 이름을 정하는 시점이 코드의 의도를 설명할 기회이다. 클래스와 메소드의 내부는 그 의도를 어떻게 구현했는지를 설명한다. 만약 내부 역시 의도의 관점에서 작성되었다면, 그 구조에 대한 중요한 정보의 대부분을 잘 전달하도록 코드를 작성할 수 있다.
- 변경의 격리
ex) 하나의 객체가 다른 두 곳에서 사용된다. 나는 두 경우중 하나의 동작을 바꾸고 싶다. 내가 그 객체를 직접 수정하게 되면 두 경우 모두 바뀔 위험이 있다. 따라서 나는 먼저 서브클래스를 만들고, 바꾸려고 하는 곳에서 이 객체를 참조하게 한다. 이제 나는 다른 곳에 의도하지 않은 변화가 생길 위험 없이 서브클래스를 수정할 수 있다.
- 조건 로직의 부호화
ex) 객체는 다형성 메세지라는 훌륭한 메커니즘을 가지고 있어 조건 로직을 융통성 있고 명확하게 표현할 수 있다. 조건문을 다형성 메시지를 사용하도록 바꾸면 중복을 줄일 수 있고, 동시에 융통성을 늘릴 수 있다.