今天阅读了《构建之法》的前15页。这一节是整个软件工程的概论，邹欣老师从大家众所周知的一个命题：程序=数据结构+算法，引出了程序的这一个概念。然后又用一个实际的案例，就是一个家长帮自己的孩子写了一个每天出算术题的小程序，到随着学校老师新提的不断需求，而扩展到一个比较大的系统的软件工程的范畴。引出了一个扩展链：程序->应用软件->软件服务.然后又扩展出了整个软件工程的技术名词，包括：源程序数据软件架构软件设计与实现源代码管理配置管理质量保障软件测试需求分析程序理解软件维护服务运营软件生命周期项目管理用户体验国际化和本地化软件商业模式职业道德规范
由此从最原始的公式逐渐推演和扩展：
由此得出一个结论：程序（算法，数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。软件从业人员和软件企业的道德操守会极大地影响软件用户的利益。
然后，通过类比人类对飞机的发展阶段：从叠纸飞机（玩具阶段），到用气球实现飞屋环游（业余爱好阶段），再到莱特兄弟发明飞机（探索阶段），再到现在的商业大飞机（成熟的产业阶段）。作者指出一个软件的开发阶段也是从简单到复杂的阶段，并且进行了对比，指出在每一个阶段如果成功或失败，会引起的不同结果。
通过这一天的阅读，对软件工程的了解，也从原来的模糊逐渐到清晰。而作为身在其中的工程人员，也清楚了自己在整个软件工程中的定位，其中的很多词汇也都是平时自己工作中耳熟能详的。期待明天的继续阅读！
作者之前已经对计算机和软件工程进行了一个大致的描述，相信读者已经跃跃欲试了。然而，作者给大家提了一个醒，就是关于如何去衡量一个软件是否合格的标准或评价。那就是软件测试了！接下来作者讲解了软件测试的概念和一些分类。软件测试的概念：
软件测试的分类：（1）单元测试（2）回归测试（3）用户测试结合一个例子，作者讲解了这三类软件测试的概念和区别。
作者针对之前提到的软件测试，介绍微软发明的一套用于程序性能的工具：在微软VisualStudio中选择Tools->PerformanceTools->PerformanceWizard，可以进行两种方式的效能分析：抽样（Sampling）和代码注入（Instrumentation）。并且针对一个具体的程序，统计词频的程序，来讲解如何用这两种方法来进行分析和性能改进。而后，作者又强调：虽然优化很重要，但是如果我们不经分析就盲目优化，也许只会事倍功半。
然后作者又指出了目前在高校中，软件设计作业的局限性。就是无法体现出真正的软件工程。师生们身处轰轰烈烈的软件产业大环境，但是在软件工程课上做的题目却是非常简陋，没有起到应有的作用，这的确是一件很有讽刺意义的事情。作者指出目前软件工程课一个基本的作业“图书馆信息系统”存在着很多问题，并由此对需求进行扩展，指出：（1）从数据方面扩展（2）从需求方面扩展（3）从用户方面扩展（4）从软件构建方面扩展等等，指出在开发软件时需要考虑的各种扩展因素。
最后，在本章最后，作者布置了一个作业，实现一个类似wc.exe（代码行统计）的软件作业。并且在布置作业时，非常具体的指出了这个作业的：基本功能，扩展功能，高级功能。然后，希望学生们按照之前讲的PSP，来记录在完成这个作业的过程中，是如何体会软件工程的各个组成部分的。最后，又指出如何来测试自己所完成作业的质量。
接下来作者提出了软件工程师的一些思维误区：（1）分析麻痹；（2）不分主次，想解决所有依赖问题；（3）过早优化；（4）过早扩大化/泛化（PrematureGeneralization）——画扇画，调侃目标和远景。
接下来作者提出了软件工程师的职业发展，指出了专和精的关系，职业成长，自我评估。
本章的最后，作者还是对大家比较熟悉的魔方，来描述不同的精通程度，相对应的魔方的技能。那么作者如何考察一个“精通”魔方的面试者呢：（1）给面试者一个打乱颜色的魔方；（2）要求他把六面还原；（3）如果还原了，要求他把魔方恢复成面试官最初给他的那个混乱的局面，必须一模一样。
这部分主要分为两个部分的内容。前半部分63～67页，是作者针对前面的章节提出的一些课后思考题，诸如：（1）选哪一种医生；（2）软件开发到底是工程，还是艺术；（3）绞刑架和职业发展的故事；（4）针对案例，在博客中撰写观点；（5）成长和代码量的关系；（6）学什么，怎么学，核心竞争力是什么？（7）各式各样的工程师；（8）对职业梯子的思考；等等。
接下来是新的一章：第4章两人合作这章主要讲述了代码规范，极限编程，结对编程等概念，以及代码复审的重要概念。并且详尽地列出了代码规范的一些要求，以及为什么要进行代码审查，如何进行代码审查。这些都和自己平时的工作有密切的联系，受益匪浅。
本段依然承接上述，关于代码复审进行描述，包括代码复审的步骤和核查表。代码复审的核查表包括：（1）概要部分（2）设计规范部分（3）代码规范部分（4）具体代码部分（5）效能（6）可读性（7）可测试性
接下来讲述了结对编程，描述了结对编码产生的原因，方式。在关于两人结对编程时，两个人之间如何正确地进行反馈时，作者指出当一个人对另一个人的行为进行反馈时，有三个层次：（1）最外层：行为和后果；（2）中间层：习惯和动机；（3）最内层：本质和固有属性。
在接下来的练习与讨论中，有关于代码审查的讨论，值得深思。
本章的标题为《团队和流程》。主要讲解了团队，软件团队模式，开发流程。开发流程是每一个成熟的软件团队，都必须要制定和遵守的。其中比较著名的开发流程有：（1）瀑布模型（WaterfallModel）（2）瀑布模型的各种变形（3）统一流程（RationalUnifiedProcess,RUP）（4）渐进交付流程（EvolutionaryDelivery），包括MVP和MBPMVP（MinimumViableProduct,最小可行产品），如互联网公司快速迭代的产品。MBP（MaximalBeautifulProduct,最强最美产品），如iPhone,iPad等。
最后介绍TSP（TeamSoftwareProcess）的一些原则。
本部分是第6章《敏捷流程》，主要讲解敏捷的流程简介，问题和解法，敏捷的团队和敏捷总结。
敏捷流程的问题和解法针对上面提到的敏捷流程的四个步骤，每个步骤中都会有一些可能出现的问题。作者结合案例都给予了总结和分析。
敏捷团队敏捷能成功实施的关键在于Scrummaster.敏捷对团队的要求：（1）自主管理（Self-managing）（2）自我组织（Self-organization）（3）多功能型（Cross-functional）
敏捷总结作者提出一些思考：敏捷是很特别的吗？敏捷流程的经验和教训，以及关于敏捷的问答。
本部分为第7章《实战中的软件工程》。作者指出，前面的章节介绍了软件开发的各种方法论以及一些原则和宣言。宣言令人激动，但不能代替软件，用户不会看了宣言就掏钱买软件。因此，作者介绍世界上最大的软件公司——微软公司的方法论——微软解决方案框架（MicrosoftSolutionFramework,MSF）。
针对每一个原则，作者都采用问答的方式，来介绍这个原则的具体含义，以及在现实中会遇到的实际问题。
接下来作者介绍了：MSF团队模型MSF过程模型
最后作者用微软创业时的实例，讲述了微软的这套框架是如何根据公司的实际情况，从无到有的（MS的软件开发流程的演进）。
本部分是系列的第8章《需求分析》。作者在这章主要讲解了：
今天读的是关于需求分析的前4部分。8.1软件需求软件团队如何才能准确而全面地找到用户的需求呢？（1）获取和引导需求（2）分析和定义需求（3）验证需求（4）在软件产品的生命周期中管理需求
软件的需求，也可以从其他角度来划分，如：（1）对产品功能性的需求（2）对产品开发过程的需求（3）非功能性需求（4）综合需求
8.3获取用户需求——用户调研本节作者介绍了几种，用于用户调研的方法。
8.4竞争性需求分析的框架NABCD是一个有效的方法。N（Need,需求）A,Approach,方法B，Benefit,好处C，Competitors，竞争D，Delivery，推广
本部分是接上一天的内容，继续介绍需求分析的四个点。8.5功能的定位和优先级（1）杀手功能/外围功能（2）必要需求/辅助需求作者用四个象限的方法，指出每一组组合，软件团队应该采取的措施和态度去应对这些需求。
8.6计划和估计（1）目标、估计和决心（2）找出估计后面的假设（3）提高估计能力的招数
8.7分而治之WBS，通常从最终的产品开始，一层一层往下，把大型交付件分割为小型、具体的交付件。WBS的基本原则如下：（1）保证所有的子节点覆盖了全部父节点包含的内容（2）保证各个子节点不要相互覆盖（3）叶子节点要保证足够小，能在一个里程碑中完成（4）从结果出发构建WBS，而不是从团队的活动出发
本部分开始第9章《项目经理》。PM有几种分类。ProductManagerProjectManagerProgramManager
PM的核心要求是：根据市场和用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化产品。
作者接下来介绍了微软PM的来历。主要是解决：交流成本问题开发和测试搞不定的事情
PM做开发和测试之外的所有事情
成为合格的PM，需要具备的能力：（1）观察、理解和快速学习的能力（2）分析管理能力（3）一定的专业能力（4）自省的能力
PM的领导力——高效的团队讨论
本节阅读主要分为两个部分。第一部分是接着昨天的阅读，关于PM的领导力——高效的团队讨论的介绍。
组织会议的人应该做到：（1）明确会议目的，要解决的问题是什么；（2）推动会议进程，促使与会者在每一个阶段做合适的事情；（3）总结会议，记录要点。
会议的思维活动包括：（1）理清事实（2）表达直觉和感情（3）从乐观的角度分析问题（4）从悲观的角度分析问题（5）从创意角度去分析问题
9.5PM和风险管理PM要在整个项目的生命周期管理风险。对于软件项目来说，风险是在正常软件生命周期事件之外的，可能发生的影响项目的成功的事件。
风险管理的几个层次：第一层次：啊呀！大问题（Crisis!）第二层次：缓和并防止问题第三层次：预计（Anticipation）第四层次：把问题变为机会（Opportunity）
接下来是第10章典型用户和场景
该章主要分为：
本节续前一天的章节，主要讲述了典型用户到场景的部分。（4）从典型用户到场景典型用户和他要达到的目标要相互对应。对于每一个目标，列出达到目标所必须经历的过程，这就是场景。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。银行从业者的一次经历，体会本行“ATM无卡取现”功能的强大：特意带上手机和令牌，不带银行卡，感受一下我行ATM的无卡取现，结果连自助银行的门儿都没进去，不刷卡怎么开门啊......
（5）明确了场景的概念后，接下来由架构设计师和各个模块的负责人一起，沿着子系统/模块的所属关系把场景划分开。不同的任务将会把一个场景编织起来，虽然有多个开发者参与这项工作，但是应该有一个开发者对整个场景负责。得到开发任务后，就可以创建和分配测试任务。
10.2用例（UseCase）用例也是很常用的需求分析工具。用例的基本构成元素：（1）标题（2）角色（3）主要成功场景（4）扩展场景
10.3.2功能说明书的模板
10.4功能驱动的设计如何才能把用户的需求变成团队成员可以直接操作的开发工作，然后源源不断地实现这些需求？功能驱动的设计（FeatureDrivenDesign,FDD）是一种方法。该方法论的原则如下：第一步，构造总体模型第二步，构造功能列表第三步，制定开发计划第四步，功能设计阶段第五步，实现具体功能
本次阅读开始新的章节，第11章，软件设计与实现11.1分析和设计方法11.2图形建模和分析方法11.3其他设计方法11.4从Spec到实现11.5开发阶段的日常管理11.6实战中的源代码管理11.7代码完成
以下依次进行介绍：11.1分析和设计方法写软件是为了解决用户的需求，整个软件开发周期我们需要表达、传递和处理下面的这些信息：（1）需求分析阶段：在问题领域的现实世界里，都有哪些实体，如何抽象出我们真正关心的属性，实体之间的关系是什么，在这个基础上，用户的需求是什么，软件如何解决用户的需求。（2）设计与实现阶段：软件是怎么解决需求的？现实世界的实体和属性在软件系统中是怎么表现和交换信息的？（3）测试和发布阶段：软件真的解决了用户需求了吗？软件解决需求时候的效率如何？用户还有什么新需求？
11.2图形建模和分析方法我们要给事物建造出一个“模型”，描述事物、事物的属性、事物之间的关系（静态的）以及各个事物之间的信息传递（动态的）。11.2.1表达实体和实体之间的关系11.2.2表达数据的流动11.2.3表达控制流11.2.4统一的表达方式
11.5开发阶段的日常管理11.5.1闭门造车11.5.2每日构建（DailyBuild）11.5.3构建大师11.5.4宽严皆误11.5.5小强地狱小强地狱——让Bug多的队员专心修复Bug，不要开发新功能。
本次阅读紧接着昨天的阅读。11.6源代码管理软件工程的质量要靠软件工具和软件流程来保证。软件的源代码管理工具，加上构建系统，能保证一个复杂软件在多个角色、多个团队的合作下，按时以合适的质量发布。如果你写一个HelloWorld程序，当然不需要这些工具，就像你用儿童积木搭房子过家家那样，但这不是建筑工程。
接下来开始全新的一章，第12章，用户体验
12.1用户体验的要素12.1.1用户的第一印象用5W1H来衡量用户体验：WhoWhenWhereWhatWhyHow
12.1.2从用户的角度考虑问题12.1.3软件服务始终都要记住用户的选择长期使用之后，软件会更好用么？a.软件用得越多，一样难用b.软件用得越多，越发难用c.软件用得越多，越来越好用
12.1.4短期刺激和长期影响12.1.5不要让用户犯简单的错误12.1.6用户体验和质量12.1.7情感设计
本节继续昨天的讲解，用户体验
12.2用户体验设计的步骤和目标用户体验设计的一个重要目的就是要降低用户的认知阻力，即用户对于软件界面的认知和实际结果的差异。用户体验设计的步骤：（1）概要设计（2）行为（交互）设计（3）界面设计
12.3评价标准（1）尽快提供可感触的反馈（2）系统界面符合用户的现实惯例（3）用户有控制权（4）一致性和标准化（5）适合各类型的用户（6）帮助用户识别、诊断并修复错误（7）有必要的提示和帮助文档
12.4贯穿多种设备的用户体验
接下来进入全新的一章，第13章软件测试13.1基本名词解释及分类BugTestCaseTestSuite
Bug可以分解为：症状程序错误根本原因
13.1.1按测试设计的方法分类黑箱和白箱测试
13.1.2按测试的目的分类
13.1.3按测试的时机和作用分类
13.2各种测试方法13.2.1单元测试和代码覆盖率测试13.2.2构建验证测试13.2.3验收测试13.2.4探索式的测试13.2.5回归测试13.2.6场景/集成/系统测试13.2.7伙伴测试13.2.8效能测试13.2.9压力测试13.2.10内部/外部公开测试（Alpha/BetaTest）13.2.11易用性测试13.2.12小强大扫荡
现在是11月27日了。虽然上周末已经终于把这本书看完了，但还是无法保证及时地把内容摘要记录下来。看来一件事，要坚持一个月不动摇，还真的是很难的呀。
这节还是接上一次内容，主要讲解了测试的知识。包括：上一节提到的13.2.5～13.2.12的全部内容。
关于13.2.6的场景/集成/系统测试：在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，各方面均能满足用户的需求。这类测试叫系统/集成测试。（我之前在公司的时候，还给新同事进行过类似的培训，关于单元测试，集成测试，验收测试的区别）
但是作者在这里提到一个疑问——那到底应该什么时候做集成测试呢？是不是越早越好？答：原则上是当一个模块稳定的时候，就可以把它集成到系统中，和整个系统一起进行测试。在模块本身稳定之前就提早做集成测试，可能会报出很多bug。但是这些由于提早测试而发现的Bug，有点像汽车司机在等待绿灯时不耐烦而拼命地按喇叭——也就是说，有点像噪音。所以，测试也需要把握时机。
关于13.2.8效能测试用户使用软件，不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平。软件的效能是这些“非功能需求”或者“服务质量需求”的一部分。以下的概念包括：设计负载：首先要定义什么是正常的设计负载。从需求说明出发，可得出系统正常的设计负载。令用户满意的服务质量
设计负载的细化服务质量的细化（现实的静态数据，现实的动态数据）
关于13.2.9压力测试压力测试严格地说不属于效能测试。压力测试要验证的问题是：软件在超过设计负载的情况下，是否仍能返回正常结果，没有产生严重的副作用或奔溃。
在测试的时候，如何增加负载呢？可以从以下两个方面来考虑：
13.3实战中的测试13.3.1似是而非的测试观念13.3.2测试工作中的文档（1）测试设计说明书（TDS）（2）测试用例（TestCase）a.等价类划分b.边界值分析c.决策表、因果图和功能图方法d.pair-wise和正交实验设计方法（3）错误报告（4）测试修复，关闭缺陷报告（5）测试报告
备注：不同的角色在开发过程中有相互合作，相互制约的作用，不能替代．测试人员在做验证测试时，需要做多方面，多平台的测试，这些工作量，也许远远超过了开发人员的能力范围．因此，必须要由测试人员来验证并处理已经修理好的bug．
接下来开始新的一章：第１４章质量保障记住如下的公式：软件（质量）＝程序（质量）＋软件工程（质量）程序的质量体现在软件外在功能的质量．软件工程的质量，则体现在如下方面：（１）软件开发过程的可见性（２）软件开发过程的风险控制（３）软件内部模块，项目中间阶段的交付质量，项目管理工具的因素（４）软件开发成本的控制（５）内部质量指标的完成情况
１4.1.3软件工程的质量如何衡量一个比较成熟的理论是ＣＭＭＩ：ＣapacityMaturityModelIntegrated,能力成熟度模型集成．ＣＭＭＩ总共分为五级．初始级，管理级，明确（定义）级，量化管理级，优化级．ＣＭＭＩ有两种不同的实施方法，其级别表示不同的内容：（１）连续式：主要是衡量一个企业在某一项目中的管理能力（２）阶段式：主要是衡量一个企业的成熟度．
１4.1.4质量的成本预防评审内部故障外部故障流程分析改进提高职业技能技术投资
１４.2软件的质量保障工作要注意软件测试和软件质量保障的区别．软件测试：运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作流程和结果通常是可量化的．正因为流程和结果是明确定义的，可量化的，所以很多测试工作可以自动化．软件质量保障：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试活动．
问题2盲目信任“专业人士”扮演的角色每个角色的水平不一样，水平最差的角色往往对软件质量的影响最大。
问题3为了自己的角色而做绩效优化分工之后，每个角色为了自己的绩效而优化，会出现局部最优而全局未必最优的情况。
问题4画地为牢的分工有时分工链条过长，信息丢失。一个开发者对自己写的程序有什么潜在问题还是很有感觉的，有些问题可以用文字表述出来（如果开发人员有耐心的话），有些问题是一些预感......现在都交给测试人员了，那么，让他们测吧，我也懒得说了。
分工还可能会导致一个软件的灵魂被切碎分割各个角色，每个功能都做得很卖力，但是整体就是不行，明显看出来是费了老大的劲给强行“集成”起来的。
问题5无明确责任的分工
这一节继续上面的关于软件质量保障的章节。
“快速重现用户报过的bug”，这是专业测试人员的价值所在。没有测试人员之后，开发人员并没有负责这个新的任务，他们的主要目标还是“快速开发功能”。针对bug的修复，也要一级一级地发出去，增加很多成本。还是那句话，没有责任，就没有质量。
第15章稳定和发布阶段
15.1从代码完成到发布软件生命周期的最后阶段往往是最考验团队的，不但考验团队项目管理水平、应变能力，也考验团队的“血型”。A型：他们知道优秀的软件公司会发布有已知缺陷的软件B型：他们不相信这一点O型：他们不知道这一点，因此嘴巴惊讶成O型AB型：他们对于自己开发的软件是A型，对于别人开发的软件是B型
做商用软件的人都在为此苦恼，只有优秀的软件公司能找到一个平衡点，及时发布能够解决用户问题的软件，并且能及时修改软件中的问题。
15.1.1会诊小组软件团队的各个角色代表（PM/Dev/Test/UX等）组成了会诊小组，处理每一个影响产品发布的问题。对于每一个bug，会诊小组要决定采取下面哪一种行动：（1）修复（2）设计本来如此（3）不修复（4）推迟
15.1.2复杂项目的会诊在项目稳定阶段的初期，团队只要决定需要修复哪些缺陷，然后团队成员就会进行必要的设计、实现、测试工作，并签入代码修改。但是，随着项目进展和发布日期的临近，团队还要保证修改方案不会给产品带来负面的影响。这时，会诊会议也会有更高的要求，包括以下三个方面：第一步，开发者提交参加会诊的bug和修改方案；第二步，会议决定是否同意修改方案；第三步，执行。
项目接近尾声时，要确保门槛越来越高。提升门槛是放走一些无伤大雅的bug，换取项目能如期完成。其指导思想是抓大放小，既然没法全解决，就集中精力解决最重要的bug。避免频繁地到处改动代码而引入新的bug，是以谓之”稳定“。
15.1.3招数：设计变更（DesignChangeRequest）要分清楚重构和重写的区别：重构——在尽量保持原有界面的基础上优化部门代码；重写——重新实现原有功能，同时，要分清是全部重写原有功能，还是偷偷加上许多新的功能。
要记住，项目的当前阶段是一个阻尼振荡的过程，要收敛和稳定。等到下一个版本开始的时候再进行发散的思考吧。
本节继续前面的介绍。
15.1.4招数：ZBB团队要有把Bug都搞定的执行力。ZBB=ZeroBugBuild,即这一版本的构建把所有已知的Bug都解决掉了。
15.1.5招数：最后回归测试项目临近结束时，所有人员（开发、管理、测试）都要回归测试所有的bug。每个人都要帮助团队确保这些Bug的确是被修复了，而且别的更改没有导致功能的”回归“。
15.1.6招数：砍掉功能软件的三个目标：快、便宜、好。一般团队只能达到三个目标中的两个。