《构建之法，邹欣》阅读笔记

前言：

从2018年10月30日开始，阅读由微软工程师邹欣老师撰写的《构建之法》一书，全书共435页，每天阅读15页，在一个月（30天）完成。每天阅读完成后，需要思考当日的阅读要点和一些思考。
真正让自己感受到积累的效果和伟大！
以下是书的封面：

周序号	Mon	Tue	Web	Thu	Fri	Sat	Sun
第1周		10.30(1~15)	10.31(16~31)	11.01(32~47)	11.02(48~63)	11.03(64~79)	11.04(80~95)
第2周	11.05(96~111)	11.06(112~127)	11.07(128~153)	11.08(154~169)	11.09(170~185)	11.10(186~201)	11.11(202~217)
第3周	11.12(218~233)	11.13(234~249)	11.14(250~269)	11.15(270~285)	11.16(286~301)	11.17(302~317)	11.18(318~333)
第4周	11.19(334~349)	11.20(350~369)	11.21(370~385)	11.22(386~401)	11.23(402~417)	11.24(418~435)

每日打卡阅读和写作：

10月30日打卡：

阅读页码： 1～15页

阅读概要：

今天阅读了《构建之法》的前15页。这一节是整个软件工程的概论，邹欣老师从大家众所周知的一个命题：程序= 数据结构+算法，引出了程序的这一个概念。然后又用一个实际的案例，就是一个家长帮自己的孩子写了一个每天出算术题的小程序，到随着学校老师新提的不断需求，而扩展到一个比较大的系统的软件工程的范畴。引出了一个扩展链：
程序->应用软件->软件服务.
然后又扩展出了整个软件工程的技术名词，包括：
源程序
数据
软件架构
软件设计与实现
源代码管理
配置管理
质量保障
软件测试
需求分析
程序理解
软件维护
服务运营
软件生命周期
项目管理
用户体验
国际化和本地化
软件商业模式
职业道德规范

由此从最原始的公式逐渐推演和扩展：

• 程序= 算法 + 数据结构
• 软件= 程序 + 软件工程
• 软件企业= 软件 + 商业模式

由此得出一个结论：程序（算法，数据结构）是基本功，但是在算法和数据结构之上，软件工程决定了软件的质量；商业模式决定了一个软件企业的成败。软件从业人员和软件企业的道德操守会极大地影响软件用户的利益。

然后，通过类比人类对飞机的发展阶段：从叠纸飞机（玩具阶段），到用气球实现飞屋环游（业余爱好阶段），再到莱特兄弟发明飞机（探索阶段），再到现在的商业大飞机（成熟的产业阶段）。作者指出一个软件的开发阶段也是从简单到复杂的阶段，并且进行了对比，指出在每一个阶段如果成功或失败，会引起的不同结果。

在大家对软件工程有了一个模糊的印象后，作者用专业化的定义对软件工程做了定义。同时又指出了软件的特殊性。
然后针对目前全国各大高校，开的与计算机和软件相关的专业，指出了这些专业在培养侧重点方面的区别。

通过这一天的阅读，对软件工程的了解，也从原来的模糊逐渐到清晰。而作为身在其中的工程人员，也清楚了自己在整个软件工程中的定位，其中的很多词汇也都是平时自己工作中耳熟能详的。
期待明天的继续阅读！

10月31日打卡：

阅读页码： 16～31页

阅读概要：

作者之前已经对计算机和软件工程进行了一个大致的描述，相信读者已经跃跃欲试了。然而，作者给大家提了一个醒，就是关于如何去衡量一个软件是否合格的标准或评价。那就是软件测试了！
接下来作者讲解了软件测试的概念和一些分类。
软件测试的概念：

软件测试的分类：
（1）单元测试
（2）回归测试
（3）用户测试
结合一个例子，作者讲解了这三类软件测试的概念和区别。

11月01日打卡：

阅读页码： 32～47页

阅读概要：

作者针对之前提到的软件测试，介绍微软发明的一套用于程序性能的工具：
在微软Visual Studio中选择Tools->Performance Tools->Performance Wizard，可以进行两种方式的效能分析：抽样（Sampling）和代码注入（Instrumentation）。
并且针对一个具体的程序，统计词频的程序，来讲解如何用这两种方法来进行分析和性能改进。而后，作者又强调：虽然优化很重要，但是如果我们不经分析就盲目优化，也许只会事倍功半。

然后作者开始讲述软件的个人开发流程，有CMMI（软件能力成熟度模型）和PSP（Personal Software Process），主要讲解后者对软件开发流程的分配。
并且对大四学生和工作三年的软件开发工程师，针对PSP这套模型，得出了一个时间分配的对比表格。根据对比得出一个结论：
工程师在“需求分析”和“测试”这两方面要花更多的时间（多60%以上）；但是在具体编码上，工程师比学生要少花1/3的时间。从学生到程序员，并不是更加没完没了地写程序。

然后作者又指出了目前在高校中，软件设计作业的局限性。就是无法体现出真正的软件工程。
师生们身处轰轰烈烈的软件产业大环境，但是在软件工程课上做的题目却是非常简陋，没有起到应有的作用，这的确是一件很有讽刺意义的事情。
作者指出目前软件工程课一个基本的作业“图书馆信息系统”存在着很多问题，并由此对需求进行扩展，指出：
（1）从数据方面扩展
（2）从需求方面扩展
（3）从用户方面扩展
（4）从软件构建方面扩展
等等，指出在开发软件时需要考虑的各种扩展因素。

最后，在本章最后，作者布置了一个作业，实现一个类似wc.exe（代码行统计）的软件作业。并且在布置作业时，非常具体的指出了这个作业的：
基本功能，扩展功能，高级功能。然后，希望学生们按照之前讲的PSP，来记录在完成这个作业的过程中，是如何体会软件工程的各个组成部分的。最后，又指出如何来测试自己所完成作业
的质量。

11月02日打卡：

阅读页码： 48～63页

阅读概要：

今天作者主要讲述的是关于“软件工程师的成长”的话题。相信这个话题也是所有身处这个行业的工程师们最关注的。
要衡量一个软件工程师的能力，那么必须设计一定的衡量指标。就像衡量一个NBA的职业运动员，或者是一个俱乐部的足球运动员，有很多的衡量指标一样，软件工程师也是有很多的衡量指标的。
作者指出，软件项目的确需要创造性，需要一些意外，一些惊喜。但是，更多的是常规的、可重复的任务。一个成熟的软件工程师应该能够降低任务交付时间的标准方差。如果你能长时间稳定而按时地交付工作的结果，内部和外部的顾客就会对你的工作有信心，更喜欢与你合作。
作者讲述了团队对个人的一些期望点。与PSP想对应的一个概念是TSP（Team Software Process），TSP对团队成员的要求如下：
（1）有效的交流；
（2）说到做到，按时交付；
（3）接受团队赋予的角色并按角色要求工作；
（4）全力投入团队的活动；
（5）按照团队流程的要求工作；
（6）时刻做好准备；
（7）理性的工作。
著名的艺术家Chuck Close说：我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续今天的工作，最终你会有所成就。

接下来作者提出了软件工程师的一些思维误区：
（1）分析麻痹；
（2）不分主次，想解决所有依赖问题；
（3）过早优化；
（4）过早扩大化/泛化（Premature Generalization）——画扇画，调侃目标和远景。

接下来作者提出了软件工程师的职业发展，指出了专和精的关系，职业成长，自我评估。

接下来作者根据自己对魔方的真实案例，指出了如何准确地评价自己的能力。并且用一个实际的案例，一个简历上写着是“精通”Visual Studio C#编程的大学生，在进行面试时解决的问题，都是一些最最基本的问题。结果，你发现他把时间都花在“解决（低层次）问题”上了，面试官想考察的“算法技能”、“C#程序设计技能”都无暇顾及。

那怎么提高技能呢？
答案很简单，通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。
作者指出，这正好对应教育理论中的三个区域的理论（舒适区，学习区，恐慌区）。
我们不应该一开始就让自己处于恐慌区，这样会极大的打消自己的学习积极性。而应该选择合适的“学习区”来学习，不断构建自己的舒适区，从而扩展学习区，最后在某些领域达到技能的精通，是一个循序渐进的好办法。

本章的最后，作者还是对大家比较熟悉的魔方，来描述不同的精通程度，相对应的魔方的技能。那么作者如何考察一个“精通”魔方的面试者呢：
（1）给面试者一个打乱颜色的魔方；
（2）要求他把六面还原；
（3）如果还原了，要求他把魔方恢复成面试官最初给他的那个混乱的局面，必须一模一样。

11月03日打卡：

阅读页码： 64～79页

阅读概要：

这部分主要分为两个部分的内容。
前半部分63～67页，是作者针对前面的章节提出的一些课后思考题，诸如：
（1）选哪一种医生；
（2）软件开发到底是工程，还是艺术；
（3）绞刑架和职业发展的故事；
（4）针对案例，在博客中撰写观点；
（5）成长和代码量的关系；
（6）学什么，怎么学，核心竞争力是什么？
（7）各式各样的工程师；
（8）对职业梯子的思考；
等等。

接下来是新的一章：第4章 两人合作
这章主要讲述了代码规范，极限编程，结对编程等概念，以及代码复审的重要概念。
并且详尽地列出了代码规范的一些要求，以及为什么要进行代码审查，如何进行代码审查。
这些都和自己平时的工作有密切的联系，受益匪浅。

11月04日打卡：

阅读页码： 80～95页

阅读概要：

本段依然承接上述，关于代码复审进行描述，包括代码复审的步骤和核查表。
代码复审的核查表包括：
（1）概要部分
（2）设计规范部分
（3）代码规范部分
（4）具体代码部分
（5）效能
（6）可读性
（7）可测试性

接下来讲述了结对编程，描述了结对编码产生的原因，方式。
在关于两人结对编程时，两个人之间如何正确地进行反馈时，作者指出当一个人对另一个人的行为进行反馈时，有三个层次：
（1）最外层：行为和后果；
（2）中间层：习惯和动机；
（3）最内层：本质和固有属性。

在接下来的练习与讨论中，有关于代码审查的讨论，值得深思。

11月05日打卡：

阅读页码： 96～111页

阅读概要：

本章的标题为《团队和流程》。
主要讲解了团队，软件团队模式，开发流程。
开发流程是每一个成熟的软件团队，都必须要制定和遵守的。其中比较著名的开发流程有：
（1）瀑布模型（Waterfall Model）
（2）瀑布模型的各种变形
（3）统一流程（Rational Unified Process, RUP）
（4）渐进交付流程（Evolutionary Delivery），包括MVP和MBP
MVP （Minimum Viable Product, 最小可行产品）， 如互联网公司快速迭代的产品。
MBP（Maximal Beautiful Product, 最强最美产品），如iPhone, iPad等。

最后介绍TSP（Team Software Process）的一些原则。

11月06日打卡：

阅读页码： 112～127页

阅读概要：

本部分是第6章《敏捷流程》，主要讲解敏捷的流程简介，问题和解法，敏捷的团队和敏捷总结。

1. 敏捷的流程简介：
   主要讲解了敏捷的12条原则：主要包括
   （1）尽早并持续地交付有价值的软件以满足顾客需求
   （2）敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
   （3）经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
   （4）业务人员和开发人员在项目开发过程中应该每天共同工作
   （5）以有进取心的人为项目核心，充分支持并信任他们
   （6）面对面的交流始终是最有效的沟通方式
   （7）可用的软件是衡量项目进展的主要指标
   …

敏捷的步骤：
（1）找出完成产品需要做的事情——Product Backlog
（2）决定当前的冲刺（Sprint）需要解决的事情——Sprint Backlog
（3）冲刺
冲刺期间，团队通过每日例会（Scrum meeting）进行面对面的交流。每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时团队要启动每日构建（Continous Integration, CI），让大家每天都能看到一个逐渐完善的版本。
Scrum master根据项目的情况，可以用燃尽图，任务看板等，显示任务完成进度。
冲刺阶段，是以时间驱动的（Time-boxed）。时间一到就结束。
（4）得到软件的一个增量版本，发布给用户。

2. 敏捷流程的问题和解法
   针对上面提到的敏捷流程的四个步骤，每个步骤中都会有一些可能出现的问题。作者结合案例都给予了总结和分析。

3. 敏捷团队
   敏捷能成功实施的关键在于Scrum master.
   敏捷对团队的要求：
   （1）自主管理（Self-managing）
   （2）自我组织（Self-organization）
   （3）多功能型（Cross-functional）

4. 敏捷总结
   作者提出一些思考：
   敏捷是很特别的吗？敏捷流程的经验和教训，以及关于敏捷的问答。

11月07日打卡：

阅读页码： 128～153页

阅读概要：

本部分为第7章《实战中的软件工程》。
作者指出，前面的章节介绍了软件开发的各种方法论以及一些原则和宣言。宣言令人激动，但不能代替软件，用户不会看了宣言就掏钱买软件。
因此，作者介绍世界上最大的软件公司——微软公司的方法论——微软解决方案框架（Microsoft Solution Framework, MSF）。

MSF有9条基本原则：
（1）推动信息共享与沟通
（2）为共同的远景而工作
（3）充分授权和信任
（4）各司其职，对项目共同负责
（5）交付增量的价值
（6）保持敏捷，预期和适应变化
（7）投资质量
（8）学习所有的经验
（9）与顾客合作

针对每一个原则，作者都采用问答的方式，来介绍这个原则的具体含义，以及在现实中会遇到的实际问题。

接下来作者介绍了：
MSF团队模型
MSF过程模型

最后作者用微软创业时的实例，讲述了微软的这套框架是如何根据公司的实际情况，从无到有的（MS的软件开发流程的演进）。

11月08日打卡：

阅读页码： 154～169页

阅读概要：

本部分是系列的第8章《需求分析》。
作者在这章主要讲解了：

1. 软件需求
2. 软件产品的利益相关者
3. 获取用户需求——用户调研
4. 竞争性需求分析的框架
5. 功能的定位和优先级
6. 计划和估计
7. 分而治之（Work Breakdown Structure）

今天读的是关于需求分析的前4部分。
8.1 软件需求
软件团队如何才能准确而全面地找到用户的需求呢？
（1）获取和引导需求
（2）分析和定义需求
（3）验证需求
（4）在软件产品的生命周期中管理需求

软件的需求，也可以从其他角度来划分，如：
（1）对产品功能性的需求
（2）对产品开发过程的需求
（3）非功能性需求
（4）综合需求

8.2 软件产品的利益相关者
软件团队在分析软件需求时，需要考虑如下这些利益相关者：
用户（User, End-user）
顾客（Customer, Client），这些人不一定是软件的直接用户
市场分析者
监管机构
系统/应用集成商
软件团队
软件工程师

8.3 获取用户需求——用户调研
本节作者介绍了几种，用于用户调研的方法。

8.4 竞争性需求分析的框架
NABCD是一个有效的方法。
N（Need, 需求）
A, Approach, 方法
B，Benefit, 好处
C，Competitors，竞争
D，Delivery，推广

11月09日打卡：

阅读页码： 170～185页

阅读概要：

本部分是接上一天的内容，继续介绍需求分析的四个点。
8.5 功能的定位和优先级
（1）杀手功能/外围功能
（2）必要需求/辅助需求
作者用四个象限的方法，指出每一组组合，软件团队应该采取的措施和态度去应对这些需求。

8.6 计划和估计
（1）目标、估计和决心
（2）找出估计后面的假设
（3）提高估计能力的招数

8.7 分而治之
WBS，通常从最终的产品开始，一层一层往下，把大型交付件分割为小型、具体的交付件。
WBS的基本原则如下：
（1）保证所有的子节点覆盖了全部父节点包含的内容
（2）保证各个子节点不要相互覆盖
（3）叶子节点要保证足够小，能在一个里程碑中完成
（4）从结果出发构建WBS，而不是从团队的活动出发

11月10日打卡：

阅读页码： 186～201页

阅读概要：

本部分开始第9章《项目经理》。
PM有几种分类。
Product Manager
Project Manager
Program Manager

PM的核心要求是：根据市场和用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化产品。

作者接下来介绍了微软PM 的来历。
主要是解决：
交流成本问题
开发和测试搞不定的事情

PM做开发和测试之外的所有事情

成为合格的PM，需要具备的能力：
（1）观察、理解和快速学习的能力
（2）分析管理能力
（3）一定的专业能力
（4）自省的能力

PM的领导力——高效的团队讨论

11月11日打卡：

阅读页码： 202～217页

阅读概要：