軟件開發(fā)為什么如此之難？本文認(rèn)為這種困難與編程語言無關(guān)，因為現(xiàn)代的編程語言已經(jīng)足夠好了。那么，原因到底是什么？

有一種觀點(diǎn)認(rèn)為，使用更好的編程語言就會讓軟件開發(fā)變得更容易、更高效。在匯編或 Fortran 時代，這種觀點(diǎn)無疑是對的。然而，現(xiàn)代的編程語言已經(jīng)足夠好了，目前的主要困難和改進(jìn)機(jī)會出現(xiàn)在其他方面。編程仍然很難，但導(dǎo)致這種困難的原因卻與所使用的編程語言無關(guān)。

1.安達(dá)爾定律

當(dāng)你有一系列需要完成的連續(xù)性任務(wù)時，安達(dá)爾定律就會發(fā)揮作用。安達(dá)爾定律告訴我們，通過加快其中的一個任務(wù)來加快整個系列任務(wù)的速度是有硬性限制的。

例如，燒開水需要 10 分鐘，然后煮意大利面也需要 10 分鐘。即使你能夠找到一種可以更快把水燒開的方法，你做一頓飯的時間也絕對不會少于煮意大利面所需的 10 分鐘。

一般的公式是這樣的，如果某項任務(wù)的總時間占比是 p，那么你永遠(yuǎn)都無法獲得大于 1/(1-p) 的加速。假設(shè)任務(wù)的一部分占用了 90% 的時間，那么 p=0.90，將這個部分優(yōu)化到零時間，將使整個工作速度提高 1/(1-0.90)=10 倍。

安達(dá)爾定律的關(guān)鍵點(diǎn)在于，你所能獲得的加速受到了你所優(yōu)化部分的大小限制。

編程之所以困難，原因有很多。為了簡單起見，我們可以把困難的事情想象成必須按順序完成的任務(wù)。畢竟，人類并不擅長多任務(wù)處理。在任意一個時刻，你要么在使用構(gòu)建工具，要么在閱讀文檔，要么在編寫代碼或者參加會議。你一次只能應(yīng)對一項任務(wù)，所以安達(dá)爾定律大致適用。如果你設(shè)法將構(gòu)建時間降到零，那么項目的完成時間也只會短一點(diǎn)點(diǎn)。你的效率仍然受限于完成項目所需的其他事項。

過去，把一個程序翻譯成計算機(jī)可以運(yùn)行的東西是非常困難的。很久以前，需要先將程序轉(zhuǎn)成 1 和 0，然后再一個一個地輸入到計算機(jī)。我不知道這需要花費(fèi)多少時間，但為了便于討論，我們假設(shè)需要占用 90% 的時間。這意味著，如果有一種更好的方式來告訴計算機(jī)該做什么（比如 Python），那么編程效率將提高 10 倍。

現(xiàn)在，我們有了更好的編程語言，可以花更少的時間告訴計算機(jī)該做什么，生產(chǎn)力得到提升。將程序轉(zhuǎn)成代碼不再需要 90% 的時間，現(xiàn)在只需要 10% 的時間。這意味著我們可以從中獲得的最大改變是 1.11 倍，這比以前可以獲得的加速少 81 倍!

這是因為軟件開發(fā)其余的 90% 任務(wù)都是困難的任務(wù)，一個更好的編程語言不會讓它們變得更容易。

2.如何做到“沒朋友”

我的意思是，編程的難度與編程語言無關(guān)。為了理解其中的原因，我們先假設(shè)不需要操心與計算機(jī)相關(guān)的東西，你只需要告訴你的朋友要做些什么。你不能作弊，不能讓他們依賴常識性的東西，你必須替他們做出所有的決定。

你會發(fā)現(xiàn)，你需要花很多時間來解釋背景。你的朋友需要了解計算機(jī)程序要處理的東西在現(xiàn)實世界中是怎樣的，以及程序應(yīng)該要做什么。你需要解釋各種縮略詞和術(shù)語，需要討論一些外部因素。

你的朋友需要知道所有可能出現(xiàn)的情況，有大量的小細(xì)節(jié)需要處理，例如用戶不能在購物車中輸入負(fù)數(shù)個產(chǎn)品。用戶可能會嘗試做出所有可能的行為，會發(fā)生各種可能的事情，例如包裹在運(yùn)輸過程中弄丟了，你會發(fā)現(xiàn)有大量的邊界情況需要告訴你的朋友。

向你的朋友解釋這一切是很困難的。首先，你需要了解與項目相關(guān)的所有現(xiàn)實世界的細(xì)節(jié) (產(chǎn)品可能缺貨，可能有折扣，等等)。其次，你需要做出程序在各種可能的情況下應(yīng)該做什么的決定。第三，你需要以一種你的朋友能夠理解的方式與他們交流。這意味著你需要組織好你的想法，讓它們易于理解。如果你寫過文章或博客，你就會知道傳達(dá)大量的信息并不是一件容易的事情！

請注意，到目前為止，這些任務(wù)都還沒有涉及計算機(jī)，當(dāng)然也就不涉及編程語言。了解現(xiàn)實世界，了解程序應(yīng)該做什么，以及如何組織這些想法，這些都是非常困難的任務(wù)。

3.描述與規(guī)范

這里有一個容易就掉進(jìn)去的陷阱，人們很容易忽略描述與規(guī)范之間的區(qū)別。例如，當(dāng)你做出一個描述 (“一輛紅色的汽車”)，你可以測試一個東西是否符合這個描述 (“是的，它是紅色的，但它不是一輛汽車”)，但這不足以告訴你如何制造一輛汽車，因為制造汽車需要制造汽車的規(guī)范。

創(chuàng)造出一樣?xùn)|西需要做很多決定。如果你把每一個決定的結(jié)果都寫下來，就有了一個（未組織的）規(guī)范。開發(fā)程序需要你做出這些決定，所以僅僅進(jìn)行描述是不夠的——你需要一個規(guī)范。當(dāng)你做出一個描述 (“它需要把文件列出來”)，認(rèn)為它就是一個規(guī)范，卻忽略了你還需要做出其他無數(shù)個細(xì)小的決定 (“它應(yīng)該以什么順序列出文件？它們應(yīng)該按照自己的路線走下去嗎?”)。

當(dāng)你要開始寫一個程序時，你不得不面對這樣的現(xiàn)實，即你的規(guī)范實際上只是描述而已。電腦不會接受類似“畫一個矩形”這樣的描述，它需要知道矩形應(yīng)該出現(xiàn)在屏幕的什么地方，應(yīng)該多大，應(yīng)該是什么顏色的。將想法變成代碼，你還需要做出很多決定，而做出這些決定需要付出很大的努力。人們傾向于將這種努力歸咎于編程語言，卻不愿承認(rèn)這樣一個簡單的事實：僅給出描述是很難得到規(guī)范的。

4.回到計算機(jī)上來

開發(fā)軟件不僅僅是理解要做什么并將其轉(zhuǎn)化為代碼。計算機(jī)本身存在一些問題，這些問題也需要程序來解決。程序要能夠在硬件和網(wǎng)絡(luò)上快速運(yùn)行，可能需要處理機(jī)器故障，而工具和協(xié)議的復(fù)雜性帶來了更多問題。這些問題并非是在向計算機(jī)解釋應(yīng)該做什么的過程中造成的，它們都是原本就需要做出解釋的事情。

你需要在腦子里“運(yùn)行”部分程序。有時候，邏輯就像聽故事一樣容易理解，但有時候，事件順序和狀態(tài)跟蹤復(fù)雜到無法放在腦子里。獲得運(yùn)行正確的程序——或者糾正它們不正確的行為——需要了解程序在各種情況下的狀態(tài)。

寫代碼可以將你對程序的想法具體化，但程序不會保持一成不變。你會發(fā)現(xiàn) bug，想要新的特性，需要改變現(xiàn)有的行為。一個解決方案在一開始可能行得通，但這并不意味著它將一直是可行的。最終，你需要花時間去預(yù)測未來，去收拾爛攤子，你會不可避免地發(fā)現(xiàn)自己并沒有“千里眼”。

5康威定律

如果你自己不寫程序，就需要和其他人一起工作，這帶來了一系列全新挑戰(zhàn)。

所有參與項目的人都必須以某種方式組織起來，每個人都有自己的工作要做。你不希望人們互相妨礙，所以必須分工。合理的分工要求你對程序的結(jié)構(gòu)有很好的理解，這個時候康威定律就發(fā)揮作用了。

如果你有多個團(tuán)隊，事情就會變得更加困難。每個團(tuán)隊都有不同的目標(biāo)，因此會針對不同的事情進(jìn)行優(yōu)化。對其他團(tuán)隊有利的決定可能會阻礙你完成工作。了解其他人的立場，并找到一個好的妥協(xié)方案，這是一項艱難的任務(wù)，但你必須完成。

在大項目中，不可能有哪個團(tuán)隊（更不用說哪個人）能了解所有的東西，但你仍然需要弄清楚如何設(shè)計系統(tǒng)的各個部分，并讓這些部分相互配合，這比你自己做出整個設(shè)計要困難得多。

6“打破”定律

我們可以嘗試找到安達(dá)爾定律無法發(fā)揮作用的地方。如果個體任務(wù)的速度不是完全獨(dú)立的——如果你可以通過優(yōu)化一個任務(wù)來加快另一個任務(wù)——那么就有可能找到對你有幫助的解決方案。

更好的編程語言和開發(fā)環(huán)境可能是我們可以加以利用的地方。如果程序可以由更少的人來開發(fā)——比如說兩個人，而不是一個團(tuán)隊，或者一個團(tuán)隊，而不是一個部門——那就可以大大地減少組織方面的開銷。如果你自己實現(xiàn)接口所有的代碼，就不需要通過開會來決定如何設(shè)計接口。效率的提升不僅會降低編寫代碼的成本，還會改變工作的形式，從而降低其他任務(wù)的成本。也就是說，這里的限制變成了你可以在這條路上走多遠(yuǎn)，因為一個程序員不可能把所有跟實現(xiàn)業(yè)務(wù)相關(guān)的東西都裝進(jìn)腦子里。

迭代速度是另一個可以加以利用的杠桿。為了開發(fā)一個程序，你需要了解這個領(lǐng)域的問題和需要做出哪些決定。為了完成這些任務(wù)，你需要把收集到的所有細(xì)節(jié)都裝到腦子里，然后形成一個心理模型。這是一種可行的方法，但可能不是最有效的方法。另一種方法是基于某些明顯的細(xì)節(jié)建立一個小的心理模型，然后根據(jù)這個模型創(chuàng)建一個小程序來測試這些想法是否符合現(xiàn)實，并根據(jù)反饋進(jìn)行迭代，每次都創(chuàng)建出更豐富和更準(zhǔn)確的模型。這似乎更適合人們實際的學(xué)習(xí)方式。為了讓這種方法奏效，你需要能夠快速測試想法并獲得反饋。理想的狀態(tài)是，在你完成輸入后，新代碼就可以開始運(yùn)行。通過改變開發(fā)環(huán)境來實現(xiàn)更快的迭代周期，將使開發(fā)人員從第一種方法轉(zhuǎn)到第二種方法，幫助他們更好地理解問題。

一種表達(dá)能力更強(qiáng)的編程語言是否能有效地提高生產(chǎn)力，對于這一點(diǎn)我并不是特別樂觀。我希望的是能有更好的開發(fā)環(huán)境。如果我們有更好的工具來理解現(xiàn)有的代碼，有更快的開發(fā)迭代周期，繁瑣的工作變得更少，就可能會改變軟件的開發(fā)方式，并以一種復(fù)合而非遞減的方式給我們帶來回報。