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

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

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

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

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

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

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

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

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

本文: 简单设计要如何做？

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

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

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

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

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

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

[图一: Story 场景树: 可视化、轻量级的开发人员指导地图]

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

1.获取客户租 CD 的数据 (历史数据)。

2.校验客户已租的 CD 片数是否已超过 3 片?

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 完成的标准”时, 开发人员便能明确且客观的做出结论:

1.今天该完成的 TASK 完成了没?

2.假如, 没完成, 真正的问题是什么? 该寻求什么样的协助?

结论:

拥有 “简单设计思维” 的开发人员, 永远是在用 “脑” 驱动著手, 产生一行又一行伟大的代码。之所以称之为一行又一行伟大的代码, 是因为, 每一行代码永远都是能随著时间的推移, 而能持续的演进; 演进的过程中, 却依然保持著健康、强壮。伟大的代码就宛如是拥有强健生命的有机体。

永远只会用手写代码的开发人员, 产生的代码从一出生 (第一个版本), 就发育不全 (缺陷百出)。毫无疑问的, 随著时间的推移, 病只会越来越重 (缺陷、失败越来越多) 。

将能锻炼 “简单设计思维” 的方法、工程实践, 放在永远只会用手写代码的开发人员的面前时, 所会发生的场景, 就宛如是图二中, 那位拉车的…

拉车的永远说...我很忙。

拉车的永远说...先证明轮子对我是有价值的,我才会考虑用轮子。

拉车的永远说...我现在牛逼的很,为什么要用轮子?

[图二: 拉车的: 我很忙…]

人生是选择题, 不是是非題; 做出什么样的选择? 便过著怎么样的人生; 产出什么样的代码。