Story 场景树; 锻练开发人员 “简单设计” 的思维力

2018-03-192022-03-06 方俊贤; Ken Fang

Read Time:1 Minute, 28 Second

前言:

软件开发的过程中, 不做简单设计, 软件开发就永远做不好。

但是, 简单设计假如只是写写文档, 而不能指导开发, 这样的简单设计, 就只是在瞎折腾。

简单设计能指导开发, 指的是:
1. 代码隔离:

简单设计能使开发人员, 在开发前, 有一清晰且明确的指导地图; 开发人员沿著这指导地图, 便可开发出高质量的代码。使得代码不仅能符合各个质量属性上的要求, 更能使代码具备好的 “隔离“; 不会因后续需求上的变更, 而产生新的缺陷或失败。

2. 测试用例定义 “开发完成” 的标准:

简单设计能使开发人员, 在开发前, 便设计出测试用例; 使得开发人员可明确的定义, 每日所开发的 TASK, 完成的标准是什么? 需通过那些测试用例的场景?

3. 每日目标 (风险) 管理:

简单设计能使开发人员, 明确且客观的做出结论: 今天该完成的 TASK 完成了没? 假如, 没完成, 真正的问题是什么? 该寻求什么样的协助?

Story 场景树:

简单设计要如何做？

有的人是天生就会的。
而大部分的我们, 简单设计的思维, 是需要经过一段时间锻练的；不是天生就会的。

Matei Zaharia; Spark 开发的主导者。
Matei 当在用 Scala 开发 Spark 时, 并没有做所谓的简单设计。
Matei 在开发前, 会先在脑中清楚的浮现出软件的架构。
Matei 便照着脑中的软件架构, 开发完了一行又一行伟大的代码。
Matei 每次在开发完一段代码后, 便会根据代码的弱点, 设计所谓 “灾难测试” 的测试用例；测试自己所开发的代码, 在架构上的弱点为何？

敏捷开发与软件工程实践；如：Story 场景树；对 Matei 而言, 是完全没有 “必要” 的。因为, Matei “天生” 就会简单设计了。

Story 场景树, 主要是要帮助开发人员, 锻练 “简单设计” 的思维力；当经过一段时间的锻练后, 开发人员就可没有 “必要” 的再使用 Story 场景树进行简单设计。因为, 开发人员已能将软件架构浮现在脑海中, 并能自然而然的思考出简单设计。

为何 Story 场景树, 可帮助开发人员, 锻练 “简单设计” 的思维力？

因为, Story 场景树够可视化, 够轻量级；放在ㄧ个脑袋里, 绰绰有余。

从图一的 Story 场景树中, 清楚的指导著开发人员在“客户租 CD”的这个 Story 中, 总共有 3 个关注点所产生的3 个 TASKs 需完成开发; 分别是:

获取客户租 CD 的数据 (历史数据)。
校验客户已租的 CD 片数是否已超过 3 片?
计算客户所租的 CD 需归还的日期。

开发人员亦可在图一的 Story 场景树中, 分析、标示每个将进行开发的 TASK 需调用的外部接口。

开发人员按照 Story 场景树中的 TASK, 进行代码上的隔离; 使得 Story 不会因后续某个TASK需求上的变更, 而使得其他的 TASKs引入新的缺陷或失败。

例如: 开发人员从图一的场景树中很清晰的就能分析出: “TASK 获取客户租 CD 的数据 (历史数据)” 与 “TASK计算客户所租的 CD 需归还的日期”, 需要进行代码上的隔离。因为, 开发人员希望当 “TASK计算客户所租的 CD 需归还的日期” 的运算逻辑的代码改变时, 不致于会在 “TASK 获取客户租 CD 的数据 (历史数据)” 中引入新的缺陷或失败。

当然, 代码隔离的实现方式可藉由不同的接口或是适当的引用设计模式 (Design Patterns) 来完成。

更重要的是 : 开发人员亦可从图一的 Story 场景树中, 设计每个将进行开发的 TASK 所需的 “测试用例”; 当开发人员能设计出 TASK 相对应的测试用例时, 所代表的意义不仅是开发人员已能充分的理解了需求, 更说明了开发人员已能从TASK 相对应的测试用例中, 明确的定义出 “TASK 完成的标准”。

当开发人员已能从TASK 相对应的测试用例中, 明确的定义“TASK 完成的标准”时, 开发人员便能明确且客观的做出结论: