《构建之法》读书笔记——第11章 软件设计与实现

第11章 软件设计与实现

11.1 分析和设计方法

l  以文字为主的文档，如Word、PowerPoint文档。

l  用图形为主构造的模型，如MindMap，ERD，DFD，UML的各种图，甚至包括Flow Chart流程图

l  用数学语言的描述，如ViennaDevelopment Method

l  用类自然语言+代码构造的描述，如LiterateProgramming

l  源代码加注释也能描述

11.2 图形建模和分析方法

11.2.1 表达实体和实体之间的关系（Entity Relationship Diagram，Entity RelationshModel，Mind Map）

实体关系图

 

11.2.2 表达数据的流动（Data Flow Diagram）

11.2.3 表达控制流（Flow Chart，Finite State Machine）

略。

11.2.4 统一的表达方式（Unified Modeling Language， UML）

各种图示建模方法的大致特定

各种分析建模方法	从结构化数据的角度看	从面向对象的角度看	从控制的角度看
强调静态	ERD	Class Diagram
强调动态、交互	DFD、UCD、Activity Diagram	Sequence Diagram	FSM, Flow Chart，UML State Machine

 

11.3 其他设计方法

略

11.4 从Spec到实现

         1.估计开发任务所需的时间，他会参考以前同类任务所需花费的实际时间，以及其他同事的时间估计。

         2.小飞会试着写一些快速原型的代码，看看效果会怎样。期间他发现了若干问题，与PM沟通后，最终达成一致意见。

         3.在看到初始效果和了解了实现的细节后，小飞开始写设计文档（Technical Spec、Design Document），写好之后，他可以请同事一起来复审设计文档。

         4.设计文档写好后，小飞就会按照设计文档写代码。在实现过程中，他又发现了一些意想不到的问题，与PM沟通后，找到了解决方案。

         5.写好代码后，小飞对照设计文档和代码指南进行自我复审，重构代码。

         6.创建或更新单元测试。

         7.进行单元测试（不仅要自己创建或更新单元测试，还要通过整个模块/系统的单元测试）。

         8.得到一个可以测试的版本，交给相关的测试人员进行测试，或者在网上进行某种公开测试，如A/B测试等。

         9.修复测试人员或用户发现的问题，等到问题都解决得差不多了，就请同事进行代码复审。

         10.根据代码复审的意见修改代码，完善单元测试和其他相关文档，然后把代码嵌入到代码库中。

11.4.1 把修改集集成到代码库中

         1.根据场景和开发任务来决定集成的次序

         2.互相依赖的任务要一起集成

         3.在测试场景时，要保证端到端的测试

         4.场景的所有者必须保证场景完全通过测试，然后把场景的状态改为“解决”

11.4.2 开发人员的标准工作流程

11.4.3 代码完成（Code Complete）

代码完成就是指工程师认为所有应该写的代码都写完了，所有应该实现的功能都实现了（但未必没有问题）。

11.5 开发阶段的日常管理

11.5.1 闭门造车（Leave Me Alone）

当场景、功能都计划好的时候，要给员工足够多的时间，让他们投入到工作中去，而不要经常打断他们。

11.5.2 每日构建（Daily Build）

在我们的全球调查中，我们发现成功公司中有94%每天或至少每周完成构建，而不成功公司绝大多数每月甚至更少去做构建……当有一个能运行的系统时，即使只是一个简单的系统，（团队的）积极性也会上升。

11.5.3 构建大师

构建大师做下面的事：

         1.负责管理构建服务器

         2.调试构建，负责找错，并分析出错的原因。

         3.负责把“构建大师”称号和责任交给下一个导致构建失败的成员。

11.5.4 宽严皆误

不审势即宽严皆误，从来治蜀要深思。

11.5.5 小强地狱（Bug Hell）

11.6 练习与讨论