cat todd.log | grep programming | sort -r 需求变化与IoC 需求又变了，怎么办？

cat todd.log | grep programming | sort -r

 

需求变化与IoC

需求又变了，怎么办？

先上一个轻松的段子：

程序员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，这才算是融会贯通了。

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

architecture

需求变化与IoC

摘要: 要不被客户牵着鼻子走，需要自己有很强的设计能力，反过来让客户跟着你的设计来满足你的要求。这本质上就是软件设计中的控制反转(IoC)思想。IoC是每一个初级程序员向高级进阶所需要了解的最重要的设计思想。知道IoC概念的程序员不在少数，但不少人对于IoC的理解仅仅停留在通过依赖注入实现解耦这个层面。实际上，IoC的应用不仅包括解耦，它还是框架的基本原理，在非计算机领域，IoC也是无处不在。阅读全文

posted @ 2012-03-24 17:55 Todd Wei 阅读(1327) | 评论 (3) 编辑

多版本并发控制(MVCC)在分布式系统中的应用

摘要: 本文介绍了一种基于多版本并发控制（MVCC）思想的Conditional Update解决分布式系统并发控制问题的方法。和基于悲观锁的方法相比，该方法避免了大粒度和长时间的锁定，能更好地适应对读的响应速度和并发性要求高的场景。阅读全文

posted @ 2012-03-13 07:35 Todd Wei 阅读(1436) | 评论 (4) 编辑

海量用户积分排名算法探讨

摘要: 问题：为2亿用户规模的网站设计一种算法，在每次用户登录时显示其当前积分排名。本文介绍了一种树形分区设计，它具有几种优点：1. 分区结构稳定，不受积分分布影响；2. 每次查询或更新的复杂度为积分最大值的log(n)级别，且与用户规模无关，可以应对海量规模；3. 不依赖于SQL，容易改造为NoSQL等其他存储方式。阅读全文

posted @ 2012-03-01 10:05 Todd Wei 阅读(6595) | 评论 (42) 编辑

理解HTTP幂等性

摘要: 在数学中，幂等性是指N次变换与1次变换的结果相同。本文介绍了：1.分布式系统中幂等性的概念；2.用幂等设计代替分布式事务的方法；3.HTTP主要方法的语义和幂等性。阅读全文

posted @ 2011-06-04 20:51 Todd Wei 阅读(3762) | 评论 (15) 编辑

系统的层次性与单一职责原则

摘要: 职责层次性的背后是需求层次性，那么需求层次性又是哪里来的呢？需求层次性来源于设计！对于汽车的用户来讲，他的需求是汽车整体这个层次的，至于汽车部件的设计则不属于他所关心的范畴。而发动机、轮胎等需求来源于汽车设计者对汽车结构的设计，这就是说为满足高层系统需求所进行的设计产生了子系统的需求，而子系统的需求又进一步产生了子子系统的设计，呈现出了设计层次性。需求=>设计=>需求=>设计…，需求和设计就像鸡生蛋，蛋生鸡一样层层地细化，我们称这种设计方式为职责驱动设计。阅读全文

posted @ 2010-09-11 14:27 Todd Wei 阅读(1314) | 评论 (13) 编辑

系统的维次与层次

摘要: 目前社区流行一种通过剖析底层机制来分析事物的方法。剖析底层机制本身并没有错，只是千万不要把底层机制视为事物的全部。按系统多维与多层次的观点，正如把类图画得再完美也不过是程序的静态结构特征，程序的动态特征还需要序列图等来体现；底层机制属于实现维，而接口规范维是与之正交的。所以，单纯的底层机制剖析虽然貌似深入，其实犹如“盲人摸象”只执一端而已。阅读全文

posted @ 2010-07-11 00:25 Todd Wei 阅读(1073) | 评论 (1) 编辑

REST构架风格介绍之二：CRUD

摘要: REST是以资源为核心的，没有服务的概念，这的确让人怀疑REST能否像ORB或SOA一样支持复杂的应用？REST和以数据为核心的关系数据库是类似的。数据和资源本质上都是状态，对状态的操作CRUD少一个不行，多一个多余。因此，REST也采用CRUD四种标准操作，分别对应于HTTP协议的POST/GET/PUT/DELETE方法。阅读全文

posted @ 2009-05-09 09:11 Todd Wei 阅读(1804) | 评论 (4) 编辑

REST构架风格介绍之一：状态表述转移

摘要: REST(Representational State Transfer)是HTTP协议的作者Roy Fielding博士在其博士论文中提出的一种互联网应用构架风格。与以远程对象为核心的ORB和以服务为核心的SOA相比，以资源为核心的REST让我们从崭新的视角审视互联网应用。REST为互联网应用量身定做的简洁模型、与HTTP协议的完美结合、构架的高伸缩性，为互联网应用构架设计和异构系统集成设计带来了一股清新的空气。阅读全文

posted @ 2009-05-08 01:38 Todd Wei 阅读(3311) | 评论 (21) 编辑

3层构架.NET还缺点儿什么？

摘要: 经历了一个3层构建的.NET企业级开发项目以后，对比J2EE的开发经验，感觉.NET在3层构架里面缺了点儿什么东西。简单说来，是缺乏业务层的应用规范（EJB）和应用服务器（JBoss，WebLogic）。阅读全文

posted @ 2008-10-12 12:04 Todd Wei 阅读(3128) | 评论 (20) 编辑