《构建之法》读书笔记
目录
软件工程的阶段... 1
好的单元测试标准：... 1
代码复审... 2
结对编程... 2
软件开发流程... 3
敏捷流程 Scrum.. 3
MSF. 5
需求分析... 5
典型用户和场景... 6
规格说明书（Spec）--包括 功能说明书和技术说明书(设计文档) 8
用户体验... 9
软件测试... 10
质量保证... 11
关于IT行业的创新... 11
软件工程的阶段
1、 需求分析；
2、 设计阶段；
3、 实现阶段；
4、 稳定阶段；
5、 发布阶段；
6、 维护阶段。
好的单元测试标准：
1、 在最低的功能/参数上验证程序的正确性；
2、 单元测试由最熟悉该程序代码的人来写；
3、 单元测试过后，机器状态保持不变；
4、 测试效率要高；
5、 单元测试应产生可重复、一致的结果；
6、 若程序引用的其它模块比较耗时，可以人为构造数据；
7、 应覆盖所有代码路径；
代码复审
1、 定义：看代码是否在“代码规范”的框架内正确地解决了问题；
2、 方式：自己复审、他人复审；
3、 复审目的：找出错误、发现需要改进的地方、互相学习；
4、 其它复审：设计复审、测试计划复审和文档复审；
结对编程
说明：
一对程序员面对同一个显示器，使用同一个键盘同一个鼠标一起工作，他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等；
好处：
- 两个人合作解决问题的能力更强
- 给开发人员带来更多的信心；
- 更有效地交流，相互学习和传递经验；
软件开发流程
5、 瀑布模型（Waterfall Model）
适用范围：
·产品定义稳定，产品正确性非常重要，需要每一步的验证；
- ·产品模块之间的接口、输入和输出能很好地用形式化的方法定义和验证；
- ·使用的技术非常成熟，团队成员都很熟悉这些技术；
- ·负责各个步骤的子团队不能做到频繁交流；
敏捷流程 Scrum
6、 敏捷开发原则：
- ·尽早并持续地交付有价值的软件以满足顾客需求；
- ·欢迎需求变化，并利用这种变化来提高用户的竞争优势；
- ·经常发布可用的软件，发布时间能短则短；
- ·业务人员和开发人员在项目开发过程中应每天共同工作；
- ·以有进取心的人为项目核心；
- ·面对面交流时最有效的沟通方式；
- ·可用的软件是衡量项目进展的主要目标；
- ·敏捷流程应保持可持续的发展；
- ·保持简明——尽可能简化工作量的技艺；
- ·时时总结如何提高团队效率，并付诸行动；
7、 敏捷开发的步骤：
第一步：找出完成产品需要做的事情（Product Backlog），每一项工作的时间估计为天；
第二步：决定当前冲刺（Sprint）需要解决的事情——Sprint Backlog，将整个产品的实现划分为几个互相联系的冲刺；产品订单上的任务进一步细化，以小时为单位（16小时以内），团队成员根据自身领取任务；
第三步：冲刺（Sprint），冲刺阶段不受外部影响，有任何需求变动都留待冲刺结束后再讨论；
冲刺期间每天开一个‘每日例会’，各成员汇报工作进度，报告下一步计划，以及遇到的问题；
第四步：得到软件的一个增量版本，发布；然后又在此基础上进一步计划增量的新功能和改进；
8、 敏捷开发过程中的问题：
(1) 各个需求和任务之间是有依赖关系的，除了优先级外，怎么在计划中体现依赖关系？
(2) 有些任务需要很长时间做，后面的任务又基于这个耗时任务；
有任务很困难无人认领；
(3) 例会流于形式（改进：定义好任务究竟是什么，记载完成这个任务需要多少时间）；
(4) 代码完成->集成测试->Alpha发布->设计上的BUG修复->代码完成->再测试->检验是否够好了->发布;
9、 适用范围
|
方式 客观因素 |
敏捷（Agile） |
计划驱动(Plan-driven) |
形式化开发方法（Formal Method） |
|
产品可靠性要求 |
容忍经常出错 |
较高 |
极高 |
|
需求变化 |
经常变化 |
不经常 |
固定 |
|
团队人员数量 |
不多 |
较多 |
不多 |
|
人员经验 |
资深人员带队 |
中层技术人员为主 |
资深专家 |
|
公司文化 |
鼓励变化 |
崇尚秩序，按时交付 |
精益求精 |
|
例子 |
微博网站 |
办公软件，商业用户用的软件 |
复杂系统的核心组件，科学计算 |
MSF
10、 基本原则
(1) 推动信息共享与沟通；
(2) 为共同的远景而工作；
(3) 充分授权和信任；
(4) 各司其职，对项目共同负责；
(5) 交付增量的价值；
(6) 保持敏捷，预期和适应变化；
(7) 投资质量；
(8) 学习所有的经验；
(9) 和顾客合作；
需求分析
11、 找准需求的步骤
(1) 获取和引导需求(需求捕捉)；
(2) 分析和定义需求；（定义需求的内涵，需求的量化）；
(3) 验证需求；（验证是否分析准确）；
(4) 在软件生命周期管理需求；（需求会变化，技术会发展）；
12、 获取用户需求：
(1) 焦点小组；（用户代表和项目的利益相关者一起讨论）
(2) 深入面谈；（招募目标用户做试验）
(3) 对需求卡片分类；（讨论->明晰定义->归类->排序）
(4) 用户调查问卷；
(5) 用户日志研究；
(6) 人类学调查；（融入到目标用户当中去）
(7) 快速原型法；（做一个简单的例子或模型给用户，得到反馈）
(8) A/B测试；(用两个不同风格的界面给用户使用，得到反馈)
13、 竞争性需求分析的框架：
(1) Need 需求
(2) Approach 做法
(3) Benefit 好处
(4) Competitors 竞争
(5) Delivery 推广
典型用户和场景
14、 典型用户的模板：
(1) 名字（越自然越好）
(2) 年龄
(3) 收入
(4) 该典型用户的比例和重要性
(5) 使用这个软件的典型场景
(6) 使用本软件/服务的环境
(7) 生活/工作情况
(8) 知识层次和能力
(9) 用户的动机、目的和困难（困难即需要解决的问题）
(10) 用户偏好；
15、 场景
(1) 背景
- ·典型用户；
- ·用户的需求/需要解决的问题；
- ·假设；
(2) 场景
- ·关于这个场景的文字描述。
- ·列出这个故事出彩的地方，软件哪些功能让用户特别满意逻辑和界面设计要注意哪些因素，第一次使用和多次使用的用户在体验上有何区别对待；
- ·其它资料；
规格说明书（Spec）--包括 功能说明书和技术说明书(设计文档)
16、 功能说明书(Functional Spec)模板：
(1) Spec目标是什么，Spec的目标不包括什么；(定义好相关概念)；
(2) Spec的用户和典型场景；
(3) Spec用到了哪些术语，它们的定义是什么？
(4) 用户是如何使用软件的功能的？
(5) 边界条件(比如输入内容的上限和下限，数量变化….)
(6) 功能有什么副作用，对于其它功能有无依赖关系；
17、 功能驱动的设计步骤:
(1) 构造总体模型；
(2) 构造功能列表；
(3) 制定开发计划；
(4) 功能设计阶段；
(5) 实现具体功能；
二、 从Spec到实现步骤：
1、 估计开发任务所需的时间；
2、 写快速原型代码看一下效果；
3、 看到初始效果和了解了实现的细节后，写设计文档；
4、 根据设计文档写代码；
5、 复审、重构、单元测试；
6、 得到一个可以测试的版本；
7、 修复BUG；
8、 签入；
用户体验
1、 要素：
(1) 用户的第一印象
(2) 从用户的角度考虑问题
(3) 记住用户的选择
(4) 短期刺激和长期影响
(5) 不让用户犯简单的错误
(6) 用户体验和质量；
2、 评价用户体验的标准：
(1) 尽快提供可感触的反馈；
(2) 系统界面符合用户的现实惯例；
(3) 用户有自用控制权；
(4) 一致性和标准化；
(5) 适合各种类型的用户；
(6) 帮助用户识别、诊断并修复错误；
(7) 有必要的提示和帮助文档；
软件测试
1、 测试工作中的文档：
(1) 测试计划；
(2) 测试设计说明书；
(3) 测试用例；
(4) 错误报告；
(5) 测试报告；
2、 不同阶段中的测试：
(1) 远景和计划阶段：讨论测试计划和测试设计说明书；
(2) 开发阶段：
开发人员要写单元测试，测试人员写BVT(构建验证测试)；
对每一个成功的构建运行功能测试/场景测试；
功能逐渐完善，进行集成测试，进行非功能性测试(压力、效能、可用性、安全性….)；
(3) 稳定阶段：根据验收标准进行验收测试；Alpha/Beta测试；回归测试；
(4) 发布阶段：把尽可能多的测试用例自动化，为下一个版本测试工作做好准备；
质量保证
1、 软件工程的质量体现：
(1) 软件开发过程的可见性；
(2) 软件开发过程的风险控制；
(3) 软件内部模块，项目中间阶段的交付质量；
(4) 开发成本的控制；
(5) 内部质量指标的完成情况；
关于IT行业的创新
1、 一些似是而非的观点：
(1) 灵光一闪，伟大的创新就紧随其后；
(2) 大家都喜欢创新；
(3) 好的想法会赢；
(4) 创新者都是一马当先；
(5) 要成为领域的专家，才能创新；
(6) 技术的创新是关键；
(7) 成功的团队更能创新；
