Why Refactoring Works[By kent Beck]
Programs have two kinds of value : what they can do for you today and what they can do for you tomorrow . Most times when we are programming ,we are focused on what we want the program to dot today . Whether we are fixing a bug or adding a feature, we are making today's program more valuable by making it more capable.
You can't program long without realizing that what the system does today is only part of the story. If you can get today's work done today, but you do it in such a way that you can't possibly get tomorrow's work done tomorrow , then you lose . Notice, though , that you know what you need to do today ,but you're not quiet sure about tomorrow . Maybe you'll do this, maybe that , maybe something you haven't imagined yet .
I know enough to do today's work .I don't know enough to do tomorrow's .But if I only work for today ,I won't be able to work tomorrow at all .
Refactoring is one way out of the bind . When you find that yesterday's decision doesn't make sense today ,you change the decision .Now you can do today's work . Tomorrow , some of you understanding as of today will seem naive , so you'll change that ,too .
What is it that make programs hard to work with ?Four things I can think of as I am typing this are as follows :
- Programs that are hard to read are hard to modify .
- Programs that have duplicated logic are hard to modify .
- Programs that require additional behavior that requires you to change running code are hard to modify .
- Programs with complex conditional logic are hard to modify .
So , we want programs that are easy to read ,that have all logic specified in one and only one place ,that to not allow changes to endanger existing behavior ,and that allow conditional logic to be expressed as simply as possible .
Refactoring is the process of taking a running program and adding to its value , not by changing its behavior but giving it more of these qualities that enable us to continue developing at speed .
解决文章中提到四个问题，解决方法如下：（摘至《Refactoring : Improving the Design of Existing code》）
能够清晰表达意图的好的命名；细粒度的方法；遵循单一职责原则的类；清晰的结构与模块关系。
遵循ＤＲＹ原则；合理利用封装。
遵循开放封闭原则（Open Closed Principle）,即“软件实体对扩展是开放的，对修改是封闭的。”
封装或分解条件分支；以多态替代条件分支；好的命名方法。