文章目录
Code
类的实现(理想情况下,还包括完整的单元测试)要按照从耦合度最低到耦合度最高的顺序来完成.
TDD
逻辑就是让人充满信心地得出错误结论的方法
TDD的有点
- 使程序员获得满足感从而更始终如一的坚持编写测试
如果先编写测试,我们会感觉在面前存在具有价值的挑战和问题- 有助于澄清接口和行为的细节
如果你在测试代码中编写了…你就必须要思考方法名称,返回值,参数和行为等公共视图的细节
…
从上面第二条可以看出,在方法声明还未明确的时候就需要单元测试.
需要注意的关键点是,我们没有先为Sale编写所有的单元测试,我们只编写了一个测试方法,在Sale类中实现该方法并确保通过测试,然后再反复这一过程.
创建测试固件
按照约定命名为fixture
通常定义为实例字段而不是局部变量
Refactor
UML蓝图
在建模日之前,使用UML工具进行逆向工程,从代码生成UML图-包,类和交互图.然后,对于感兴趣的部分,用绘图机在大型绘图纸上打印出来.将其挂在建模室墙上比较高的地方,这样在建模日时,开发人员就可以参考这些图形,在上面画草图,同时在它们下面白板或胶片上画草图.
附上书中推荐的一个UML工具列表网站,但是里面的工具都有些老.
继续编码
使用UP的过程成熟的标志是,知道何时创建制品能够带来显著价值,或者是当遇到呆板的"完成作业"式的步骤时能够较好的略过.
准则当有下列情况时,创建超类的概念子类
- 子类具有我们感兴趣的额外属性
- 子类具有我们感兴趣的额外关联
- 对子类概念的影响,处理,反应和操作与超类或其他子类有显著的差异.
准则将超类声明为抽象类
架构分析
定义
架构分析是指在功能性需求的语境中识别和解决非功能性需求
在UP中,架构性因素被记录在补充规格说明(Supplementary Specification)中,解决这些需求的架构性决策被记录在软件架构文档SAD中.UP不是瀑布,因此SAD不是在开始编程之前就完全创建好的.相反,代码稳定之后,架构才完全稳定,这时SAD文档记录了系统的实际情况,可帮助其他人学习和了解
架构图不是架构结果的精确表示,而是架构师思想的表达
质量
对性能以及平均故障间隔时间等的量化描述已经广为人知,质量场景扩展了这些思想,并鼓励人们用可度量的陈述记录所有因素
质量场景是形如<刺激><可度量响应>的简短陈述.例如:
当销售完成,调用远程税金计算器服务计算税金时,在平均负载条件的生产环境下,大部分会在2秒之内完成
当NextGen Beta测试的志愿者报告一个bug时,应在一个工作日内电话回复
选择你的战斗
factor table
FURPS
- functional
- usablity
- reliability
- performance
- supportability
H/M/L
- H
- M
- L
将各种架构上考虑的情况加以说明,并给出困难或风险的评级
艺术
收集和组织有关的架构性因素,可以称为架构的科学.根据相互依赖情况,优先级,权衡考虑等,做出解决这些因素的决定,可以称为*架构的艺术
现在不考虑做出架构选择的原则,几乎所有的方法都建议保存与重要问题和决定有关的信息
当然,上面的记录不只是决定,好包括动机(架构师自己也会遗忘)和其他可供选择的方案
post-compiler & aspect-oriented
后编译器(在常规的编译器之后执行的"编译器")在后盖后的…开发者只能看到仅包含"干净"的业务逻辑的类
另一种方法是诸如AspectJ这样技术
引导架构决策的优先级
- 强制性约束
强制性的安全和法律规定 - 业务目标
商业价值等 - 所有其他目标
敏捷
计划依次迭代
- 确定迭代的时间长度.迭代的结束时间一旦确定,就不应改变—这是时间定量的实践.但是,可以通过减少本次迭代的工作范围来满足该结束时间
- 召集迭代计划会议.这通常在上一次迭代完成而下一次迭代尚未开始时进行.在理想情况下,主要涉众都应该参加:顾客(营销人员,最终用户),开发者,首席架构师和项目经理等
- 列出本次迭代的潜在目标并标记优先级
通常由客户(代表业务目标)和首席架构师(代表技术目标)共同确定 - 每个成员为本次迭代编制个人资源预算(以小时/天为单位)
- 对于某一目标,在计划中对其进行较为详细的描述,并分解其对应的问题.接着进行头脑风暴
- 反复进行第5步直到确定足够多的工作
可以看出来,架构师的价值不在于解决问题,而是指明方向
Phase Plan & Iteration Plan
可以让外部涉众看到一个宏观计划(例如三个月),开发团队对此作出承诺.但是,微观的组织应该留给团队的适应性判断
UP是用例驱动,这意味着工作是围绕用例的实现来组织的
通常用例有过多的可选场景,因此无法再一次迭代中全部完成,
准则
在每次迭代完成之后,使用版本控制工具为这些文件夹中所有元素(包括源代码)创建带有标签并且冻结的检查点.这样,每个制品都会有多个版本…以后(在该项目或其他项目中)估计团队的开发速度时,这些检查点为每次迭代所完成的工作量提供了原始数据
何时你会发现自己并没有理解迭代计划
- 推测性详细计划了所有迭代,并且预订了每次迭代的任务和目标
期望初始阶段或者细化阶段第一次迭代中的预算是可靠的,且被用于长期的项目承诺
在早期迭代阶段解决容易或者低风险的问题