《构建之法》阅读笔记

第一部分 关于结对编程的体悟与实践

　　在结对编程这一部分我曾讲过很多的注意点，比如代码变量命名风格、缩进风格、注释风格，前后语句次序风格，等等。然而这里还有一些新的东西。代码风格这个老掉牙的话题咱们先搁置不谈，而说说在结对编程中同样重要的其他注意点。

　　Step1：“自己改+你说我看”：不符合共同协定的编码风格的地方，一律修改

　　我们需要在一开始就商定好代码风格，比如哪些地方需要换行，变量的命名规则等等。

　　然后，先过自己这一关——自己对代码进行修改。比如在上面的例子中，函数名为anothermain，这是什么鬼意思？这种根本不知其所以然的命名，必须根除。还有像enternum这样的变量，也会让人摸不着头脑，应该改为characterNum这种规范的命名。

　　在自己认为没有大毛病之后，还需要对方对自己进行挑错。在这里，挑错要注意一个原则：不要在鸡蛋里挑骨头，要本着找出有意义的错误的原则，认真查错。比如，“这样的函数命名会不会和以后的命名冲突，从而引起歧义？”

　　Step2：探讨潜在的逻辑问题，预防“逻辑灾害”的发生

　　Step3：修改完后也不松懈，继续进行经验总结

　　总结这个步骤，是让我们“事半功倍”的不二捷径。它不容忽视

 

         然而，如果我们进行过程序优化，就会发现，这是一个很令人诧异的结果——代码的运行时间变成了原来的两倍！这究竟是怎么回事呢？

　　原来，在新的函数中，我采取了反复调用子函数的措施来精简代码。而在我的子函数中，我为了继续精简代码，又套用的新的子函数，这里进行了两次的套用。而在判断是否为一个单词并进行储存的时候，这种层层调用的次数是超乎想象的。正是这里头的反复嵌套，大大拖慢了程序的运行速度。

　　接下来是进行修改，在不损失代码简洁性的前提下进行代码优化，其中主要是性能优化。我首先要做的是把两层的函数嵌套改为一层。

　　注意，在这里我并没有把子函数放上来，是出于阅读的简洁性和直观性——直接把我的实践结论告诉大家，而不是用代码和大家继续兜圈子。

　　通过将两层的函数嵌套改为一层，我的子函数从原来的16行变成了42行，可以说复杂了不少，但接下来我们看一下运行效率。

　　代码的运行时间大约是最初运行时间的 1.4 倍。

　　这个结果比第一次优化的结果好了不少，但没有达到本次代码优化的最终目的——在不损失性能的前提下进行感官上阅读体验的提升。当然，我也已经知晓了代码变慢的原因——函数嵌套和函数调用花去了太多无用的时间，接下来的优化步骤也明晰了。

标签：风格,函数,代码,笔记,嵌套,子函数,阅读,命名,构建
来源： https://www.cnblogs.com/liubaiii/p/15934370.html