需求变化与IoC

需求变化与IoC

感谢 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!

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (25 人打了分,平均分: 3.88 )
Loading...

需求变化与IoC》的相关评论

  1. 说的很对,去年做的一个项目我就是这么干的,不过当时对IoC的理解就如文中所说,现在才知道还可以上升到这个高度~

  2. 理想是美好的,现实是残酷的。我讲个笑话:
    某富翁想娶老婆,有三个人选,富翁给了三个女孩各一千元,请她们把房间装满。第一个女孩买了很多棉花,装满房间的1/2。第二个女孩买了很多气球,装满房间的3/4。第三个女孩买了很多蜡烛,让光线充满房间。
    最终,富翁选了胸部最大的那个。

  3. 一两年前,我也是坚持这样的想法,把公司的产品设计和项目区分开来,后来上层和同事们都因为一些原因慢慢放弃了专注于产品的开发,转向项目开发,用他们的话说“这是闭门造车”。于是我离开了那家公司,但我知道他们也有苦衷,产品到底能不能上一个台阶只是愿景,小公司最需要的,是生存问题。

  4. 很有趣的文章,但是不知道作者对我这种在软件外包公司做PM的人有什么建议没有?
    我们公司欧美客户的系统以市场需求为导向,在做一个项目的过程中需求变更太平常了,我们作为offshore乙方也不可能跟他说什么不要变化,只能去尽量控制这个变化带来的影响。
    IoC是个很有意思的理念,有没有实际的项目或产品作为案例,详细阐述一下吗?

  5. 这种想法很好,但往往小公司很难做到,因为他们首先要解决的是吃饭问题,就不可避免的要根据客户的需求不断修改,要是实现控制反转,估计还是有难度的,我想不仅仅是设计问题。

  6. 感觉论述没有展开啊,里面可以论一论的问题很多。比如框架的设计,逻辑实现语言的设计,业务通用接口的设计,逻辑实现语言和实际代码的交互。

  7. 不错。

    用户往往不知道他真正想要的是什么——老板也是用户。

    好的设计者,应该吃透什么才是用户真正需要的;然后,从专业的角度,把用户的真实需求抽象出来。这个大框架一出来,用户的需求就只是一些细节问题,可能仅仅改变一些配置文件就可以跟上变化了。

    比如,PC设计就是这样: 用户真正想要的,是一台既便宜又能满足自己需要的电脑;他们的需要可以抽象为整数计算、浮点计算、3D图形图像、存储以及网络等几个关键点。于是“便宜”+“满足需要”就成了主板上接插件的选择。

    另一种“偷懒”的设计方法,是把用户的需求“拆卸”为逻辑上独立的简单“模块”,软件就成了用这些模块堆积木的过程——我之前为公司做的一个设计就是这样:那是个探索性的项目,没人知道确切需求,只能做哪算哪。

    但,其中至少磁盘缓存管理、认证、权限管理、存储管理等是必需的,而这些都可以做出完整的可重用方案:哪怕这个项目失败了,这些“零件”也可以给公司其他项目组使用。

    最终,这个项目成功了。最终版本连DHT网络都集成进去了;但整个项目有条不紊,代码写一块“凝固”一块。因为新代码可以随便加,除了完成集成的那个main,没什么需要回头修改的。

  8. 其实我们一直缺少领域专家,或者说我们缺少领域知识,所以我们一直被动的接受客户的驱使,而不是主动的说服客户。

  9. 您这篇博文让人比较清晰地了解了IoC的优势,遗憾的是它没有实现IoC所需要遵守的基本原则和基本手段,相信这也是作为一个公司的产品设计规划师比较核心的技术与经验了吧。

  10. 控制反转是重要,可能也是目前唯一有效的解决这一问题的方法。

    但是现实情况中,
    对于外包公司和厂商,挑选和培养用户非常重要,但同时又很难解决抵抗市场和竞争的引力,最后还是只管做完挣钱,而不考虑产品的长远价值和客户的长远利益。

    对于公司内部的开发部门,公司结构,公司政治和领导的气质都会影响这一方法的成功率。

    另外产品经理,技术leader和项目经理必须得有丰富的经验和很高的水准。你的选择必须首先是对的,长远的,考虑全局的。不然反转过来了最后也是悲剧

    所以路子是对的,能做到的个人或公司是极少的。对于强势的个人开发者,小型team或创业公司可能机会还大点。

  11. 就算是PC,难道不是以用户需求为基础设计出来的吗?
    不管是做产品还是做定制项目,都是以用户需求为本吧!
    内存硬盘容量越来越大,CPU越来越快,显卡越来越好,
    难道不是因为用户有大量的视频、照片要存储?
    难道不是因为用户喜欢的游戏越来越费资源?

  12. 不错, 但是普通程序员很难一步登天, 所以现实点的成功例子可能是先按照用户的需求给做出来, 当用户需要更高的显示性能时, 以此为契机把显卡模块化, 然后做更好的显卡; 后来又有用户要求更快的网卡, 则干脆标准化各种I/O接口了; 再然后, 在用户提出新需求之前, 主动模块化更多的东西. 我觉得这是比较适合普通程序员的路子, 不能要求所有公司老板所有程序员都是文艺青年 :p

  13. Pingback: 需求变化与IoC
  14. 程序员(分析人员)要成为客户领域的专家,引导客户,是很正确也很重要
    但是说反转什么的,又夸张了

  15. 文章太好了,仔细看完了,觉得很精彩,支持下,!!!辛卯年(兔)二月廿五 2011-3-29

  16. 微软,苹果不都是这么干的,而且乔布斯他从不问客户有啥需求;他觉得用户根本不知要什么;把自己做得够好ok;当然他是个在各方面都极其强势的人。。。太特例了。。。

  17. 其实……需求从来就没变过,提需求、做需求分析和软件设计的人没真正领会自己想要/面对的东西而已。

    所以,其实好的设计就是,知道/承认自己哪里不知道/不明白,然后仅仅依赖完全确定的地方做设计;不确定的,要么空着,要么通过一个通用性良好的接口去等待挂接“未来”的实现即可——后者就是所谓的依赖倒置。

    ——显然,所谓一步登天是不存在的。踏实就是一切。每一个细节上的踏实都会成为下一个细节的坚实基础,甚至下一层次的基础。这种踏实的基础越多,未来的升级/加速空间就越大。

    当然,有些公司根本就没打算出能用的产品。和他们就没什么道理好讲了。

  18. 举例来说吧,著名的unix/linux系泛文件思想,这看似一个很帅很高深的高层抽象,其实是个极其保守的、功能薄弱因而才无比稳固的基础设计。

    事实上,它几乎没有做任何抽象:反正计算机里面的任何事物,最终总逃不脱数据的输入或者输出;于是凡有输入和/或输出的东西它都把它叫文件。

    于是,GPU?光纤网?怎么支持?

    不支持就是最好的支持:反正除了你肯定有输入输出,别的它什么都不知道;至于你输入/输出的那一坨子东西,谁敢揽下,他就自己看着办,它只管打酱油……嗯,当然,谁打算揽下什么瓷器活,这点你得告诉它,这样它才好把麻烦事推出去。

    于是,它跑一边傻呵呵的管道、驱动、权限等等搞了一大坨,全是方便文件管理的,正经事一点没做:因为它不知道该怎么做。

    可就这么个傻呵呵的、一点知识没有的大老粗设计,成就了世界上最优秀最成功最具移植性的操作系统。

    反过来说也对: 如果它一开始就“知道”穿孔纸带机之类神奇的设备,那它一定活不到现在。

  19. 话说,这几天北京一直无法访问Coolshell呢,求教这几天怎么了?

    另外,@invalid 先生的观点不完全同意.
    真有需求无限变化的用户的.
    比如这两天终于可以放手的一个政府的项目.由于领导的各种诡异的拍脑袋,一个瀑布模型硬生生做成了原型模型..
    (我没有透漏技术细节吧?据说被查到后要坐牢的~)

  20. 为什么改需求? 因为你不知道客户想要什么,或者客户不知道他自己想要什么

  21. @Walkerinwind
    偶说过:“有些公司根本就没打算出能用的产品。和他们就没什么道理好讲了。”

    政府部门是有名的不做事的部门。你有办法定义“不做事”的人关于“提高做事效率”或“改善做事方法”的“需求”吗?

  22. 原来按配置买电脑,是厂商行为的控制反转,否则就失去领导地位了。
    但是如果说这是一种很差的用户体验呢?因为消费者根本就关心这些内容,他也不需要理解这些东西游戏就可以跑起来。

  23. pc这个例子不太好
    pc这个规范不是一下字制定出来的,是慢慢由业内专家、用户需求慢慢形成的现在这样的

  24. 我的理解
    从ioc的角度出发描述 PC架构 就是

    PC架构规定连接硬件的连接点(插槽或线)并连接点的数据通信协议。硬件插入后,因为硬件接口都符合标准通信协议,cup可以顺利地通过主板与硬件通信,调用硬件的功能。
    (简单的说,pc预留标准接口,硬件插入后,pc会调用其功能。)

    用户购买PC时,使用目的不同,但对pc的期待是一样的–利用其运算能力实现某个目的。若有用户找pc厂商说我想要个会飞的pc,pc厂商直接会让他去买玩具飞机,而不是努力迎合。

    软件开发中,难保客户不提出如此需求,但能让他去找B公司吗。

    所以我个人认为,软件开发以需求分析为出发点,架构只是实现需求的途径。
    贯穿始末的需求分析和迭代开发 是我 认为的重点。

  25. 试问,如果我想自己DIY一台电脑,那么照本文所说的该怎么定义概念呢。

    不过做软件,有时候很容易被外部环境所制约。

  26. 说的很对,去年做的一个项目我就是这么干的,不过当时对IoC的理解就如文中所说,现在才知道还可以上升到这个高度~

  27. 用户的需求不是买电脑,是玩魔兽。
    用户常常会把自己的解决方案当成需求提给你。

  28. “以愿景(自身利益是愿景的重要方面)为出发点,以架构为核心”,可否理解为技术人员为解决自身需求而开发产品?如:陈士骏为解决自己的视频分享需求而创建了youtube?

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注