2023年3月26日
todd
10,680 人閱讀
【感謝 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!
需求變化與IoC
2012年3月26日 todd 15,687 人閱讀 感謝 todd投遞本文 微博帳號 weidagang 需求又變了，怎麼辦？程式設計師xx遭遇車禍成植物人，醫生說活下來的希望只有萬分之一，喚醒更為渺茫。可他的lead和親人沒有放棄，他們根據xx工作如命的作風，每天都在他身邊念 xx，需求又改了，...
用敏捷方法應對需求變化
一 問題的提出 筆者近幾年一直從事資訊系統的開發，特別是有關國家機關和企業資訊系統的開發工作，取得了許多的經驗和教訓。其中乙個深切的體會是，需求的不斷變化，如果不能很好的應對，會導致整個專案的進度和質量都難以控制，最終使整個系統失敗。特別是在我國，使用者對於如何應用計算機軟體並沒有乙個成熟的經驗，在...
作團隊感悟 13 如何應對需求變化
本文出處 http blog.csdn.net sodme 前記 過去，在傳統軟體行業裡，開發的流程一般是 先作需求分析，然後確定功能，最後實施開發。也就是說，需求分析之後，需求基本就很少變了，會在相當長一段時間內，維持乙個穩定的需求。但是，在進入網際網路軟體時代後，事情已經發生了變化，僅就需求而言...