修改代码的艺术----- 1.2 危险的修改

1.2  危险的修改

行为保持是一项巨大的挑战。在我们需要作出修改并保持行为时，往往伴随着相当大的风险。

为了减小风险，我们要考虑下面这三个问题：

(1) 我们要进行哪些修改？

(2) 我们如何得知已经正确地完成了修改？

(3) 我们如何得知没有破坏任何（既有的）东西？

如果所作改动是有风险的话，你能够承担得起多少改动？

我曾共事过的大多数团队都曾试图以一种非常传统的方 式来控制风险。他们把对代码基的改动数量降至最低。有时候这是一种团队策略：“如果没有被破坏，就别去修正。”开发者在进行修改的时候是非常谨慎的。“什 么？为此创建一个新方法？不不不，我还是把这几行代码直接放到这个现成的方法里面算了，这样我就可以看到新老代码在一起。况且这种做法费力少，也更为安 全。”

人们可能会认为可以通过“避免”二字 诀来将软件问题的数量降至最低，然而遗憾的是，问题总是不可避免。当我们避免创建新类和新方法时，既有的类和方法就会变得越来越庞大，越来越难以理解。当 在任何大型系统中进行修改时，你可能需要一点时间来熟悉一下将要修改的区域。这时好的系统和差的系统之间的差别就体现出来了。对于前者，当你熟悉了待修改 的区域之后，你会对将要进行的修改充满信心。而对于那些结构糟糕的代码，从理清存在的问题到着手进行修改的过程简直就像是为了躲避一只老虎而跳下悬崖一样 痛苦。你一再犹疑：“我真的准备好这么做了吗？唔，好吧，我想我别无选择。”

避免修改还会导致其他不良后果。如果人们不做修改代 码的工作的话，久而久之他们就会对此感到生疏。即便是将一个较大的类分解成几个小类的工作也可能会因为生疏而变得棘手起来。要想保持熟练，唯一的途径就是 经常练习，如一个星期进行好几次。熟能生巧之后，这件事情对你来说就变得像例行公事一样自然而然了。你也会变得越来越精于判断，知道哪些代码可以分解哪些 则不可以，而且做起来也容易得多。

避免改动的最后一个后果就是会带来恐惧心理。不幸的是，许多团队都在忍受着很重的恐惧心理，而且每况愈下。通常他们并不知道他们的恐惧到底有多重，直到他们学到更好的技术，而恐惧心理也随之减退。

我们已经讨论了，避免修改是不可取的做法，然而既然 不能避免，那我们又该怎么做呢？答案是我们应该更努力地去修改。或许我们可以雇佣更多的员工，这样每个人就会有足够的时间来进行分析，仔细审查所有的代码 并“正确地”进行修改。更多的时间和详细审查应该会让修改变得更为安全。但果真如此吗？在所有的代码审查完毕之后，究竟有没有人确切知道他们是否把事情做 对了呢？