第1章，第2章，第16章阅读笔记

构建之法是一本独特的教材，和以往的教材彻底不同，里面充满了颇有趣的例子，很是引人入胜，也下降了个人畏难心理。因此阅读的过程也很轻松。通过对第一章，第二章，第十六章的学习，我产生了一些困惑和问题，但一些问题过于庞大，没法彻底解决，一些囿于知识的局限，没法实际操做，可能理解得不深刻，这里只能提出我的的一些见解。

 

---

 

 

第一章

对我而言，阅读第一章主要是一个学习的过程---本身尚未达到反思批判的高度。它告诉我什么是软件工程和计算机科学的区别，也让我理解了为何一些软件看起来那么简单，却须要一个团队长期奋斗才能搞定。阅读的过程当中，我发现本身以往都是以一个用户的角度在看问题，或者一个玩家的心态看问题，而非开发者。就算是开发一个简单的程序，当几千几万的人使用时，这个软件也就变得复杂起来了。

当我又读了几遍以后，发现有一些地方仍是不赞同做者的。

好比下文：

“一个好的软件，即便功能和同类软件区别不大，可是会让人感受到很是好用。这就是软件的用户体验（User Experience）。用户体验和数据结构、算法没有直接的关系，可是不少很是成功的软件就赢在这个方面。”

个人疑问是：用户体验真的重要吗（按照文中的定义）？

个人想法是，它是个难以把握的概念。一样的两个软件，不一样人可能以为用户体验不同。好比我用过qq浏览器，也用过chrome浏览器，但我并不以为chrome有什么明显比qq浏览器好的，虽然网上的风评显然是chrome好。

另外，若是一个软件有了你所须要的功能，那干吗还要下载另一个？除非是其余的缘由。好比一样是通信交流软件，我以为qq和微信的用户体验是同样的，而我两个都用的缘由是认识的人有的用qq，有人用微信。并且，难道决定用户使不使用你的软件的因素不是软件的功能吗？无论怎样类似，两个软件的功能总会有区别，---我认为世界上找不到功能彻底同样的两个软件，除非是抄袭的。不然它们能作到的事情同样，在速度和占用内存方面或者其余方面，确定仍是不同。就好比qq旋风和迅雷，qq旋风就是由于资源没有迅雷多，才被迅雷战胜的。这显然是功能的问题---我用迅雷能够作到qq旋风作不到的事情。再好比有的软件笨重，有的软件轻巧，那这里就必定会涉及到算法和数据结构的问题了。

在网上，我找了一些资料。

有的做者阐述了对用户体验的定义---对用户体验的目标是，作到“天然”。好比iPhone的开锁是天然的，由于触摸是人的天性。再好比Apple取消了“文件夹”，MacOS试图将手指滑动改成和内容一致的方向，都是为追求天然作出的一些努力。

有的做者对B.A.T挨个进行了分析：阿里“天猫”的界面虽然丑，但综合商品的历史评价 、付款的便捷性 、送货的速度 、售后的评价和售后服务，它是最好的。腾讯能作到不丢失信息，即时通信的准确性这一大优点已经盖过了界面的单调。百度向来以技术著称，它的搜索速度和准确度在国内无人能够匹敌。

也有人认为用户体验能够包含三个方面：有用性，易用性，满意度。

在学术上，用户体验的定义是用户心里的情况（倾向、指望、需求、动机、心情等）和具备必定特色的系统（复杂性、目的性、可用性、功能性等）在特定交互环境下产生的结果（Hassenzahl & Tractinsky http://www.360doc.com/content/12/0909/17/9934_235207302.shtml）。根据这必定义，用户、产品或服务、交互环境是影响用户体验的三个因素。

所以，个人理解是，用户体验应该和用户的需求联系在一块儿，也就是，软件的功能和性能都包含在了用户体验这个概念里，那么此处的体验就必定要涉及技术了。

但仍然有一个问题，就是所谓用户体验实际上仍是因人而异，因时而变的，04年Google上市以前，Yahoo的评测结果好于Google，但笑到最后的仍是Google。另外，决定软件成功与否，和先发优点分不开。由于对于一些人来讲，大众的选择就是本身的选择。细微的体验，绝不重要。一个五十岁的人，对他来讲微信就和短信同样，只是你们都在用就用了。而这样的人确定不在少数。那么，在如今同质化愈来愈严重、市场竞争又如此激烈的当下，单单靠产品、用户体验还能获胜吗？

 

 

---

 

第二章

“建立单元测试函数的主要步骤是：
1. 设置数据（一个假想的正确的E-mail地址）
2. 使用被测试类型的功能（用E-mail地址来建立
一个User类的实体）
3. 比较实际结果和预期的结果”

这章遇到的最大问题就是看不懂代码，从致使理解可能有误差。书中举的例子彷佛是在类库里将用户的e-mail地址复制给程序中m-email这个变量，经过VSTS这个软件自带的功能，能够之间生成代码覆盖报告，以及测试的框架。读到这里，我有几个问题或者说困惑：

什么是代码覆盖？

单元测试和debug有什么区别？就我在文中看到的，就是在vsts帮你注释掉了一些代码以后跑一遍数据。那这样感受就和debug没什么区别了。

 

关于第一个问题，我去搜索引擎上查找了一些概念。

“代码覆盖（Code coverage）是软件测试中的一种度量，描述程式中源代码被测试的比例和程度，所得比例称为代码覆盖率。”

仍是太抽象了。而后我找了一篇博文（http://blog.csdn.net/u010425776/article/details/46955325）。

 

 

这是语句覆盖的例子，接下来还有判断覆盖、条件覆盖、分支覆盖的例子。读完以后，我对代码覆盖有了一些浅显的了解---就是看代码跑过的全不全的一个指标，最全面的方法是分支覆盖，对嵌套的多个分支都进行测试。

 

关于第二个问题，我先是查找了一些资料。

“单元测试（unittesting），是在计算机编程中，针对程序模块（软件设计的最小单位）来进行正确性检验的测试工做。”

“Unit testing你的程序主要是由一个个的 Class 组成的，一个类或一个对象固然也是一个单元，而比类更小的单元是类的方法（函式）。若是你的类中的基本单元——如某些方法不能正常工做，在某些输入条件下会得出错误的执行结果，那么如何保证你的类/对象乃至整个应用软件或系统做为一个总体能正常工做呢？因此，简单说，单元测试（优先）的目的就是首先保证一个系统的基本组成单元、模块（如对象以及对象中的方法）能正常工做，这是一种分而治之中的 bottom-up 思想。”

再结合我看到的一些例子，个人理解是单元测试是能够检验程序的逻辑语义，但不能保证API能完成开发者须要的功能，并且，debug是对整个程序而言的，单元测试是对一个个小的模块的debug。

在资料查找的过程当中，我又产生了新的疑问，彷佛许多人认为单元测试是必要的，但由于实际工做中单元测试的麻烦不少，干脆就不写了。

单元测试的麻烦大概有如下几点：
1，测试和开发的不是同一我的，即便天天沟通，测试仍是对开发的不少代码逻辑不熟悉，增长了单元测试的难度。

2，开发的代码每次改动，都须要花更多的时间去改动测试代码，成本过高。

3 单元测试对框架的设计要求很是高，数据与代码与界面要尽量分离。

若是单元测试带来的麻烦和开支超过了收益的话，恐怕没有多少企业会真正地使用这种方法。并且就我了解，彷佛单元测试在2000年之前不盛行，是 JUnit以及xUnit被发明以后开始普及，彷佛还和Java语言的流行以及“敏捷运动”有关，以前的软件彷佛也没有用上过单元测试的方法。我不清楚网上的说法到底是常态呢仍是个例，但这些说法让我产生了一个问题：单元测试应该做为一种硬性标准，仍是一个较高的目标？

 

 

 

 

 

---

 

16章

第十六章主要讲的是创新的问题。书中提到了创新的几个迷思，我以为都很能启发思考，而且再一次认识到单纯的理科思惟在这个领域未必会得到成功，由于咱们必须考虑到大众的因素。接下来的几章都比较有意思，做者提出了创新时机，创新招数，还举了一些例子。但在阅读到16.5也就是创新与做坊时，我对一些观点产生了怀疑。

"日前，信息产业部副部长娄勤俭在出席中国软件产业生态链高层论坛时表示，中国软件产业的规模还比较小，软件企业的实力较弱，不少企业还处于手工式的开发生产阶段，缺少核心技术，长期处于产业链的低端，发展方向受制于人，出口能力较差， 为此从此信产部将从四大方面大力发展我国软件产业。……
做坊，英语叫Workshop，好多学术论文也发表在各类Workshop中，你们也以为挺有面子的。美国好多家里的车库（Garage）、地下室都兼做主人的小做坊。在中国的上下文提到“做坊”，你们会想到什么？我想到：本身手工劳动，作出产品。人很少，师傅带徒弟，或家传手艺。只作某种行业，不太改行，商业技巧很少。不太作广告，主要靠口口相传，容易被技术进步淘汰。和顾客很熟悉，能够赊帐……这些好像都不是缺点吧？为何要着急走出去？"

问题：创新的出路真的在小做坊式的公司身上吗？

首先，本书已经提到了，一个团队须要不少人员保证产品质量：质量保障（Quality Assurance），软件测试（Testing），需求分析（Re-quirementAnalysis）、设计实现、软件维护（Software Maintenance）、项目管理（Project Management）。”若是要作一个大型的软件或项目，这么多的岗位，势必要求分工的细化，我认为这是小做坊不能胜任的。并且书中的一些例子我不认同，好比马云的例子---他虽说了“小就是好”，但是他的实际行动和言论彻底相反啊。

其次，我查了些资料，有了如下发现：

1 小公司/小团队的生存状态不佳，每每没法在大型公司前保住本身的劳动成果，反而常常被大公司利用，好比在几个月前某网络论坛上被爆出的阿里公司“智能测肤”项目盗窃抄袭“你今天真好看”团队的代码。比较有意思的是，抄袭代码的事件发生在该团队向阿里公司商谈合做不成以后。可能有些小做坊式的公司会作出一些不同的东西，但它们最终仍是被大企业收编了。相对来讲，阿里的“价值观”已经算是比较正的了，至于某些靠抄袭起家的某t，就更不消说了。

2 中国小做坊模式的公司是过去的盈利模式。在浏览了一些帖子以后，我发现许多人在强调团队合做的重要性，“求伯君的年代已通过去了”----这是我常常看到的一句话。书中举的比尔盖茨和Google创始人的例子，都是在二零零几年，也就是互联网一片空白的时代，我我的的理解是，当时的网络世界一片蓝海，所以灵活的小型公司能够发现更多的商机，并迅速地调整，投入应用，而大公司体态臃肿，政策可能不如小公司灵活。可是，小型公司可能已经不能适应如今竞争激烈的互联网“红海”，我的的灵光和大片的商机被团队的协做和激烈的竞争所取代。

所以，小做坊没法保证创新给自身带来的益处，那么创新每每就由一些互联网“托拉斯”完成了，事实上，人工智能，无人驾驶，都是goole，百度等一系列big one在探索的。对于小公司，它们既无开设一个实验室的资金，更缺少能创新的专业人才。

3 小做坊式的企业每每不讲究规范。这个却是和实体店的状况差很少，越是小的公司，人事的成分越重，也越缺少大公司的规范和标准，好比前面说到的单元测试，彷佛在小企业里不多有人作。也就是说，在产品质量上，小型公司和大公司比会有差距。

所以，我认为做者的想法是偏颇的。

书中，做者曾这样描述小做坊式的公司：“本身手工劳动，作出产品。人很少，师傅带徒弟，或家传手艺。只作某种行业，不太改行，商业技巧很少。不太作广告，主要靠口口相传，容易被技术进步淘汰。和顾客很熟悉，能够赊帐” 这里的描述让我联想起工业时代前夕那些骄傲的手工匠人们，那些面孔酷似猫头鹰、满手皮革味儿的老工匠，在市场已经实现了规范化，托拉斯已经诞生的时代，他们和他们的小做坊都怎样了？换言之，这种根基于前现代社会的人和物，是否还能在业已被资本精神统治的现代社会吃得开呢？我表示怀疑，毕竟太多小而美的事物在咱们这个时代消逝了。