需求变化与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.cn ,请勿用于任何商业用途)
相关推荐
人物 _ 陈皓:自信源于专业 APT 安全开发 安全架构 数据安全 APT
征文 _ 陈皓:年度安全规划–“我们不一样” 渗透测试 自动化 安全防护 物联网安全业务安全
前在#研发实践#主题论坛演讲的是酷壳博主、亚马逊高级研发经理陈皓,他给我们带来了《高并发互联网应用性能优化实践》,演讲中提出一个新的观点——节省资源,少用资源,你的程序可能会跑得更快。还解析扩展的三个...
关于铁道部的火车票网络订票系统,这些天招致的骂声不断,当然,除了发泄...(这又是一篇长文,只讨论性能问题,不讨论那些UI、用户体验、或是否把支付和购票下单环节分开的功能性的东西)任何技术都离不开业务需求,
作者:陈皓 整理:祝冬华 来源网络,希望能与大家分享这份学习资料,资源分数也设置了最低值,如有侵权,请联系我删除文件。 第一部分、概述 (6) 第二部分、关于程序的编译和链接 (6) 第三部分、Makefile 介绍 (7) ...
陈皓勇:新时代电力系统科研创新探路者.pdf
这篇文章必然是有争议的,我在我的微博上讨论过很多次了,每次都是很有争议的。有不同的观点,有争论总是一件好事,这样可以引发大家的思考。所以,对于我的这篇博文,如果你赞同我的观点,我会感到高兴,如果你会去...
本篇总结了在用C/C++语言(主要是C语言)进行程序写作上的三十二个“修养”,通过这些,你可以写出质量高的程序,同时也会让看你程序的人渍渍称道,那些看过你程序的人一定会说:“这个人的编程修养不错”。
跟我一起写Makefile (PDF 重制版) 作者: 陈皓 2021 年04 月06 日
Linux相关:跟我一起写 Makefile 作者:陈皓 整理:祝冬华
什么是makefile?或许很多Winodws的程序员都不知道这个东西,因为那些Windows的IDE都为你做了这个工作,但我觉得要作一个好的和professional的程序员,makefile还是要懂。...特别在Unix下的软件编译,你就不能...——陈皓
20210423-中银国际-基金专题报告:均衡成长型基金经理侧写~陈皓.pdf
讲的还不错,权当学习、借鉴一下别人的编程风格了。
文根据InfoQ中文站跟陈皓(@左耳朵耗子)在2014年3月的一次聊天内容整理而成。在沟通中,陈皓分享了自己对云计算的理解,包括云计算为什么会分三层,实现一个云平台的难点在什么地方,运维之于云计算的重要性,电商...
编译器需要的是语法的正确,函数与变量的声明的正确。对于后者,通常 是你需要告诉编译器头文件的所在位置(头文件中应该只是声明,而定义应该 放在 C/C++文件中),只要所有的语法正确,编译器就可以编译出中间目标...
leetcode, 400题+, 最全解答源码, 详细注释updated 2017-08-12, by 陈皓 左耳多耗子, C++\C\Java .
跟着大神一起学写makeFile文件,通俗易懂,如果静下心能看完保准收获颇丰. 感谢大神的付出.
Cloud Native 云化架构,微服务架构的演进历史,运用,结构
GDB调试程序[陈皓] GDB调试工具指南 两个pdf文件
make是一个命令工具,它解释Makefile 中的指令(应该说是规则)。在Makefile文件中描述了整个工程所有文件的编译顺序、编译规则。Makefile 有自己的书写格式、关键字、函数。像C 语言有自己的格式、关键字和函数一样...