需求又變了，怎么辦？
最近微博上流行一個段子：
程序員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!