软件开发的过程中, 一定需要简单设计?
2017-07-05 00:14
465 查看
2017.7.4, 深圳, Ken Fang
前言:
简单设计只是写文档, 而不能指导开发, 这样的简单设计, 就只是在瞎折腾。
但是, 软件开发的过程中, 不做简单设计, 软件开发就永远做不好。
简单设计能指导开发, 指的是:
1.简单设计能使开发人员, 在开发前, 有一清晰且明确的指导地图; 开发人员沿著这指导地图, 便可开发出高质量的代码。使得代码不仅能符合各个质量属性上的要求, 更能使代码具备好的 “隔离 “; 不会因后续需求上的变更, 而产生新的缺陷或失败。
2. 简单设计能使开发人员, 在开发前, 便设计出测试用例; 使得开发人员可明确的定义, 每日所开发的 TASK, 完成的标准是什么? 需通过那些测试用例的场景?
3. 简单设计能使开发人员, 明确且客观的做出结论: 今天该完成的 TASK 完成了没? 假如, 没完成, 真正的问题是什么? 该寻求什么样的协助?
本文:
简单设计要如何做?
有的人是天生就会的。
而大部分的我们, 简单设计的思维, 是要经过一段时间锻练的;不是天生就会的。
Matei Zaharia; Spark 开发的主导者。
Matei 当在用 Scala 开发 Spark 时, 并没有做所谓的简单设计。
Matei 在开发前, 会先在脑中清楚的浮现出软件的架构。
Matei 便照着脑中的软件架构, 开发完了一行又一行伟大的代码。
Matei 每次在开发完一段代码后, 便会根据代码的弱点, 设计所谓 “灾难测试” 的测试用例;测试自己所开发的代码, 在架构上的弱点为何?
敏捷开发与软件工程实践;如:Story 场景树;对 Matei 而言, 是完全没有 “必要” 的。因为, Matei “天生” 就会简单设计了。
Story 场景树, 主要是要帮助开发人员, 锻练 “简单设计” 与 “测试用例设计” 的思维;当经过一段时间的锻练后, 开发人员自然而然的, 就可没有 “必要” 的再使用 Story 场景树, 进行简单设计。因为, 开发人员已能将软件架构浮现在脑海中, 并能自然而然的思考出测试用例。
为何?
因为, Story 场景树够可视化, 够轻量级;放在ㄧ个脑袋里, 绰绰有余。
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/05/c27be8d8750cba116d8bc12fa9de62d3)
[图一: Story 场景树: 可视化、轻量级的开发人员指导地图]
结论:
拥有 “简单设计思维” 的开发人员, 永远是在用 “脑” 驱动著手, 产生一行又一行伟大的代码。之所以称之为一行又一行伟大的代码, 是因为, 每一行代码永远都是能随著时间的推移, 而能持续的演进; 演进的过程中, 却依然保持著健康、强壮。伟大的代码就宛如是拥有强健生命的有机体。
永远只会用手写代码的开发人员, 产生的代码从一出生 (第一个版本), 就发育不全 (缺陷百出)。毫无疑问的, 随著时间的推移, 病只会越来越重 (缺陷、失败越来越多) 。
将能锻炼 “简单设计思维” 的方法、工程实践, 放在永远只会用手写代码的开发人员的面前时, 所会发生的场景, 就宛如是图二中, 那位拉车的…
人生是选择题, 不是是非題; 做出什么样的选择? 便过著怎么样的人生; 产出什么样的代码。
![](https://oscdn.geek-share.com/Uploads/Images/Content/201909/05/3994922820924c694ba427cc2335a1e4)
[图二: 拉车的: 我很忙…]
前言:
简单设计只是写文档, 而不能指导开发, 这样的简单设计, 就只是在瞎折腾。
但是, 软件开发的过程中, 不做简单设计, 软件开发就永远做不好。
简单设计能指导开发, 指的是:
1.简单设计能使开发人员, 在开发前, 有一清晰且明确的指导地图; 开发人员沿著这指导地图, 便可开发出高质量的代码。使得代码不仅能符合各个质量属性上的要求, 更能使代码具备好的 “隔离 “; 不会因后续需求上的变更, 而产生新的缺陷或失败。
2. 简单设计能使开发人员, 在开发前, 便设计出测试用例; 使得开发人员可明确的定义, 每日所开发的 TASK, 完成的标准是什么? 需通过那些测试用例的场景?
3. 简单设计能使开发人员, 明确且客观的做出结论: 今天该完成的 TASK 完成了没? 假如, 没完成, 真正的问题是什么? 该寻求什么样的协助?
本文:
简单设计要如何做?
有的人是天生就会的。
而大部分的我们, 简单设计的思维, 是要经过一段时间锻练的;不是天生就会的。
Matei Zaharia; Spark 开发的主导者。
Matei 当在用 Scala 开发 Spark 时, 并没有做所谓的简单设计。
Matei 在开发前, 会先在脑中清楚的浮现出软件的架构。
Matei 便照着脑中的软件架构, 开发完了一行又一行伟大的代码。
Matei 每次在开发完一段代码后, 便会根据代码的弱点, 设计所谓 “灾难测试” 的测试用例;测试自己所开发的代码, 在架构上的弱点为何?
敏捷开发与软件工程实践;如:Story 场景树;对 Matei 而言, 是完全没有 “必要” 的。因为, Matei “天生” 就会简单设计了。
Story 场景树, 主要是要帮助开发人员, 锻练 “简单设计” 与 “测试用例设计” 的思维;当经过一段时间的锻练后, 开发人员自然而然的, 就可没有 “必要” 的再使用 Story 场景树, 进行简单设计。因为, 开发人员已能将软件架构浮现在脑海中, 并能自然而然的思考出测试用例。
为何?
因为, Story 场景树够可视化, 够轻量级;放在ㄧ个脑袋里, 绰绰有余。
[图一: Story 场景树: 可视化、轻量级的开发人员指导地图]
结论:
拥有 “简单设计思维” 的开发人员, 永远是在用 “脑” 驱动著手, 产生一行又一行伟大的代码。之所以称之为一行又一行伟大的代码, 是因为, 每一行代码永远都是能随著时间的推移, 而能持续的演进; 演进的过程中, 却依然保持著健康、强壮。伟大的代码就宛如是拥有强健生命的有机体。
永远只会用手写代码的开发人员, 产生的代码从一出生 (第一个版本), 就发育不全 (缺陷百出)。毫无疑问的, 随著时间的推移, 病只会越来越重 (缺陷、失败越来越多) 。
将能锻炼 “简单设计思维” 的方法、工程实践, 放在永远只会用手写代码的开发人员的面前时, 所会发生的场景, 就宛如是图二中, 那位拉车的…
拉车的永远说...我很忙。 拉车的永远说...先证明轮子对我是有价值的,我才会考虑用轮子。 拉车的永远说...我现在牛逼的很,为什么要用轮子?
人生是选择题, 不是是非題; 做出什么样的选择? 便过著怎么样的人生; 产出什么样的代码。
[图二: 拉车的: 我很忙…]
相关文章推荐
- web开发,是个非常敏捷的过程,变化随时都在产生,用户需求千变万化,许多方面偶然性非常高,较之软件开发,希望用一个架构规划以后的所有设计,是不现实的
- 需要大量设计的软件如何进行敏捷开发
- 软件开发过程五 用户界设计
- 软件开发过程中的过度设计
- 面向对象软件开发和过程(六) - 针对契约设计(转)
- 全国软件专业人才开发与设计赛题之简单题
- 软件开发过程中的浪费——详细设计
- 软件开发过程一 需求分析与设计
- sharepoint开发设计中所需要掌握的基础信息---软件限制、性能情况等
- 全国软件专业人才开发与设计赛题之简单题
- 需要大量设计的软件如何进行敏捷开发
- 需要大量设计的软件如何进行敏捷开发
- 详细设计成软件开发过程中的浪费
- [软件开发过程]反模式:简单的部分留在需求人员的脑海中,只描述最复杂的部分给我们听
- 关于软件开发过程中的设计阶段
- 需要大量设计的软件如何进行敏捷开发
- 需要大量设计的软件如何进行敏捷开发
- 软件开发再编写过程中,要尽可能地让开发者再后来可以很容易地找到软件的编写逻辑和思路结构。这才是我们需要追求的。
- 设计模式入门 软件开发过程--------------CHANGE,change----------
- 软件开发过程五 用户界设计