< 构建之法 -- 现代软件工程 > 读书笔记
Table of Contents

构建之法

一本不错的软件工程教材，实际从事过软件开发后再读，很多东西就是日常的工作行为规范，本书没有大段大段的概念定义，而是用对话、场景和例子来介绍，读起来也很有趣。

印象比较深的点：

前言

关于学习：

  1. 知识体系是构建出来的，不是接收到的。
  2. 人的认知模型改变得非常缓慢。
  3. 提问能帮助构建知识体系。
  4. 身心投入是学习的关键。

ch1 概论

程序 = 数据结构 + 算法

软件 = 程序 + 软件工程

软件企业 = 软件 + 商业模式

软件开发的不同阶段：

玩具阶段 → 业余爱好阶段 → 探索阶段 → 成熟的产业阶段

软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。

ch2 个人技术和流程

PSP（Personal Software Process）。

如何让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？-- 单元测试。

好的单元测试的标准：

回归测试：

个人开发流程，以 PSP 2.1 为例：

“开发” 不仅仅是写代码。

ch3 软件工程师的成长

一个问题：软件工程师如何衡量和证明自己的能力？类比篮球运动员，用数据展示是最直观的。

初级软件工程师的成长包括以下几种：

  1. 积累软件开发相关的知识，提升技术技能（如对具体技术的掌握，动手能力）。例如：对JAVA、C/C++、C#的掌握，诊断/提高效能的技术，对设备驱动程序、内核调试器的掌握，对于某一开发平台的掌握
  2. 积累问题领域的知识和经验（例如对医疗或金融行业的了解）
  3. 对通用的软件设计思想和软件工程思想的理解
  4. 提升职业技能（区别于技术技能），包括：自我管理的能力、表达交流的能力、与人合作的能力、按质按量完成任务的执行力
  5. 实际成果——最重要的评价标准

ch4 两人合作

函数的设计：只做一件事，而且要做好。

结对编程：

结对编程对人的心智、道德修养有较高的要求。

结对编程好处：

  1. 在开发层次，可以提供更好的设计质量和代码质量，两人合作解决问题的能力更强。
  2. 对开发人员，带来更多的信心，高质量的产出带来更高的满足感。
  3. 企业管理层次上，有效地交流，相互学习和传递经验，分享知识，取得更高的投入产出比。

Code Review：

除了提前发现错误之外，还能够传授、分享知识和经验。

可以记录一个“我常犯的错误”列表。

ch5 团队和流程

常见软件团队模式：

常见开发流程：

ch6 敏捷流程

敏捷开发原则：

  1. 尽早并持续地交付有价值的软件以满足顾客需求
  2. 敏捷流程欢迎需求的变化，并利用这些变化来提高用户的竞争优势
  3. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
  4. 业务人员和开发人员在项目开发过程中应该每天共同工作
  5. 以有进取心的人为项目核心，充分支持信任他们
  6. 无论团队内外，面对面的交流始终是最有效的沟通方式
  7. 可用的软件是衡量项目进展的主要指标
  8. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
  9. 只有不断关注技术和设计，才能越来越敏捷
  10. 保持简明——尽可能简化工作量的技艺
  11. 只有能自我管理的团队才能创造优秀的架构、需求和设计
  12. 时时总结如何提高团队效率并付诸行动

敏捷流程概述：

每日立会（站立会议）：

要追踪任务完成的时间。

敏捷方法为什么有效，可能是“霍桑效应”。

霍桑效应(Hawthorne Effect)：当人们在意识到自己正在被关注或者观察的时候，会刻意去改变一些行为或者是言语表达的效应。

敏捷不是万能的，它只是帮助你更早知道你是否能如期完成任务，仅此而已。

学会估算工作量，这需要不断练习。

ch7 MSF

微软公司中关于软件开发的思想和宣言有一个方法论——微软解决方案框架（Microsoft Solution Framework，MSF），也就是微软推荐的软件开发方法。

  1. 推动信息共享与沟通（Foster open communications）
  2. 为共同的远景而工作（Work toward a shared vision）
  3. 充分授权和信任（Empower team members）
  4. 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
  5. 交付增量的价值（Deliver incremental value）
  6. 保持敏捷，预期和适应变化（Stay agile, expect and adapt change）
  7. 投资质量（Invest in quality）
  8. 学习所有的经验（Learn from all experiences）
  9. 与顾客合作（Partner with internal and external customers）

ch8 需求分析

软件需求

竞争性需求分析的框架 -- NABCD模型

功能的定位和优先级

我们以一个英汉词典软件为例子来说明。

分而治之(Work Breakdown Structure): 通常从最终的产品开始，一层一层往下，把大型交付件（Deliverable）分割为小型、具体的交付件。这样的分割可以持续下去，直到WBS的使用者（开发团队、接收方）达到共识。从数据结构方面来看，WBS分割的结果是一棵树。所有子节点都最终有一个根节点。每个节点描述的是要交付的产品或文档，而不是开发团队的努力或花费（各个叶节点的成本可以作为次节点的属性展现出来）。

ch9 项目经理

软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，我们叫他们项目经理 —— PM

PM 的 M 就是Manager，但是P有这几种：Product Manager、Project Manager、Program Manager，在不同的行业和公司，他们的作用各不相同。接下来介绍的是项目经理——Program Manager

PM 的能力要求和任务：

ch10 典型用户和典型场景

我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。

典型用户只是我们的设想，还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户

有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。

怎么写场景：

如何区分场景：

使用用例（Use Case）：

规格说明书（Spec）：

  1. 软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）
  2. 软件技术说明书（Technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子）

ch11 软件设计与实现

从 Spec 到实现，注意沟通，不要闭门造车。

ch12 用户体验

ch13 软件测试

名词解释：

测试方法：

Ad hoc Test：exploratory test，探索式、随机进行的测试。Ad hoc 原意是特定的、一次性的。

ch14 质量保障

软件（质量） = 程序（质量） + 软件工程（质量）

软件质量的保障工作：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作。

ch15 稳定和发布阶段

设计变更（DCR, Design Change Request）。

发布之后：项目回顾（Postmortem）

有什么历史经验教训？如果重来一遍，我们会做什么改进？

ch16 IT 行业的创新

介绍关于创新的一些迷思。

创新不是灵光乍现的产物。

不是所有人都喜欢创新。

好的想法不一定带来好的创新。

创新者可能会摔得更惨。

创新不需要成为某个领域的专家。

技术创新不一定是最关键的。

黄金点游戏：

N个同学（N通常大于10），每人写一个0~100之间的有理数 (不包括0或100)，交给裁判，裁判算出所有数字的平均值，然后乘以0.618（所谓黄金分割常数），得到G值。提交的数字最靠近G（取绝对值）的同学得到N分，离G最远的同学得到－2分，其他同学得0分。
玩了几天以后，大家发现了一些很有意思的现象，比如黄金点在逐渐地往下移动。

你会想, 如果大家随机报数的话, 0-100 的平均数是50, 50 * 0.618 = 31. 那我就来个 31。

但是其他人也不是傻子, 他们肯定也想到了这一点。如果大家都选 31 附近的数, 那我得选 31*0.618 = 19;

但是这些人肯定也想到了这一点, 那我要选 19 * 0.618 = 12… 然后 12 * 0.618 = 8 …

最后干脆选 0.0001 好了！

0.0001 是正确答案么? 这取决于参与游戏的所有成员。

赢者通吃

这个游戏规定第一名得到全部的分数, 第二名（不管多接近）到倒数第二名都是 0 分，最后一名还要倒扣分。软件行业就是一个赢者通吃的坏境, 最后一名还要把自己的身家倒贴进去。

螳臂当车

在游戏中, 经常有一两个同学逆历史潮流, 提交一个 99.999 之类的分数。但是从大趋势来看, 这些捣乱分子对大局影响不大。我经常看到几个同学面带微笑小声商量，一起提交几个最高分来搅局，但是G-number 还是由大多数人决定。另外不是所有口头同意搅局的同学最后都“守约” 提交了大数字… 这也是“囚徒的困境”的一种。

只先一步

参加游戏的人都是在top N 的大学生, 或者IT 从业人员, 数学足够好, 都是聪明人。我把题目公布之后, 一些人马上就说– 这肯定收敛到0啦！ 他们交上来一个 (0.00001 ) 的答案 (提交的数字必须大于 0 )。遗憾的是, 一起玩游戏的人其他人不这么想。 一个小团体, 或者一个小社会的社会共识 (consensus) 从来不是最激进的, 每个个体发出自己看似随机的声音, 它的进步是缓慢的, 有时还倒退一下。 如果只看微博上的发言, 你会觉得德先生和赛先生早已是国人的共识; 如果只参加最前沿的科技沙龙, 你会觉得明天大家都会用人体嵌入智能芯片同时会同步电子书邮件微博微信SNS再加GPS再有云计算，你如果不推出相应产品就会被淘汰… 但是社会作为一个整体还没有进步得这么快。

ch17 人、绩效和职业道德

RASCI模型

职业道德是工作的基本原则，为了短期利益违反职业道德是得不偿失的。