為什么說(shuō)軟件開(kāi)發(fā)過(guò)程是一個(gè)復(fù)雜過(guò)程

問(wèn)題的分類

最初在1999年被Dave Snowden開(kāi)發(fā)出來(lái)的Cynefin框架嘗試把世界上的問(wèn)題劃分到了5個(gè)域中（大類）：

簡(jiǎn)單（Simple）問(wèn)題，該域中的因果關(guān)系非常明顯，解決這些問(wèn)題的方法是 感知-分類-響應(yīng)（Sense-Categorise-Respond），有對(duì)應(yīng)的最佳實(shí)踐

復(fù)合（Complicated）問(wèn)題，該域中的因果關(guān)系需要分析，或者需要一些其他形式的調(diào)查和/或?qū)I(yè)知識(shí)的應(yīng)用，解決這些問(wèn)題的方法是感知-分析-響應(yīng)（Sense-Analyze-Respond），有對(duì)應(yīng)的好的實(shí)踐

復(fù)雜（Complex）問(wèn)題，該域中的因果關(guān)系僅能夠從回顧中發(fā)現(xiàn)，解決這些問(wèn)題的方法是探索-感知-響應(yīng)（Probe-Sense-Respond），我們能夠感知涌現(xiàn)實(shí)踐（emergent practice）

混亂（Chaotic）問(wèn)題，該域中沒(méi)有系統(tǒng)級(jí)別的因果關(guān)系，方法是行動(dòng)-感知-響應(yīng)（Act-Sense-Respond），我們能夠發(fā)現(xiàn)新穎實(shí)踐（novel practice）

失序（Disorder）問(wèn)題，該域中沒(méi)有因果關(guān)系，不可感知，其中的問(wèn)題也無(wú)法被解決

顯然，軟件開(kāi)發(fā)過(guò)程更多地是一個(gè)復(fù)雜（Complex）問(wèn)題。在一個(gè)產(chǎn)品被開(kāi)發(fā)出來(lái)之前，不確定性非常高，團(tuán)隊(duì)（包括業(yè)務(wù)人員和技術(shù)人員）對(duì)產(chǎn)品的知識(shí)也是最少的，而且需要大量的學(xué)習(xí)和嘗試才可以明確下一步可能的方向。不幸的是，很多時(shí)候我們需要在一開(kāi)始（不確定性最高的時(shí)候）就為項(xiàng)目做計(jì)劃。這種從傳統(tǒng)行業(yè)中非常適合的方法在軟件開(kāi)發(fā)領(lǐng)域不再適用，這也是敏捷開(kāi)發(fā)、精益等方法論在軟件開(kāi)發(fā)中更加適合的原因。

正因?yàn)檐浖_(kāi)發(fā)事實(shí)上是一個(gè)學(xué)習(xí)的過(guò)程，我們學(xué)習(xí)到的新知識(shí)反過(guò)來(lái)會(huì)幫助我們對(duì)問(wèn)題的定義，從而帶來(lái)變化。這里的變化可能來(lái)自兩個(gè)方向：功能性非功能性。

功能性的變化指隨著對(duì)業(yè)務(wù)的深入理解、或者已有業(yè)務(wù)規(guī)則為了匹配市場(chǎng)而產(chǎn)生的變化。比如支付方式由傳統(tǒng)的貨到付款變成了網(wǎng)銀付款，又變成了微信支付、支付寶掃碼等等。一個(gè)原始的電商平臺(tái)僅僅提供基本的購(gòu)物服務(wù)，但是后來(lái)可以根據(jù)已有數(shù)據(jù)產(chǎn)生推薦商品，從來(lái)帶來(lái)更大的流量。這些變化需要體現(xiàn)在已有的代碼中，而對(duì)代碼的修改往往是牽一發(fā)而動(dòng)全身。

非功能性的變化是指隨著業(yè)務(wù)的發(fā)展，用戶規(guī)模的增加，數(shù)據(jù)量的變化，安全認(rèn)知的變化等產(chǎn)生的新的需求。比如100個(gè)用戶的時(shí)候無(wú)需考慮性能問(wèn)題，但是100萬(wàn)用戶的時(shí)候，性能就變成了必須重視的問(wèn)題。天氣預(yù)報(bào)應(yīng)用的數(shù)據(jù)安全性和網(wǎng)絡(luò)銀行的數(shù)據(jù)安全性要求也大不相同。

而在業(yè)務(wù)提出一個(gè)需求的時(shí)候，往往只是一個(gè)簡(jiǎn)化過(guò)的版本。

非功能性復(fù)雜性

這是一個(gè)經(jīng)過(guò)設(shè)計(jì)師精確設(shè)計(jì)的界面，在它被設(shè)計(jì)出來(lái)之前，用戶事實(shí)上無(wú)法準(zhǔn)確的描述出它。設(shè)計(jì)過(guò)程中經(jīng)歷了很多的諸如：

• 線框圖

• 顏色的確定

• 交互的動(dòng)畫(huà)

• 信息層次

往復(fù)多次之后，界面確定了。在沒(méi)有仔細(xì)思考使用場(chǎng)景的時(shí)候，開(kāi)發(fā)會(huì)誤以為這個(gè)功能非常簡(jiǎn)單。但是如果你是一個(gè)有經(jīng)驗(yàn)的開(kāi)發(fā)者，很快會(huì)想到的一些問(wèn)題是：

• 在寬屏下如何展示

• 在平板上如何展示

• 在手機(jī)上如何展示

• 即使僅僅支持桌面版，跨瀏覽器要考慮嗎？支持哪些版本？

• 有些UI效果在低版本的瀏覽器上不工作，需要Shim技術(shù)

除此之外，依然有大量的其他細(xì)節(jié)需要考慮：

• 性能要求是什么樣的？

• 安全性要考慮嗎？

• 在網(wǎng)絡(luò)環(huán)境不好的時(shí)候，要不要fallback到基礎(chǔ)視圖？

• 既然涉及發(fā)送邀請(qǐng)函，送達(dá)率如何保證

• 與外部郵件服務(wù)提供商集成時(shí)的工作量

等等。這些隱含的信息需要被充分挖掘出來(lái)，然后開(kāi)發(fā)者才能做一個(gè)合理的評(píng)估，而且這還只是開(kāi)始。一旦進(jìn)入開(kāi)發(fā)階段，很多之前沒(méi)有考慮到的細(xì)節(jié)開(kāi)始涌現(xiàn)：字體的選用，字號(hào)，字體顏色，元素間的間距等等，如何測(cè)試郵件是否發(fā)送成功，多個(gè)角色之間的conversation又會(huì)消耗很多時(shí)間。

需求的變化方向

作為程序員，有一天你被要求寫(xiě)一段代碼，這段代碼需要完成一件很簡(jiǎn)單的事：

1. 打印”Hello, world”5次

很容易嘛，你想，然后順手就寫(xiě)下了下面這幾行代碼：

print("Hello, world")
print("Hello, world")
print("Hello, world")
print("Hello, world")
print("Hello, world")

不過(guò)，拷貝粘貼看起來(lái)有點(diǎn)低端，你做了一個(gè)微小的改動(dòng)：

for(var i = 0; i < 5; i++) {
 print("Hello, world")
}

看起來(lái)還不錯(cuò)，老板的需求又變成了打印”Goodbye, world”5次。既然是打印不同的消息，那何不把消息作為參數(shù)呢？

function printMessage(message) { for(i = 0; i < 5; i++) {
   print(message);
 }
}

printMessage("Hello, world")
printMessage("Goodbye, world")

有了這個(gè)函數(shù)，你可以打印任意消息5次了。老板又一次改變了需求：打印”Hello, world”13次（沒(méi)人知道為什么是13）。既然次數(shù)也變化了，那么一個(gè)可能是將次數(shù)作為參數(shù)傳入：

function printMessage(count, message) { for(i = 0; i < count; i++) {
   print(message);
 }
}

printMessage(13, "Hello, world");
printMessage(5, "Goodbye, world");

完美，這就是抽象的魅力。有了這個(gè)函數(shù)，你可以將任意消息打印任意次數(shù)。不過(guò)老板是永遠(yuǎn)無(wú)法滿足的，就在這次需求變化之后的第二天，他的需求又變了：不但要將”Hello, world”打印到控制臺(tái)，還要將其計(jì)入日志。

沒(méi)辦法，通過(guò)搜索JavaScript的文檔，你發(fā)現(xiàn)了一個(gè)叫做高階函數(shù)的東東：函數(shù)可以作為參數(shù)傳入另一個(gè)參數(shù)！

function log(message) {
 system.log(message);
}

function doMessage(count, message, action) { for(i = 0; i < count; i++) {
   action(message);
 }
}

doMessage(5, "Hello, world", print);
doMessage(5, "Hello, world", log);

這下厲害了，我們可以對(duì)任意消息，做任意次的任意動(dòng)作！再回過(guò)頭來(lái)看看那個(gè)最開(kāi)始的需求：

1. 打印”Hello, world”5次

稍微分割一下這句話：打印，”Hello, world”，5次，可以看到，這三個(gè)元素最后都變成了可以變化的點(diǎn)，軟件開(kāi)發(fā)很多時(shí)候正是如此，需求可能在任意可能變化的方向上變化。這也是各種軟件開(kāi)發(fā)原則嘗試解決的問(wèn)題：如何寫(xiě)出更容易擴(kuò)展，更容易響應(yīng)變化的代碼來(lái)。

小結(jié)

軟件的復(fù)雜性來(lái)自于大量的不確定性，而這個(gè)不確定性事實(shí)上是無(wú)法避免的，而且每個(gè)軟件都是獨(dú)一無(wú)二的。另一方面，軟件的需求會(huì)以各種方式來(lái)變化，而且往往會(huì)以開(kāi)發(fā)者沒(méi)有預(yù)料到的方向。比如上面這個(gè)小例子中看到的，最后的需求可能會(huì)變成將消息以短信的方式發(fā)送給手機(jī)號(hào)以185開(kāi)頭的用戶手機(jī)上。