|
|
文/Todd Wei
需求又變了，怎么辦？
先上一個輕松的段子：
程序員 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!
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
