问题4，费解的用法目前，我们主要讨论了如何结构化你的类、方法和变量命名。心智模型的另一个重要部分是理解这些方法应该怎样被使用。再次强调，当你最初形成心智模型 时，这是相当清晰的。当你后来返回时，就非常难以重建你的类和方法的、所有有意图的用法了。通常这是因为不同的用法散布在你的程序其它地方。有时候甚至出 现在很多不同的项目中。 我就是在这种情况下发现测试用例是非常有用的。除了相应地知道一个修改是否破坏了代码的明显好处，测试为你的代码提供了一整套的用例。你不必搜遍100个文件，只需看测试就能得到引用的全景。 注意为了达到这个目的，你需要有一整套完整的测试用例。如果你的测试仅仅覆盖了一部分、而你认为测试是完整的，那么你后来将陷入困境。 问题5，不同的模型之间没有清晰的途径你的代码从技术角度看，常常是优秀的、非常优雅，但是从程序意图到语义模型、再到代码存在非常不自然的跳跃。考虑你选择的一堆模型的透明性是重要 的。从程序意图到语义模型、再到代码的过程需要尽可能平滑。你应当能够看透对应到问题的每个模型的所有方面。多数情况下，最好选择特定类结构或算法不是为 了它在隔离方面的优雅，而是可以连接各种模型，为你重建的目的而留下 一条自然的途径。当你从抽象的编程意图走到具体的代码时，你做的选择应该受到 你能够表现更为抽象模型 的清晰度驱使。 问题6，发明算法作为程序员，我们经常认为，我们在为了解决问题而发明着算法。事实很难是这样的。几乎所有情况下，已经有现成的算法可以被组合在一起解决你的问题 了。像最短路径搜索法、字符串相似度算法、粒子群算法等。大部分编程是以正确的组合、选择现存算法来解决你的问题。如果你正在发明新算法，那么，要么你不 知道合适的算法、要么你正忙于你的博士论文。 总结最后总结：作为一名程序员，你的目标是建立能够解决你问题的、尽可能简单的语义模型。把语义模型尽可能靠近地转化为句法模型（代码），尽可能多地提供线索，便于你之后无论哪个人看你的代码，都能重建像你最初脑子里的、相同的语义模型。 设想一下，当你走过你代码的被照亮的森林时，你在身后留了面包屑。相信我，当你需要找到回去的路时，森林将充满了黑暗、朦胧和不详的预感。 听起来容易，实际做起来是很难的。
|
