이미 소장하고 있다면 판매해 보세요.
|
|
1. 리팩토링, 첫번째 예제
2. 리팩토링의 원리 3. 코드에서의 나쁜 냄새 4. 테스트 만들기 5. 리팩토링의 카탈로그로 6. 메소드 정리 7. 객체간의 기능 이동 8. 데이터 구성 9. 조건문의 단순화 10. 메소드 호출의 단순화 11. 일반화 다루기 12. 대규모 리팩토링 13. 리팩토링, 재사용, 그리고 현실 14. 리팩토링 도구 15. 하나로 합치기 |
|
리팩토링은 버그를 수정할 때 코드를 좀 더 쉽게 이해하기 위해서 사용된다. 어떤 코드를 이해하려고 할 때, 더 깊은 이해를 위해 리팩토링을 한다. 종종 이런 적극적인 프로세스는 버그를 찾는데 도움을 준다. 또한 버그 리포트를 받으면, 그것은 리팩토링이 필요하다는 신호인데, 왜냐하면 버그가 있었다는 것을 몰랐을 정도로 코드가 명확하지 않았다는 뜻이기 때문이다.
--- p.79 |
|
같은 작업을 하지만 다른 시그너처(signature)를 가지는 메소드에 대해서는 Rename Method를 사용하라. 종종 이것만으로는 부족할 때도 있다. 이럴 때는 클래스가 여전히 충분한 작업을 하지 않는 경우이다. 프로토콜이 같아질 때까지 Move Method를 이용하여 동작을 이동시켜라. 너무 많은 코드를 옮겨야 할 때에는 목적을 이루기 위해 Extract Superclass를 사용할 수 있다.
--- p.108 |
|
전통적인 소프트웨어 개발 단계는 분석-설계-구현-테스트로 이어진다. 개발 후반부의 변경사항을 최소화하기 위해서는 정확한 요구분석이 필요하고, 변경에 적절히 대처하기 위해서는 소프트웨어를 유연하게 설계하는 것이 중요하다. 그러나 모든 것을 미리 알 수는 없는 노릇이다. 아무리 정확하게 분석한다 하더라도 변경사항은 계속 발생하기 마련이다. 코드를 수정함에 따라 시스템의 본래 모습과 디자인된 구조는 점점 사라질 것이다. 또한 소프트웨어의 디자인을 유연하게 하는 것은 비용을 증가하게 하고, 코드를 이해하기 어렵게 한다.
리팩토링은 소프트웨어의 외부 기능을 변경하지 않으면서 내부 구조를 바꾸는 기술이다. 리팩토링을 사용하면 나쁜 디자인의 코드를 취해서, 외부 기능을 변경하지 않고, 좋은 디자인의 코드로 바꿀 수 있다. 따라서 리팩토링을 이용하면 처음부터 미리 모든 경우에 대해 고민하고, 필요할지 확실하지도 않은 유연성을 소프트웨어에 주기 위해 비용을 낭비할 필요가 없다. 처음에는 간단한 경우에 대해 코드를 작성하고, 나중에 문제가 복잡해지면 리팩토링을 하면 된다. 리팩토링의 각 단계는 아주 적은 작업만을 포함하고 있고, 또 각 단계마다 테스트를 하기 때문에 안전하게 소프트웨어의 내부 구조를 바꿀 수 있다. 리팩토링을 사용하면 작업의 밸런스가 바뀐다. 모든 것을 미리 생각하기보다는 개발을 하면서 지속적으로 좋은 디자인을 찾는다. 시스템을 구축하면서 어떻게 디자인을 개선할지에 대해 배운다. 그 작업은 개발이 계속되어도 프로그램의 디자인이 계속 좋은 상태로 남아있게 한다. |