漫谈 ‖ 软件设计的目标和途径.docxVIP

漫谈 ‖ 软件设计的目标和途径 这条准绳看起来很有客观性的倾向，但是其实并不是。 比如说你刚写了一段代码，你觉得简约理解，他看起不简约理解；或者说代码是他写的，他看起来很简约理解，但是到你这里无法一下子理解他的思维，然后你就觉得不好理解。假如消灭了这样的情况，那么则统统都是不行理解的。这时候你要说了：你要一棍子打死双方啊。是的，正是如此。再回想一下我们的目标是什么？可维护性！这里的维护不单单是说你的代码你来维护，而是大家相互交叉着；你新增了一个功能，后续担任其他的事情去了，那么这时候就由你的队友来担任维护了；或者你接手维护别人的代码。 所以我们需要一个客观上的可理解性。那么到底什么才能叫客观？没法度量啊！其实也不简单，就是看当你读到一段代码的时候，你能否需要额外的思考，额外的脑中维持一个上下文的环境才能明白这段代码的意图，假如需要，那么就是不行理解的，至少也是不易理解的。更简约点说就是这段代码应当让你不用思考就看的明白它的意图。比如下面的一个小例子，功能是完全等价的，但是差异格外微妙。 // 1 if(userList.isNotEmpty()){ } // 2 if(userList.isEmpty() == false){ } // 3 if(!userList.isEmpty()){ } // 4 if(userList.length() != 0){ } 你觉得可理解性怎样排？答案是确定的吧？1 2 3 4。 1、1是不是你根本就不用思考，直接读下来就晓得其含义？ 2、2则是有一个==fasle的过程，需要你进行简约的思考。 3、3则是接近于2，但是比2更差一点，由于取反符号在前面，但是其打算性的值则在后面，而你的阅读挨次是从左向右，所以你需要一个比2略微更简单一点的思考过程。 4、前三个还都一眼能看出来是空或者非空的语境，但是4就更差了，4的字面意思是长度不等于0，规律上其实和非空是等价的，但是你需要在脑中做这样的一个映射长度!=0等同于非空，这个的笼统层级明显更低了一个层级。 不晓得能否体会其中差微小差异。那么你觉得这些理解是客观的还是客观的呢? 可测试性 可理解性可以确保你可以快速的理解现存代码的意图，但是其真实的行为呢？是不是和你所认为的行为就是全都的？上面我说过：“代码只会依据你编写的行为去执行，而不是依据你认为的行为去执行”。 那么如何确保你真实的行为和你所认为的行为是全都的？那就是测试。把你认为的行为也写成代码，去验证你的业务代码执行的时候是不是会依据你给定的输入得到你期望的输出结果。借助自动化的CI，就可以在你每次改动代码时把现有的全部测试都运转一遍，然后你至少可以获得3点收益： 1、代码真的时依据你认为的行为去执行的。 2、确保你的改动不会破坏现有的代码行为。 3、倒逼你的代码进行合理的分解和笼统，不然你很难编写有效的测试。 当然你可能把测试写错了，这种概率就小多了吧。况且假设你真的写错了测试，时间久了，这个错误也就变成了feature。为什么呢？或许你代码的消费方已经依据它实际的行为去处理了，这时候你贸然把这个bug修复了，结果可能时消费方反而不能正常工作了。这时候这个错误的测试其实也就变成了消费方的一种契约测试。确保你不会把它改对 比如C#的类库中有个DateTime，在处理时区问题时很多诡异的行为，这时候微软已经无法修正它了，只好再单独新增了一个DateTimeOffset，两者共存，渐渐的迁移过去。 可隔离性 那么现在你可以快速的理解现存的代码了，也可以确保你的新代码不会破坏已有的功能，也确认你的代码行为是你所认为的行为了。是不是就可以开心的合并代码并且上线发布了？是的，差不多可以了。但是，凡是总有例外，我们不能把全部期望都寄予在我们能严格落实上述两点。总是要有个备选方案对吧？ 可隔离性就是这样的一个备选方案，其意图就是隔离你的代码行为，哪怕它就是腐烂变质成了不行维护的代码，只需不影响其他的模块，那么就还算是可控的。就像万吨巨轮，底层的隔水舱总是一个个的独立的，一个进水了也不影响其他的，从而避开全体的失控。 6 途径 还记得文章开头引见的目标和途径的概念吧，上述的3个准绳是我们的目标，那么想要达成这样的目标有哪些途径可供使用呢？ 命名 已经有这么一句话，计算机领域有两大难题：命名和缓存失效。一个好名字的重要性不必多说了吧？此外我还有一个心得体会：假如你觉得命名消灭了困难，那么请从头端详一下你的设计，或许你走错了方向了。我认为一旦消灭了命名困难的问题，那确定就是你的设计消灭了问题。或许时你的方法职责太多了，你无法用简约的名字描述清楚，或许是你的字段所表达的含义不清，导致你无法精确?????的用一个简约的词语描述它。 目标 效果 解释 可理解性 ++ 添加可读性。 可测试性 无 无影响。 可