- Published on
代码大全读书笔记
- Authors
- Name
- hpoenixf
软件构建
软件开发中的活动
- 定义问题
- 需求分析
- 规划构建
- 软件架构
- 详细设计
- 编码和调试
- 单元测试
- 集成测试
- 集成
- 系统测试
- 保障维护 构建活动主要关注编码调试，也包括详细设计，单元测试，集成测试，集成，规划构建。
具体任务
- 验证基础工作已经完成
- 确定如何测试代码
- 设计和编写类和子程序
- 创建并命名变量和常量
- 选择控制结构，组织语句块
- 测试，排错
- 代码审核
- 代码格式化和注释
- 将软件组件集成为一体
- 优化代码 构建活动是软件开发的主要组成部分，核心部分，是唯一确保会完成的工作。
用隐喻来更充分理解软件开发
通过类比把不理解的东西和较理解的东西进行比较，这种使用隐喻的方法叫做建模。 隐喻更像探照灯，告诉你该如何去寻找答案，更像启示，而不是算法。具有偶然性。
编程跟写作不一样，编程是多人的，鼓励复用的。 跟耕作不一样，过程是可控的，是增量式开发。 跟建造比较相同。需要计划，准备，执行。预先规划，调整需要成本，需要审核，使用现成的东西。
前期准备
前期准备可以明确方向，减少犯错的成本。
开始构建前，需要
定义问题
避免浪费时间在解决错误的问题。从使用者的角度描述问题。
确定需求
避免争论与设计上的修改。在需求错误在后续的阶段再发现的话，解决他会需要很大的成本。可以使用下面的方法来应对需求的变更。使用需求核对表来评估需求、确保每个人都知道需求变更的代价、建立需求变更程序、使用能适应变更的开发方法，如演进交互、放弃项目、注意项目的商业案例。
架构
程序组织。架构应该定义程序的主要构造块，明确各构造块的功能，令其负责某一个区域的事情，互相配合而不冲突。
主要的类。架构应该详细定义主要的类，指出各主要的类的责任以及如何与其他类交互。
数据设计。架构应该描述用到的主要文件和数据表的设计。
业务规则。架构应该详细描述业务规则，描述这些规则对系统设计的影响。
用户界面设计。应该在需求或者架构中说明。应该模块化。
资源管理。数据库连接，线程，句柄，内存
安全性。缓冲区的处理，非受信数据(用户输入数据、cookies、配置文件、其他外部输入的数据)的规则，加密，错误消息、保护内存中的秘密数据。
性能。详细定义性能目标
可伸缩性。系统增长以满足未来需求的能力。
互用性。与其他软件或硬件共享数据或资源时需要关心
国际化/本地化。交互系统中需要关心。
输入输出。
错误处理。 纠正还是检测？主动还是被动？如何传播错误？错误处理有什么约定？如何处理异常？在什么层次处理错误？每个类在输入有效性的责任？使用内建的机制还是自己建立一套？
容错性。检测错误、从错误中恢复。常见方法：回退、重试、辅助代码、系统进入功能退化状态、使用表决算法、使用虚假值、
可行性。能否达到性能目标、在有限资源下运转、运行环境是否有足够支持。
过度工程。架构的系统会比需求描述的系统更健壮。
关于买和造的决策。自己定制的组件在什么地方胜过现成的组件
复用的决策。如何对复用的软件进行加工，使其符合其他架构目标。
变更策略。让架构足够灵活，能够适应可能出现的变化。列出有可能增强的功能。
总体质量。优秀的架构规划书应该讨论了系统中的类、讨论了类背后的隐藏信息、讨论了采纳或排斥其他可能的替代方案的理由。应该清楚描述目标。应该描述主要决策的动机。与机器和编程语言无关。应该在对系统描述太少和过度描述之间。应该指出有风险的区域。应该包括多个视角。
核对表
核对表: 需求
a. 是否详细定义了系统的全部输入，包括来源、精度、取值范围、出现频率？
b. 是否详细定义了系统的全部输出
c. 是否详细定义了所有输出格式
d. 是否详细定义了全部外部通信接口
e. 是否列出了用户想要做的全部事情
f. 是否详细定义了每个任务所用的数据及得到的数据
g. 期望响应时间
h. 与计时相关的考虑，如处理时间，数据传输率，系统吞吐量
i. 安全级别
j. 可靠性
k. 机器内存与磁盘空间
i. 可维护性
m. 对成功和失败的定义
核对表：架构
a. 架构的整体组织结构是否清晰，是否有良好架构全局观。
b. 是否明确定义了主要的构造块
c. 是否涵盖了需求中列出的所有功能
d. 是否描述和论证了最关键的类、数据结构、数据设计、数据库的组织结构和内容。
e. 是否指出了关键业务规则及其对系统的影响
f. 是否描述了用户界面的策略、并将其模块化。
g. 是否论证了I/O策略
h. 是否估算了稀缺资源(线程、数据库连接、句柄、网络带宽)的使用量。
i. 是否描述了架构的安全需求。
j. 是否为每个类、子系统、功能域提出空间和时间预算。
k. 是否描述了如何达到可伸缩性
l. 是否关注互操作性
m. 国际化/本地化
n. 错误处理
o. 容错
p. 技术可行性
q. 技术可行性
r. 过度工程的方法
s. 买造策略、加工复用策略
t. 适应未来变更。
u. 是否解决全部需求
v. 有没有那个部分是过度架构或欠架构
w. 架构是否概念上协调
x. 独立于机器和语言
y. 说明了决策的动机
z. 你是否对这个架构感觉良好。
核对表：前期准备
a. 是否辨明了软件的类型
b. 是否充分明确定义了需求，且需求足够稳定，可以开始构建了。
c. 是否充分定义了架构
d. 是否指出项目的风险。
关键的构建决策 选择编程语言 使用熟悉的语言生产效率更高，使用高级语言生产率跟质量更高。
编程约定 变量名称、类的名称、格式约定、注释约定等等
你在技术浪潮中的位置 如果你在技术浪潮的后期，可以计划用大部分的时间稳定持续的写新功能，在前期，可能要花很大部分找出未说明的语言特性，调试错误，修订代码来适应厂商的新版本函数库。深入一种语言去编程。首先决定他要表达的思想是什么，然后决定如何使用特定语言提供的工具来表达思想。大部分重要的编程原则不依赖特定的语言，依赖于你使用语言的方式。
选择主要的构建实践方法
编码
- 多少设计工作将要预先进行，多少在编码时进行
- 有没有名称、注释、代码格式等编码约定
- 有没有编码实践、如何处理错误、安全事项、类接口的约定、重用代码的标准、性能考虑等
- 有没有找到自己在技术浪潮中的位置并调整。
团队工作
- 有没有定义集成工序，程序员把代码check in 到主源码前需要的步骤
- 结对编程还是独自编程还是其他
质量保证
- 是否先写测试用例
- 会写单元测试吗
- check in前会用调试器跟踪代码流程吗
- check in前会继承测试吗
- 会检查别人的代码吗
工具
- 使用哪种版本控制工具
- 使用哪种语言、语言的版本或编译器版本
- 编程框架
- 是否使用非标准的语言特性
- 编辑器、重构工具、调试器、测试框架、语法检查器。