「漫谈」软件设计的目标和途径是什么？(5)

5.2 可测试性
可理解性可以确保你可以快速的理解现存代码的意图，但是其真实的行为呢？是不是和你所认为的行为就是一致的？上面我说过：“代码只会按照你编写的行为去执行，而不是按照你认为的行为去执行”。
那么如何确保你真实的行为和你所认为的行为是一致的？那就是测试。把你认为的行为也写成代码，去验证你的业务代码执行的时候是不是会按照你给定的输入得到你期望的输出结果。借助自动化的CI，就可以在你每次改动代码时把现有的所有测试都运行一遍，然后你至少可以获得3点收益：
代码真的时按照你认为的行为去执行的。确保你的改动不会破坏现有的代码行为。倒逼你的代码进行合理的分解和抽象，不然你很难编写有效的测试。当然你可能把测试写错了，，，这种概率就小多了吧。况且假设你真的写错了测试，时间久了，这个错误也就变成了feature。为什么呢？也许你代码的消费方已经按照它实际的行为去处理了，这时候你贸然把这个bug修复了，结果可能时消费方反而不能正常工作了。这时候这个错误的测试其实也就变成了消费方的一种契约测试。确保你不会把它改对，，，
比如C#的类库中有个DateTime，在处理时区问题时很多诡异的行为，这时候微软已经无法修正它了，只好再单独新增了一个DateTimeOffset，两者共存，慢慢的迁移过去。
5.3 可隔离性
那么现在你可以快速的理解现存的代码了，也可以确保你的新代码不会破坏已有的功能，也确认你的代码行为是你所认为的行为了。是不是就可以愉快的合并代码并且上线发布了？是的，差不多可以了。但是，凡是总有例外，我们不能把全部希望都寄托在我们能严格落实上述两点。总是要有个备选方案对吧？
可隔离性就是这样的一个备选方案，其意图就是隔离你的代码行为，哪怕它就是腐烂变质成了不可维护的代码，只要不影响其他的模块，那么就还算是可控的。就像万吨巨轮，底层的隔水舱总是一个个的独立的，一个进水了也不影响其他的，从而避免整体的失控。
6 途径
还记得文章开始介绍的目标和途径的概念吧，上述的3个原则是我们的目标，那么想要达成这样的目标有哪些途径可供使用呢？
6.1 命名
曾经有这么一句话，计算机领域有两大难题：命名和缓存失效。一个好名字的重要性不必多说了吧？此外我还有一个心得体会：如果你觉得命名出现了困难，那么请从头审视一下你的设计，或许你走错了方向了。我认为一旦出现了命名困难的问题，那绝对就是你的设计出现了问题。也许时你的方法职责太多了，你无法用简洁的名字描述清楚，也许是你的字段所表达的含义不清，导致你无法准确的用一个简单的词语描述它。