[ 一 ] 软件培育
1. 一个有趣的隐喻。
软件开发人员每次设计系统的一小部分、写出一段代码、做一点测试,并将成果一点点添加到整个系统中。人们逐渐为这个“每次做一点”的主意找到了恰当的隐喻——growing(培育)。
2. 要养殖牡蛎吗?
牡蛎制造珍珠的过程逐渐地添加微量的碳酸钙。我们可以用生长这个词描述这个过程。而同样的,在开发软件的过程中,我们要学会如何一次为软件系统增加一个小部分。这就是“系统生长”。与之相关的词汇有“迭代的(iterative)”、“自适应的(adaptive)”以及“演进的(evolutionary)”。这是在描述一种以增量方式进行设计、编译和测试的软件开发概念。
[ 二 ] 软件构建
-
构建意味着什么?
构建就暗示了软件开发不是一蹴而就的,而是存在着多个阶段滴!
具体阶段留待以后分解,现在先略略略。。。 -
作为一个有良心的程序猿(软件开发人员),我们的构造是需要质量滴!
那至少需要满足什么要求呢?可理解性、可维护性、可复用性、健壮性、时空性能;
如果在一个项目的生命周期的前、中、后期都强调质量,那么一个高质量的计划、高效的实践以及系统测试是必不可少的。
[ 三 ] 前期准备
- 你有WIMP综合征吗?
*Why Isn’t Mary Programing?(WIMP)或者Why Isn’t Sam Coding Anything?(WISCA)*为什么Sam不在写代码?很多人控制不住自己写代码的欲望,于是果断的牺牲了前期准备。。。 - 前期准备什么
[ 四 ] 需求变更怎么办?
三十六计走为上,放弃这个项目怎么样?或者使用能适应变更的开发方法。比如演进原型法,利用分阶段交付系统的方法不断的从用户获得反馈。
[ 五 ] 构造的典型组成部分
- 程序组织
明确定义各个构造块的责任。每个构造块应该负责某一个区域的事情,并且对其他构造块负责的区域知道的越少越好。同时应该明确定义每个构造块的通信规则。对于每个构造块,架构应该描述他能直接使用哪些构造块,能间接使用哪些构造块,不能适用哪些构造块。 - 主要的类
架构应该详细定义所用的主要类。它应该指出每个主要的类的责任,以及该类如何与其他类交互。图应该包含对类的继承体系、状态转换、对象持久化等的描述。 - 安全性
实现设计层面和代码层面的安全性的方法。建立威胁模型。 - 错误处理
- 变更策略
在开发过程中产品很可能发生变化。这些变更来自不稳定的数据类型和文件格式、功能需求的变更、新的功能特性等等。这些变更更可能是计划增加新的功能,也可能是没有添加到系统的第一个版本中的功能。因此软件架构是面临的一个主要挑战是,让架构做够灵活,能够适应可能出现的变化。
架构应当清楚的描述处理变更的策略。架构应该列出已经考虑过的有可能会有所增强的功能,并说明“最优可能增强的功能同样是最容易实现的”。
以下是《代码大全》中推荐的书籍:
[ 六 ] Multi-dimensional software views