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