需求变化与IoC

标签: 程序设计 系统架构 Design design pattern IoC | 发表时间:2012-03-26 11:01 | 作者:Todd
出处:http://coolshell.cn

【感谢 Todd投递本文 – 微博帐号:@ weidagang

需求又变了,怎么办?

先上一个轻松的段子:

程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫。可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀!”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了?”。

这个段子用幽默的方式反映了需求变化是每一个程序员、架构师或项目经理都会经常遇到的问题。面对这个问题,不同的人有不同的应对之道,最近微博上有一段关于需求变化的讨论:

@假装刺猬的猪:我们在软件开发过程中,会持续碰到客户需求变更的情况。如果没有领域建模,我们单纯将问题使用直觉将问题解决,那么等到客户需求变更或者有新的需求时,就会面临一个僵硬的前设计!无法在以前的设计上持续深入的优化模型,导致需求变更无法及时深化。设计实现均滞后与变更!

@高煥堂: <碰到客户需求变更的情况>是合理的;但<领域建模>不是美好的手段!!!

@weidagang: 要不被客户牵着鼻子走,需要自己有很强的设计能力, 反过来让客户跟着你的设计来满足你的要求。能做到这点的公司很少,但这是软件行业唯一有希望的出路。

@高煥堂: <这是软件行业唯一有希望的出路>。 Great!!

如何应对需求变化? @假装刺猬的猪 的答案是领域建模,并持续优化模型,适应需求的变化。@高煥堂 则认为领域建模不是美好的手段。我进一步补充,应该 “反过来”让自己在需求变化中处于主导地位,而不是被动地适应。

控制反转 (IoC)

什么样就算是“反过来”了呢?举个例子:

用户想购买一台普通PC,他只想电脑能流畅运行魔兽世界,他根本不想知道什么叫主板,什么叫内存,什么叫CPU;但他不得不接受必须购买主板、CPU、内存的事实,因为PC架构是产业标准,而不是由用户定的。客户有选择的权利,但没有设计的权利,客户的需求必须在设计框架下得到满足。

这里我们要问PC架构是保护了谁的利益?显然,直接的受益者是厂商。如果没有PC架构的保护,厂商就会直接面对客户,客户说我需要功能A,我马上分析设计实现功能A;客户说我要功能B,我马上分析设计实现功能B … 有了PC架构的保护,厂商就变得更加强势,用户的一切需求都必须在PC架构下来谈。厂商可以倾听用户的声音,不断改进产品,但设计主导权永远在自己手中。我们IT行业常常用“做产品”和“做项目”的视角来区分不同的公司,但很少有人用“做设计”的视角来看。实际上,关键的问题在于设计主导权是厂商还是在客户。如果设计主导权在客户,不管是做产品、做服务还是做项目,其命运必然是疲于奔命应付客户,最后获得微薄的利润;如果设计主导权在厂商,不管做产品、做服务还是做项目都能有更多的话语权和更高的利润。

当然,光有设计还不够,必须客户接受才能起到通过设计掌握主导权的作用。这一方面需要自己具有很强的设计能力,如苹果就是以设计能力著称的公司;另一方面,和其他厂商结盟壮大阵营也是一种方法,如最著名的Wintel联盟(Windows+Intel),以及现在的日益壮大的Android阵营都属于此类。假如有厂商不遵守PC产业标准,说我的PC就没有主板,没有显卡,因为用户更不不需要这些东西;那么,它要么像苹果一样独树一帜成为一种新的标准,要么无人问津。

我所谈到的“反过来”本质上就是软件设计中的控制反转 (Inversion of Control, IoC)思想。IoC是每一个初级程序员向高级进阶所需要了解的 最重要的设计思想。由于Spring等开发框架的流行,知道IoC概念的程序员不在少数,但不少人对于IoC的理解仅仅停留在通过依赖注入 (Dependency Injection)实现解耦这个层面。实际上,IoC的应用不仅包括解耦,它还是框架的基本原理,在非计算机领域,IoC也是无处不在,如果你能从上面的例子中体会到IoC,这才算是融会贯通了。

软件开发中一种最常见的模式是“以用户为出发点,以需求分析为核心”。该模式提倡从用户需求中分析推导出设计和实现,比如,TDD式的设计正是这类典型。而IoC式的软件设计与此截然相反,IoC的设计是一种“以愿景(自身利益是愿景的重要方面)为出发点,以架构为核心”的模式。如果用户的需求是一台电脑,我们如何能通过第一种模式分析需求推导出“主板-CPU-内存-外设”的PC架构呢?恐怕很难。IoC式的设计是以用户看不见摸不着的架构为核心,自己主导设计,用户需求是设计的约束条件和验证手段,而不是出发点和目标。我们想要掌握主动,不被需求变化搞得疲于奔命,就必须熟练使用第二种模式。

我们的人生都被环境和各种客观条件所束缚,多数人只能随波逐流,听从命运的安排。你有没有想过要拥有人生的主导权呢?既然你是程序员,你懂IoC,你能否设计自己的人生框架呢?Yes,you can!

|2|left
您可能也喜欢:

结对编程的利与弊

9个强大免费的PHP库

在新浪微博上关于敏捷的一些讨论

超强的验证码

用Google Translate玩转beat box
无觅

相关文章

相关 [需求 变化 ioc] 推荐:

需求变化与IoC

- - 酷壳 - CoolShell.cn
【感谢 Todd投递本文 – 微博帐号:@ weidagang 】. 程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫. 可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀. ”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了.

【连载 Spring IoC】IoC的理解与Spring IoC的架构介绍

- - 码农博客
研究Spring的人太多了,网上的资料也数不胜数,今天开始笔者也将开始分析Spring以及Spring的源码,主要为自己更好地学习和掌握Spring的原理,其次分享到网上也是供大家学习和拍砖. 第一篇,没有写Spring的整体架构,原因是笔者对Spring的整体架构也不是非常熟悉,虽然网上有很多资料查询参考,但是笔者想不是自己研究的,就没必要搬过来,笔者写下的内容都是笔者亲自学习和研究的,并且可能写下来也会根据笔者的理解深度和广度不断更新.

也谈谈我对IoC的理解

- - 博客园_首页
  今天看到一篇 帖子谈到了对IoC的理解,于是我自己也忍不住跳出来“理解”一番,其实我当年也被“依赖注入、控制反转”这八个字折腾的够呛,但是搞明白之后就会发现这几个字、包括IoC这个名字都纯粹是唬人的,于是今天准备用三张图来说明白这件事.   首先,IoC和DI说的是一件事,它们的中文名分别是IoC(控制反转)和DI(依赖注入),要说依赖注入,就要先说说依赖倒置原则.

再谈需求

- - 人月神话的BLOG
谈需求工程方面的文章前面写过很多,本文仅做最近思考的一些点滴记录. 首先我们谈下业务建模层面,对于从用户提出最初的业务需求到交付一个完整的系统,在建模层面涉及到两个层面的抽象,其一就是业务建模解决现实世界本身的抽象描述,其二就是软件架构设计,解决从业务模型到IT架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.

进化而来的需求

- - 极客公园-GeekPark
[核心提示]需求是可以创造,可以进化的. 在需求的“博尔赫斯库”中,我们要做的,仅仅是模拟规则,让需求,优胜劣汰. 如果本文的标题和导语引起了坐在电脑前的你的兴趣,同时又产生了些许的疑惑,那么恭喜我自己,我的目的达到了 (真是恶趣味……). 那么,在对它们进行解释之前,还容我卖个关子,先从几个有趣的见闻讲起.

谈需求和设计

- - 人月神话的BLOG
在这里再谈下需求和设计的边界问题,我们最终的业务系统实现出现的偏差,究竟是需求的问题还是设计的问题. 如果边界不清楚则很难明确的区分. 对于需求本身有原始需求,用户需求,产品需求和系统需求的各种阶段;而对于需求的过程也本身存在原始需求的收集,需求分析,需求挖掘,和需求相关的业务建模. 而对于设计同样存在总体的企业架构设计,到单个应用的总体设计和架构设计,概要设计和详细设计.

解决方案与需求

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
曾经有一个很有名的段子,大致意思就是说在汽车尚未出现的马车时代,你去做消费者调研,只会得到这样的答案:我需要一匹更快的马,而不会得到:我需要汽车. 因为对于消费者来说,他从来没有看到过汽车,怎么可能回答你需要汽车呢. 这个段子,似乎充分说明了,创新,尤其是颠覆式创新、破坏性创新是不可能通过需求调研出来的.

如何做需求分析

- - 人人都是产品经理
这段时间我做了两个大项目,其中一个项目算是商业模式上和使用规范上的调整,另一个项目是之前功能的重做,为什么重做我下面会说到. 关于需求分析,我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%,产品设计到评审完的时间大概是20%,也就是说实际开发之前产品团队介入的工作占据项目的60%,在需求分析阶段我有一些个人观点.

产品方法论:需求变更

- 盛开 - 所有文章 - UCD大社区
IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情,项目失败的原因千千万,我认为需求管理、需求变更管理是个很重要的因素. 恰恰PM的工作缺不了项目管理,更缺不了对于需求的管理,偶然的原因,和团队分享了我对于项目进行中“需求变更”的理解和管理方法. 忽然发现之前写过很多产品思考和细节思考的东西,但从没有整理出方法论,后续应该多整理下方法论.

需求分析中的产品定位

- Jessica - 所有文章 - UCD大社区
看过《定位》最大的感受就是产品在诞生之前就决定了他是否能存活或成功. 就像走在商场中,面对玲琅满目的产品,你似乎很难找到一两款绝对同质化的大品牌:. 各式的服装,NIKE的衣服是运动的,但也不会和做户外运动的哥伦比亚冲突. 都是做化妆品,Fancl打出“无添加”没有防腐剂也收获了一群喜爱天然的用户…...