需求又变了，怎么办？
先上一个轻松的段子：
程序员 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!