精读《构建之法》的理解与思考
前言
有时间去读两本书，不如拿读两本书的时间去精读一本书。于是粗略读完《构建之法》三个章节后，我又重新回顾了一遍，勾画出了一些我不懂的地方，带着这些问题，我去查阅了相关资料，结合个人感悟写成了这篇博客。其中有我的笔记，也有我的困惑，希望跟大家一起交流谈论。
第一章
问题一
探究软件企业中实际开发中运用到的商业模式到底是什么样的？
原文回顾
软件企业 = 软件 + 商业模式
商业模式影响了一个软件企业的成败
我的观点
查询相关资料后，我了解到，传统的软件开发模式，比较类似于互联网中的Web 1.0的门户网站，是以产品为中心，客户围绕着产品中心做圆周运动，而不是以客户为中心。而Web 2.0要逐步完成“去中心化”的工作，让客户成为中心，产品围绕客户的中心做圆周运动。回想自己以前开发新闻管理系统的经历，根本没有涉及需求分析与软件测试，两三个人熬夜做出来了，仅仅满足运行通畅这一基本条件，谈何满足以用户为中心，这样的软件一发布，哪能吸引住顾客？贯彻Saas（Software-as-a-Service）理念于今后的开发中显得尤为重要。
问题二
看到需求分析的探究时，我想到了乔伯斯说过这样一句话，“不必做市场调查，因为消费者自己也不知道自己想要什么”，那么如何正确理解这一话呢，需求分析是为了满足用户的所有需求吗？到底是有了需求再有产品，还是有了产品才有需求？
原文回顾
需求来自于实际，而不是自己想象出来的“需求”或者人云亦云的需求（例如：虚拟的、没人用的、也没有数据的“图书管理系统”）。
我的观点
查询资料，我认识到，在进行用户分析时，会对目标用户进行分类，：前卫（10%）、普通（80%）、保守（10%）。而在分析用户需求时，着重对前卫人群的需求进行分析，往往这些人都是比较新潮、时尚、有创意、个性以及流行的趋势。一个有“创新”的产品，往往不是用户想到的，而是用户接受了我们针对需求所做出的解决方案。于是，用户需求调研不是通过需求提出什么样的功能或服务，而是去验证我们的产品理念是否能让用户接受。这也许就是乔布斯说出这句话的本意。
第二章
刚开始读第二章，感觉很迷茫，很多概念以前都没有接触过，比如代码覆盖率，单元测试，回归测试等等。于是自己看了几遍博客，对这些概念有了一些初步的认识。
问题一
原文中提到了代码覆盖率，那么什么是代码覆盖率？
原文回顾
100%的代码覆盖率并不等于100%的正确性！
我的观点
代码覆盖（Code coverage）是软件测试中的一种度量，描述程式中源代码被测试的比例和程度，所得比例称为代码覆盖率。在一些博客中还提到了代码覆盖率的几种度量方式。最常用的几种：语句覆盖、判定覆盖、条件覆盖、路径覆盖。同时我还认为不能盲目追求代码覆盖率，覆盖率数据只能代表你测试过哪些代码，不能代表你是否测试好这些代码。举一个例子我们看下面的被测试代码：
int foo(int a, int b)
{
return a / b;
}
假如我们的测试人员编写如下测试案例
TeseCase: a = 10, b = 5
测试人员的测试结果会告诉你，他的代码覆盖率达到了100％，并且所有测试案例都通过了。然而遗憾的是，我们的语句覆盖率达到了所谓的100%，但是却没有发现最简单的Bug，比如，当我让b=0时，会抛出一个除零异常。所以不要过于相信覆盖率数据。
问题二
为何要做单元测试？如何一步步进行单元测试？它的流程是什么样的？
我的观点
1.什么是单元测试？
单元测试( unit testing )，是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
2.为什么要编写单元测试?
单元测试有不少的优点，能够给我们的工作带来很大的帮助。单元测试的优点1.帮助开发人员编写代码，提升质量、减少bug。如果大家分析一下我们bug原因的构成，我想有会有一部分bug的原因是开发人员在编写工作代码的时候没有考虑到某些case或者边际条件。造成这种问题的原因很多，其中很重要的一个原因是我们对工作代码所要完成的功能思考不足，而编写单元测试，特别是先写单元测试再写工作代码就可以帮助开发人员思考编写的代码到底要实现哪些功能。例如实现一个简单的用户注册功能的业务类方法，用单元测试再写工作代码的方式来工作的话开发人员就会先考虑各种场景相关，例如正常注册、用户名重复、没有满足必要的填写内容....等等，之后就会编写相关的测试用例
第十六章
问题一
迷思之一，灵光一现，伟大的创新紧随其后
原文回顾
不要一开始就想着找到并拼对所有的拼图块，以为能够打造一个巨大的创新。
在“现代软件工程”课上，许多同学也提出了不少宏伟的创新想法，但是到了课程结束，什么也没做成，只剩下一个空的构想。
我的观点
如何才能使空的构想变成现实呢？结合第一章软件开发的不同阶段，从玩具阶段到业余爱好者，再到探索阶段，最后到成熟的产业阶段，我想这同样适用于个人的发展。我们有一个宏伟的构想，尽管目前没有能力去实现，但我们可以从培养兴趣爱好一步步做起，积累经验，做一些小的项目，创新不是偶然间取得的，它需要知识的积累，等到时机成熟，没准下一个砸向牛顿的苹果可能会砸向你。
尾言
《构建之法》这本书写的妙趣横生，一些难懂的专业术语，在作者朴素又抽象的阐述下，变得简单。而且这种做中学的模式，让我在实际的开发中有了更多的收获，在此为老师们的这种教学模式打call。
