第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 小作坊式的企业往往不讲究规范。这个倒是和实体店的情况差不多，越是小的公司，人事的成分越重，也越缺乏大公司的规范和标准，比如前面说到的单元测试，似乎在小企业里很少有人做。也就是说，在产品质量上，小型公司和大公司比会有差距。
因此，我认为作者的想法是偏颇的。
书中，作者曾这样描述小作坊式的公司：“自己手工劳动，做出产品。人不多，师傅带徒弟，或家传手艺。只做某种行业，不太改行，商业技巧不多。不太做广告，主要靠口口相传，容易被技术进步淘汰。和顾客很熟悉，可以赊账” 这里的描述让我联想起工业时代前夕那些骄傲的手工匠人们，那些面孔酷似猫头鹰、满手皮革味儿的老工匠，在市场已经实现了规范化，托拉斯已经诞生的时代，他们和他们的小作坊都怎样了？换言之，这种根基于前现代社会的人和物，是否还能在业已被资本精神统治的现代社会吃得开呢？我表示怀疑，毕竟太多小而美的事物在我们这个时代消逝了。
