读重构 (Refactoring:Improving the Design of Existing Code)

总觉得自己的代码写的很垃圾,事实上也是如此,每当需求出现变化时,都有力不从心的感觉.
虽然最终总是能解决问题,但是代码看起来一团糟,然后仰天长啸:我×,我这代码没有人能看得懂了!
或许你可以把这个归结为设计问题.计划总是赶不上变化(尤其是做项目),程序员之间的想法又不大一样,往往起初代码还可以说得过去,但是就在不断的更改,添加功能的过程中,程序慢慢的腐败掉.
有一句古老的谚语:If it ain't broke,don't fix it.很多时候我们也是遵循这句谚语的.因为修改可能会带来成本和bug,如果出现新的严重bug,就得不偿失了.而且你不能预料修改后的后果,整个程序需要重新测试,这样会导致项目周期变长且不可控制.
那么如果我们对糟糕的代码视而不见呢?如果需求没有变化,那么还好.但是需求变化是不可避免的,糟糕的代码笨拙而难于变化.过一段时间,你会发现代码完全超出你的控制范围,如果项目够大够复杂的话,糟糕的代码最终导致项目失败.
这么看来,修改与不修改都不像是好办法.横竖都是死,何为?

新买了<<重构>>,这本书很好的解答了这个问题,坏代码需要修改,需要重构,但是重构也不是随便拍脑袋就来的,书的第一章讲了概括的几个重构原则(只看到前两章,正在看第二章).
When you find you have to add a feature to a program, and the program's code is not
structured in a convenient way to add the feature, first refactor the program to make it
easy to add the feature, then add the feature.
当你不得不向程序中加入一个新功能时,如果程序的代码不能用一种方便的方式来添加这个功能,那么首先重构程序使之能容易地加入这个功能,然后在加入此功能.

Before you start refactoring, check that you have a solid suite of tests. These tests
must be self-checking.
当你开始重构之前,确定你有一套坚固的测试系统,这些测试必须是可以自检测的.

Refactoring changes the programs in small steps. If you make a mistake, it is easy to
find the bug.
每次重构只对程序做微小的改动.如果你犯了一个错误,很容易找出bug

Any fool can write code that a computer can understand. Good programmers write
code that humans can understand.
连傻B都能写出机器可以读懂的程序(像我 O(∩_∩)O ),优秀的程序员写出人能读懂的程序.