构建之法阅读笔记（一）

【第一章】

一、我的思考

〖关于让代码易读〗

刚打开书就看到在P.3作者提到了关于“软件团队的人员流动的问题”，即“新的成员要尽快读懂应有的程序，了解程序的设计”“团队的新老成员要一起修复各种各样的问题”。因为我还没有在公司实习的体验，因此在看到这些文字时的确会有一些疑问。

但巧合的是，我在前天CSDN的推送中也恰好发现了一篇名为《为什么你的代码如此难以理解？》[1]的文章，里面详细说明了这个问题。

作者很敏锐地发现了自身问题，结合这位职场中人的代码体会我也总结出一些想法：

①如果想要易于维护的简单代码，那么尽可能消除会出现意外的复杂性尤为重要。首先是文中提到的“心智模型”的建立，需要理解你所要试图解决的问题，解释现实个体所运作的历程，然后形成方案模型，接着是构建最简单的语义模型。在这一进程中，应当尽量避免复杂的思考，建立尽可能简单的模型，来使你的代码容易读懂。

②而将语义模型的含义转换成计算机能够理解的语法则需要尽可能多地留下线索，即句法模型的建立。文中给出了一些例子来说明，包括类、方法和变量命名的命名以及注释的

③足够的组块会缩短了你的代码和你脑中的模型的距离，也更容易重建你的心智模型。当你使用组块（例如算法和标准函数）时，它会让你停下来思考，你编写的代码是如何运行的，而不是考虑它做了什么。

④作者提到了“测试用例”[2]这个概念。测试时不仅要知道一个修改是否破坏了代码的明显好处，还需要在测试时有一组完整的覆盖全部的测试用例。

⑤不同模型之间需要有清晰的路径。多数情况下，最好选择一个特定的类结构或算法，能够连接各种模型，并为重构意图留下一条自然的路径。

⑥尽量以正确的组合、选择现存算法来解决你的问题，而不是为了解决问题而发明着算法。

二、我的问题

书中P.16提到bug是“软件的行为和用户的期望值不一样”“是否是bug取决于用户、开发者的不同角度”，并且在P.15提到了“bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性”。但是老师上课的时候说到过乔帮主的故事：

当初有人问乔布斯：“如何通过市场调查了解大众需求，才能让产品如此成功？”
乔布斯的回答是：“不用做调查，消费者并不知道他们需要的是什么，而苹果会告诉他们什么才是潮流！”福特也说过“如果当初我去问顾客到底想要什麽，他们会回答说要一匹跑得更快的马。”那么应该怎么理解用户需求、bug和用户满意度的关系呢？

【第二章】

一、我的思考

〖关于单元测试〗

书中P.27有一段小飞和阿超的对话，其中阿超的一句话被作者标黑了：“100%的代码覆盖率并不等于100%的正确性”，那么追求“100%的代码覆盖率”是必要的吗？我在知乎上找到了相似的问题讨论《实际软件工程中是否真的需要100%代码覆盖率（code coverage）？》[3]。

大神们基本上都认为：把测试覆盖作为质量目标没有任何意义，但是我们可以把它作为一种发现未被测试覆盖的代码的手段。“ThoughtWorks中国”[4]提出：“对于需要快速上线的短期项目，需要注重的是让测试覆盖核心功能代码。如果你的项目是一个长期项目，那么高覆盖率是非常有必要的，它意味着高可维护性，以及更少的bug。代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量绝对不会高到哪里去，可以作为测试自我审视的重要工具之一。”

同样在这篇文章中我概念性地了解到了《构建之法》中P.27提到的度量覆盖率的四个维度：

行覆盖率（line coverage）：度量被测代码中每个可执行语句是否都被执行到，但不包括java import，空行，注释等。

函数覆盖率（function coverage）：度量被测代码中每个定义的函数是否都被调用。

分支覆盖率（branch coverage）：度量被测代码中每一个判定的分支是否都被测试到。

语句覆盖率（statement coverage）：度量被测代码是否每个语句都被执行。

所以行覆盖率的高低不能说明项目的好坏，我们要从多方面进行思考，一般我们遵循的标准应是：函数覆盖率 > 分支覆盖率 > 语句覆盖率。

而对于本书中提到的单元测试的代码覆盖率，单元测试的覆盖率并不只是为了取悦客户或者管理层的数据，它能够实实在在反应项目中代码的健康程度，帮助我们更好的改善了代码的质量，增加了我们对所编写代码的信心。

〖关于项目时间的估计〗

我一直是个困扰：怎么来估计一个项目的完成时间和时间划分呢？记得本节课的第一次课上老师问：“这个代码你们多久能写完”，我当时一脸懵：哈？这还能估计出来？翻到本书第二章P.43时，作者建议我去看看第8章，于是我对此有一些认识。

从P.176页开始，本书通过举例引出了三个概念：目标、估计和决心，例子很简单但很易懂，突然感觉理解到了一些。后面还提到了一些提高估计能力的技巧：①参考前人的经验来做出自己的推断；②快速原型法，写一个简单的应用，实际看看情况如何，给项目估计提供更好地数据支持。具体的影响因素文中也有说明：包括产品因素、平台因素、人员因素和项目的因素。

文中有一句话很有意思：“领导，您已经已经制定了一个商业目标，现在你是想听客观的估计呢？还是我主观的决心？”恩，简单易懂

对于“程序员如何正确估算项目完成时间”[5]，知乎上也有一些很有意思的回答：①“需求要改架构，写的代码烂要改bug，天知道有多少种原因，总之乘以4就对了”（90赞）；②“另一方面乘以四之后还是自己估算的时间，一不留神又可以乘以四”；③“总之就是看运气”；④“小公司老板听到乘4不吃了你╮(╯▽╰)╭”；⑤“以後估時間先上個1024才是正解”……

〖关于侯世达定律〗

侯世达定律（Hofstadter's law）：做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。侯世达定律指做复杂任务需要花费的时间总是很难预计的。

程序员经常会引用这一定律，特别是在进行有关提高效率的讨论时（如《人月神话》和极限编程）。其自指的特征反映了即便意识到任务的复杂性，预计花费的时间仍是困难的。

这一定律最初是描述早年国际象棋人机对弈的现象。侯世达写道：“计算机下国际象棋的早期阶段，有人曾估计再要十年的时间计算机（或程序）就能得到世界冠军。可是，十年过去之后，计算机要成为世界冠军似乎还要再过十年……”他将这一现象看作是递归化的侯世达定律的一个例证。

二、我的问题

第二章中提到了“效能分析”的方法并举例进行了说明，但是我还是有点不太明白，效能分析的作用和含义，希望可以有简单的语句说明一下。

【第十六章】

一、我的思考

〖关于创新〗

第十六章整个都是关于创新的“迷思”，我则想谈谈创新工场的问题：

李开复这个名字应该说是人人皆知的，但是对我来说，他是我逃离高中课本之后新认识的第一个人，或者说第一本书《世界因你不同》（自传）。作为创新工场的董事长，他的经历也是很丰富的，也就更能给予我们一些帮助与期望。对于创新工场的失败项目，他是这么说的[6]：“

失败或碰到挑战的项目也不少。这里不点名，不谈细节，但是谈谈碰到什么挑战（有些已经失败，有些还在努力）：

有一个项目由几个很牛的技术人员负责，策划一个很有技术深度的平台，但是初步搭建后，原来认为的潜在客户其实不愿意如此依靠一个第三方的技术平台。

有些项目出现创始人不和的问题，都是认识不久的共同创始人，创业前充满激情，甚至彼此互补加分，但是创业后发现彼此的远景或工作方式不符合。如果一位创始人离开，对士气打击较大。

有一个项目是一位很优秀的产品经理，但是这个项目成功关键之一是要建立很好的线下合作伙伴关系，而这个关键做不好，产品再好也没有用。

有一个项目有一位很聪明的创业者，总是想加新的功能，新的产品线，不够专一，产品推出迭代太慢，错失市场良机。

有一个项目过分相信美国的趋势，忽视了在某方面中国的互联网格局已经和美国不同，走了弯路才发现一个美国的良机在中国并不一定存在。”

二、我的问题

前面我提到的李开复自传《世界因你不同》中有一节他在SGI（Silicon Graphics）工作的经历，他给这一段文字命名为《没有用的创新》，最后他说：“‘世界不需要没有用的创新’，这么简单的道理我竟然没有吃透”。其实创新离我们很近，不管是各类专业内的比赛，还是生活中出现的各种设计，都是有着一模一样的创新者的心思在里面。那么我的问题是：作为一个大学生，想要参加一些诸如互联网＋、创新创业项目的同学，可以通过什么途径来寻找合适的创新项目呢？

【安利】

〖关于本书封面〗

之前没有注意，今天突然发现本书的封面是鲁班锁，分享一个B站上的木质鲁班锁制作向的视频[7]；

然后ZeeCamp创新工场有一个创意鲁班锁的拼装，看起来超酷炫，像闪亮的星星，感兴趣的可以自己去搜下哈哈。

〖关于神秘的程序员们〗

第二章的读书笔记中提到了项目估计时间的问题，我也无意间发现了一篇很有意思的漫画《神秘的程序员们》23《在人世间最艰难的回答：这个多久能开发完？》，链接自取[8]；

《神秘的程序员们》作为一个程序员星人，在地球上工作生活时，你是否会感到孤独呢？这里有来自程序员母星的亲切问候和地球漫游指南。中文首部以程序员文化、技术主题、项目管理及互联网创业的为主题漫画，诞生于09年。主创：西乔、霍炬。

【附录】

[1] 《为什么你的代码如此难以理解？》 http://mp.weixin.qq.com/s/9HtoAnoNvWwFLPje9Qpg6A

[2] 测试用例（Test Case）

是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

[3] 实际软件工程中是否真的需要100%代码覆盖率（code coverage）？ https://www.zhihu.com/question/29528349