"设计不足"与"过度设计"
2013-11-03 00:53
302 查看
什么是设计不足 (under-engineering)? 设计出来的系统复用性差,扩展性不强,不能灵活的应对变化,简言之,设计没到位。设计不足,多半是因为经验有限,设计能力有限。
什么是过度设计 (over-engineering)? 设 计出来的系统比恰到好处要复杂臃肿的多,过度的封装、一堆继承、接口和无用的方法,超复杂的 xml配置文件,简言之,客户需求是要一把杀鸡的刀,你给设计
了一把牛刀(杀鸡用牛刀)。过度设计,多半是因为有设计的癖好,喜欢炫耀或玩弄无谓的技巧,或是喜欢把简单的问题搞复杂化。
如此说来,没有人能说自己的设计就是恰到好处的。适合的就是最好的,但什么是适合的?这个度很难把握。
客户只是告诉你他“需要一把杀鸡的刀”,至于将来有没有需求变化,有没有可能要这把刀能杀牛,客户也不知道。所以当然这个设计的度就很难把握了。
有人主张设计必须前瞻与用户需求,不能以需求为导向。 因为客户从来不会告诉你他未来的需求,连他也不知道。例如,消费者从来不会告诉 RIM公司,我需要一款能收企业邮件的 BlackBerry手机。
但也有人持相反观点,认为设计必须以需求为导向,软件以人为本,以用为本。
其实从一定意思上说,过度设计和设计不足都是“设计错误”的一种形式。
设计不足,则意味着系统复用性扩展性和灵活性差,系统僵化,不能应对将来的需求变化,或者将来修改和维护的代价和成本会很高,这当然是设计错误;
过度设计,则意味着为了实现这个设计要付出的额外代价,例如成本上升,缺陷可能性加大,提升维护成本,甚至降低系统性能。而可维护性和系统的高性能都是系统的隐性需求,这些需求没实现好,当然也是设计错误。
从另外一个角度看来,能够进行过度设计的,多半设计能力高于设计不足的;过度的设计改回来的成本也比设计不足的改过去的成本低的多。
Martin Fowler说敏捷开发 不 是轻视设计重实践和重构,而是演进式的设计 (Evolutionary Design,区别与计划性的设计 Planned Design)。每一次的重构和迭代都映射和更新到最新的设计中来,从而最大限度的满足客户的功能性需求和非功能性需求。从最初的 Prototyping、初始需求分析与建模,然后进行演进式的架构设计和实践,这也许是适合于大多数中小型项目的最佳实践。
因为变化是无穷无尽的,需求是变幻莫测的,我们每天都跟在需求后面跑,跑的很累。而客户还要求我们随需应变,抱怨我们不够敏捷,要求我们以欢喜的心态来拥抱变化,因为变化就是 IT的机会嘛 ! 但我们能找到“银弹”来封装所有未知的需求变化吗?我们能超前于客户的需求,能变被动为主动吗?我们能设计出一个系统超前于未来客户的需求吗?
没有一个完美的能随需应变的系统,所谓“设计之美”也是盛名之下其实难副。我们实际的目标只是最大限度的封装变化,最大限度的预测某些未来可能的变化,提供某些系统扩展和变化的可能性,从而减低未来变化的成本,为客户创造价值 。
也许,最简单的才是最好的。大巧若拙,大道至简 , 有时候越简单的反而越难实现,而且越接近真理。也许这个只能靠个人体会和悟性了,才能最终体会到简单的精妙设计之美。熟背各种设计模式、学个一招半式的 人,就像一个天天背着一把剑的剑客一样,唯恐旁人不知道其剑术高强;而真正的高手是手中无剑,却照样可以打赢别人,因为万物都可被他用来施以剑法。这才是 真正的高境界。
我们缺乏的 是真正有创意的创造性的设计,比如我们为什么没有设计出中国人自己的 framework和 platform?因为我们经验、技术和设计能力不足,大家都沉 迷于玩一些小技巧,战术技巧,不是战略技巧;玩到 30岁然后都去做 PM做培训做销售去了。而在那些需要简约设计的地方,我们却自诩为高手而加上很多华丽的
设计来维护虚幻的可扩展性和灵活性。
中国的架构师,缺乏的不仅仅是经验、技术、创意、设计能力,也许最缺乏的是思想,是心境。
什么是过度设计 (over-engineering)? 设 计出来的系统比恰到好处要复杂臃肿的多,过度的封装、一堆继承、接口和无用的方法,超复杂的 xml配置文件,简言之,客户需求是要一把杀鸡的刀,你给设计
了一把牛刀(杀鸡用牛刀)。过度设计,多半是因为有设计的癖好,喜欢炫耀或玩弄无谓的技巧,或是喜欢把简单的问题搞复杂化。
如此说来,没有人能说自己的设计就是恰到好处的。适合的就是最好的,但什么是适合的?这个度很难把握。
客户只是告诉你他“需要一把杀鸡的刀”,至于将来有没有需求变化,有没有可能要这把刀能杀牛,客户也不知道。所以当然这个设计的度就很难把握了。
有人主张设计必须前瞻与用户需求,不能以需求为导向。 因为客户从来不会告诉你他未来的需求,连他也不知道。例如,消费者从来不会告诉 RIM公司,我需要一款能收企业邮件的 BlackBerry手机。
但也有人持相反观点,认为设计必须以需求为导向,软件以人为本,以用为本。
其实从一定意思上说,过度设计和设计不足都是“设计错误”的一种形式。
设计不足,则意味着系统复用性扩展性和灵活性差,系统僵化,不能应对将来的需求变化,或者将来修改和维护的代价和成本会很高,这当然是设计错误;
过度设计,则意味着为了实现这个设计要付出的额外代价,例如成本上升,缺陷可能性加大,提升维护成本,甚至降低系统性能。而可维护性和系统的高性能都是系统的隐性需求,这些需求没实现好,当然也是设计错误。
从另外一个角度看来,能够进行过度设计的,多半设计能力高于设计不足的;过度的设计改回来的成本也比设计不足的改过去的成本低的多。
Martin Fowler说敏捷开发 不 是轻视设计重实践和重构,而是演进式的设计 (Evolutionary Design,区别与计划性的设计 Planned Design)。每一次的重构和迭代都映射和更新到最新的设计中来,从而最大限度的满足客户的功能性需求和非功能性需求。从最初的 Prototyping、初始需求分析与建模,然后进行演进式的架构设计和实践,这也许是适合于大多数中小型项目的最佳实践。
因为变化是无穷无尽的,需求是变幻莫测的,我们每天都跟在需求后面跑,跑的很累。而客户还要求我们随需应变,抱怨我们不够敏捷,要求我们以欢喜的心态来拥抱变化,因为变化就是 IT的机会嘛 ! 但我们能找到“银弹”来封装所有未知的需求变化吗?我们能超前于客户的需求,能变被动为主动吗?我们能设计出一个系统超前于未来客户的需求吗?
没有一个完美的能随需应变的系统,所谓“设计之美”也是盛名之下其实难副。我们实际的目标只是最大限度的封装变化,最大限度的预测某些未来可能的变化,提供某些系统扩展和变化的可能性,从而减低未来变化的成本,为客户创造价值 。
也许,最简单的才是最好的。大巧若拙,大道至简 , 有时候越简单的反而越难实现,而且越接近真理。也许这个只能靠个人体会和悟性了,才能最终体会到简单的精妙设计之美。熟背各种设计模式、学个一招半式的 人,就像一个天天背着一把剑的剑客一样,唯恐旁人不知道其剑术高强;而真正的高手是手中无剑,却照样可以打赢别人,因为万物都可被他用来施以剑法。这才是 真正的高境界。
我们缺乏的 是真正有创意的创造性的设计,比如我们为什么没有设计出中国人自己的 framework和 platform?因为我们经验、技术和设计能力不足,大家都沉 迷于玩一些小技巧,战术技巧,不是战略技巧;玩到 30岁然后都去做 PM做培训做销售去了。而在那些需要简约设计的地方,我们却自诩为高手而加上很多华丽的
设计来维护虚幻的可扩展性和灵活性。
中国的架构师,缺乏的不仅仅是经验、技术、创意、设计能力,也许最缺乏的是思想,是心境。
相关文章推荐
- "设计不足"与"过度设计"
- Contest1376 - "师创杯"烟台大学第二届ACM程序设计精英赛复现 A--A Repeating Characters
- Contest1376 - "师创杯"烟台大学第二届ACM程序设计精英赛复现F-A Simple Question
- "无法修改表,超时时间已到" 增加设计器 事务的执行时限
- 设计模式-OOD的设计原则(3)-"依赖倒转原则"
- 谈谈设计不足(under-engineering)与过度设计(over-engineering)
- 一个被微软咨询顾问"认证"的"技术开发平台"设计规范
- "围观"设计模式(10)--创建型之原型模式(Prototype Pattern)
- "围观"设计模式(8)--创建型之简单工厂模式、工厂方法模式、抽象工厂模式
- 修复 VS2008 asp.net 设计视图 -工具-选项-[Html设计视图]出现"加载此属性页时出错" 解决方案
- python核心编程第六章题目:python代码实现:设计一个"石头,剪子,布"游戏
- 谈谈设计不足(under-engineering)与过度设计(over-engineering)
- 正方形不是矩形" << 【OOD设计原则之里氏替换原则(LSP)--- 设计模式之禅读书笔记
- 设计模式之"策略模式"
- 设计模式之"工厂方法"模式
- 设计模式-OOD的设计原则(4)-"接口隔离原则"
- 数据库表设计关于"主键"选择乱谈
- 身份证校验 如果让你设计个程序,用什么变量保存身份证号码呢?长整数可以吗?不可以! 因为有人的身份证最后一位是"X"
- 模块管理常规功能自定义系统的设计与实现(15--进一步完善"省份"模块)
- 设计模式-OOD的设计原则(5)-"合成聚合复用原则"