11.5  从影响分析当中学习

建议你只要一有机会就去分析分析代码中的影响。有时候，在对一个代码基很熟悉了之后，就会明白在做影响分析的时候无需操心某些角落，有这种感觉就意味着你已经发现了代码基所具有的一些“基本品质”。最好的代码中是没有多少“陷阱（gotcha）”的，它们里面所包含的一些“规则”（不管这些“规则”有没有被显式表达出来）使你在寻找可能的影响时不至于钻牛角尖。找出这些“规则”的最佳方式便是，首先设想一个在软件的不同部分之间传递影响的途径，这一影响传递途径必须是你从未在代码基中见到过的，然后对自己说：“不，那样的话就太愚蠢了。”如果代码基中有许多那样的规则的话，你就会发现在其中工作起来要容易得多。在糟糕的代码中人们不知道这些“规则”是什么，或者说即便有所谓“规则”也到处都是“例外”。

上面所谓“规则”并不一定是指编码规范或编程风格（如“决不使用受保护的成员变量”）之类的东西，而通常是一些与实际场景相关的方面。比如在本章开头的CppClass例子当中，我们做了一个小小的练习，试图搞清当一个CppClass对象被创建出来之后哪些动作会对其使用者产生影响。下面就是相关代码的摘录：

public class CppClass {

    private String name;

    private List declarations;

    public CppClass(String name, List declarations) {

        this.name = name;

        this.declarations = declarations;

    }

    ...

}

我们知道这样一个事实，就是当一个declarations列表被传递给CppClass的构造函数之后，人们可能还会对该列表进行修改。“但那样就太愚蠢了”，这正是刚才提到的规则的理想候选。如果在最初查看CppClass的时候就知道接受到的declarations列表是不会再改变的话，接下去的影响推测便会容易得多了。

总的来说，我们对影响的扩大范围的限制越是严厉，编起程序来就越容易，从而减少理解一段代码所需的前提知识。最极端的情况便是使用像Scheme和Haskell这样的函数式编程语言来编程。用这些语言编写的程序有时候真的很容易就能够理解，不过这些语言被使用得并不广泛。不管怎么说，在面向对象语言中，限制影响的作用范围可以令测试变得容易得多，而且并没什么东西阻碍你这么做。