这周看了邹欣老师《构建之法》的1,2,16章，获益匪浅。这本书写得妙趣横生，用阿超小飞几个人的生活场景和幽默的比喻帮我理解着软件工程的相关概念，让我对软件工程有了初步的了解：原来开发软件并不是我们想的那样简单：上手直接敲代码就可以了，而是会有一套详细的流程规范。下面是我看书时的一些心得笔记，和一些无法自己解答的疑惑，烦请各位老师批评指教。
第一章：
笔记：
软件=程序+软件工程，是否可以通俗地理解为，程序只是死的机器的东西，为什么做（需求分析），做什么（软件设计），做完后这东西是否可行（软件测试和维护）是软件工程的事情，才是使得软件能卖出去的因素所在。
问题：
P9页提到“软件开发过程有什么特别的难题？学者们总结了下面五点：”中，有一个“易变性”，让我有些难以理解，正如书中说的那样，软件看起来很好修改，比修改硬件容易多了啊，为什么还会说“正确的修改软件是一件很难的事情”呢？为什么会说软件“易变”呢？
我的看法：根据书后标注去翻看了《人月神话》，找到了相关内容：
这样的话，是不是可以理解为：软件正是由于成本低易修改，导致用户需要软件必须紧跟时代潮流和用户需求，做一个可以让用户长久满意的“好软件”是十分困难的？但这样的问题应该是软件维护时的问题，为什么说在软件开发过程中易变性是一个难点？
Ps:关于P12的标注16中的null reference问题，原书中给出的网址是英文的，我这个英语渣理解起来有点困难，就在网上看了这个https://www.zhihu.com/question/29950756/answer/46206598 和这个http://www.php230.com/1446350407.html ，假如他们解释的有误烦请助教老师指教，谢谢老师。
第二章：
笔记：
回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。——来自百度百科
我的理解：回归测试可以理解为害怕拆了东墙补西墙，在我们改这块的bug，完善某一功能假如新模块时，害怕改完后让别的地方出了bug，所以就要重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时, 还需要补充新的测试用例来测试新的或被修改了的功能。
问题：
单元测试必须由最熟悉代码的人（程序的作者来写）
以我有限的代码经验来看，很难理解单元测试的必要性。网上查找了相关资料，说单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。假如想测试这块的正确性，那作者的盲区和程序的盲区一致，也测不出错误来啊？以去年暑假我写的表单验证为例，当时我设想的输入邮箱时的提示是我假想的用户（即我本身）的行为，而学长在试用时做了我自己完全没有想到的操作导致出现了bug,这种bug让作者自己去试应该很难想到，所以我认为单元测试应该由他人（模拟用户）来写，也可能是我对单元测试的理解有误，请各位老师同学批评指正。
第十六章
笔记：
1. P345中，对创新的考虑有一点：创新和目前大众习惯、已有系统是否兼容，我认为这一点是不需要考虑的，创新时，要对利益相关者讲清楚你可以获得什么，假如这种相对于旧产品的便利可以克服替换产品的不适应，那么即使他不符合大众习惯也依然会流行吧。比如淘宝，在使用它之前我有种种的顾虑：买到假货的可能性太大了，哪有实体店买的放心？都不知道怎么偷工减料做出来的，哪有线下的有保障？钱都要放在支付宝里，要绑定银行卡，银行卡的钱多不安全啊一下子？但是见识到网购的方便后，替换购物方式的不适应，种种先前担心的隐患全称不上问题了。移动支付也是如此，你只要让既得利益者看到好处（往小了说就是小商贩，他们不用再找钱了，支付宝12月还推出了商家邀请码扫码领红包活动，商户们更乐意让客户用支付宝了），确实便利，那大众的习惯是可以被改变的。书中P348页中随身听的例子页证明了这一点。
2. 迷思一认为，灵光一闪现，伟大的创新就紧随其后；迷思五认为，要成为领域的专家才能创新。
我的看法：我是比较支持迷思五的。只有当成为一个领域的专家时，你才能对本领域的知识，行情做到透彻，才能去触碰前人未能到达的灰色地带（即迷思六中的技术创新），这时假如你有一个敏锐的头脑，善于将本学科与其他学科进行整合，那商业上的创新（如商业模式用户体验方面）也会比其他新手容易。
我们当时做国创时也牟足劲想“创新”，但是现在回过头来看，当初的项目创新有余，需求不足。（这里的创新有余指的是我们没有做类似P37中提到的“图书馆信息系统”那样的烂大街的创意）我们为了创新而创新的东西真的是市场所需要的吗？ 只有对一个行业的行情有了洞察，你才能对你的创新到底是“假创新”还是真社会需求有底吧？
综上所述我认为，只有当对这个行业有相当深入的了解（无论是技术方面还是应用方面）后，才能做到真正的也许可用的创新。