关键词：
这周看了邹欣老师《构建之法》的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中提到的“图书馆信息系统”那样的烂大街的创意）我们为了创新而创新的东西真的是市场所需要的吗？ 只有对一个行业的行情有了洞察，你才能对你的创新到底是“假创新”还是真社会需求有底吧？
综上所述我认为，只有当对这个行业有相当深入的了解（无论是技术方面还是应用方面）后，才能做到真正的也许可用的创新。
构建之法第十六章(代码片段)
《构建之法》第一、二、十六章疑问我通过阅读发现这是一本十分有趣的书。不同于别的书的晦涩难懂，《构建之法》利用浅显易懂的语言，贴近生活的例子向我们讲述了软件工程的内容。第一章 概论软件=程序+软件工程扩... 查看详情
《构建之法》第十六章读后感更正
第十六章IT行业的创新1.关于灵感。灵光闪现固然重要，很多伟大的发明依靠的就是灵光一现的基础，但是灵光闪现的前提是个人的思考，长时间的思考。完成这一灵光的基础是不断的尝试，提高自己的技术。这样才会将自己的... 查看详情
《构建之法》第十六章阅读与思考
第一章 概论 市面上有很多种赚钱的方式：有的交钱买断有的“先试用再交钱”，有些软件也提供试用版、免费版和正式版，还有的类似期刊订阅，每年交钱。有的不但免费，连源代码也一并奉送，但是要求获得... 查看详情
《构建之法》第六章读书笔记
一、敏捷的流程简介敏捷开发的原则是：1、尽早并持续地交付有价值的软件以满足顾客需求2、敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势3、经常发布可用的软件，发布间隔可以从几周到几个月，能短则短... 查看详情
关于构建之法第第二与第十六章阅读疑惑
第一章、概论 原文的1.2.1节中有说到软件的不可见性，其中有这么一段描述：“商用软件出现了错误，工程师可以看到程序在出错的一瞬间留下的一些痕迹（错误代号、大致的目标代码位置、错误信息），但是几乎无法完整... 查看详情
第四周读书笔记《构建之法》(代码片段)
第四周读书笔记《构建之法》#wmd-previewh1color:#0077bb 第四周读书笔记《构建之法》沈三景PB15061249软件工程读书笔记 前言本周接着读了构建之法（上周读了《程序员的修炼之道》）的第六、七两个章节。 第六章敏... 查看详情
《构建之法》（第十七章）读书笔记(代码片段)
一、关于代码规范1.1因为软件开发多数是一个团队的事情，所以需要格外注意代码规范。我们的代码日后通常是需要去维护的，是需要去给别人看的。但是，不同的编程语言对代码规范的要求是否相同呢？因为在工作室学的是前... 查看详情
构建之法——读书笔记
第六章敏捷流程在软件工程的语境里，“敏捷流程”是一系列价值观和方法论的集合。敏捷开发的原则： 1.尽早并持续地交付有价值的软件以满足顾客需求。 &nbs... 查看详情
构建之法——读书笔记
《构建之法》第十&十一章主要讲述了在软件设计前期的需求分析问题上的方法和实践经验，分为“典型用户和场景”以及“软件设计与实现”。其中第十章大部分内容包含：用户的分类（典型用户可以包括以下内容... 查看详情
读书笔记6—构建之法
第六章——敏捷流程1、 这一小节中有一个图表，对比了敏捷（Agile）、计划驱动（Plan-driven）、形式化的开发方法（FormalMethod）的适用范围。里面提到的形式化的开发方法，其基本步骤是怎样的呢？为什么它能... 查看详情
《构建之法》读书笔记六
第14章：质量保障软件的开发过程有三个主要特性：好、快、便宜。在开发一个软件时，我们应该尽可能的保证软件的质量，不能盲目地听从所谓的“专业人士”的意见，要有自己的见解。衡量一个软件的质量：研发出符合用户... 查看详情
读《构建之法》之一，二，十六章有感
...终将得到自己的一份收获。 这几天阅读了《构建之法》的第一，二，十六章，我个人的阅读速度应该属于比较慢的那种，遇到什么不确定的，不理解的概念总要停下来好久，各种百度，否则继续阅读的时候总有种急... 查看详情
第一周读书笔记《构建之法》(代码片段)
构建之法读书笔记#wmd-previewh1color:#0077bb 构建之法读书笔记沈三景PB15061249软件工程读书笔记 前言开学前两周，杂事颇多，没有充足的时间阅读《构建之法》，只能每天在睡前阅读约半小时，故只看了前三章。虽如此... 查看详情
第二周读书笔记《构建之法》(代码片段)
构建之法读书笔记#wmd-previewh1color:#0077bb 构建之法读书笔记沈三景PB15061249软件工程读书笔记 前言本周阅读了构建之法的四、五两个个章节。这三个章节主要讲述了代码规范、结对编程、团队模式、开发流程。 第... 查看详情
构建之法第七，第十七章读书有感
第四章两人合作 关于合作中算法的使用 在第四章的叙述中，我们看到了代码的编写规范，代码的命名规范，我们还知道要写注释，要有良好的代码设计和错误处理。而这些都是我们在使用语言进行编辑中的问题。我们... 查看详情
《构建之法》第四&十七章读书笔记
《构建之法》第四&十七章读书笔记一． 前言 再次阅读《构建之法》，愈发被其中生动有趣的举例吸引。作为一本给予软件工程学生的书籍，其不以枯燥的理论知... 查看详情
构建之法——读书笔记
第8章需求分析8.1软件需求 寻找需求：1.获取和引导需求（Elicitation） 软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。 2.分析和定... 查看详情
构建之法——读书笔记
第七章MSFWhatisMSF?——MicrosoftSolutionFramework（微软解决方案框架）即一个方法论，也就是微软推荐的软件开发方法。MSF基本原则：MSF没有像敏捷那样搞一个宣言，但是它也有一套思想框架—9条基本原则 1.推动信息共享与沟通（... 查看详情