為什么軟件開發這么難？

　有些人認為，一種好的編程語言可以減輕軟件開發人員的負擔，并相應地提高他們的效率。

毫無疑問，這在很久以前的匯編和Fortran時代是真的。

　　然而，現在編程語言已經足夠好了，我們仍然面臨著其他一些困難和挑戰。目前，許多開發人員認為編程仍然非常困難，但這些困難與編程語言無關，原因如下。

1.阿姆達爾定律。

當我們需要執行一系列任務時，我們會想到阿姆達爾定律。這條法律告訴我們，僅通過加快某項任務獲得的整體速度提高是有限的。

假設燒開水需要10分鐘，然后煮面條需要10分鐘。即使你找到了加快沸水速度的方法，烹飪時間也不會少于10分鐘。無論爐子有多旺，烹飪速度都不可能翻倍。

該定律的數學公式是：如果某件事的總時間比為p，您將永遠無法獲得超過1/（1-p）的加速比。假設這部分工作占90%，即p=0.90。在優化過程中，如果這部分時間減少到0，整體工作速度將提高1/（1-0.90）=10倍。

阿姆達爾定律的關鍵在于，您可以獲得的大速度提升僅限于優化工作的比例　

編程工作困難的原因有很多。簡單地說，我們可以認為這是因為我們需要處理的工作必須按照一定的順序完成。畢竟，人類并不擅長同時處理許多任務。在某個時間點，你可能會使用建筑工具、閱讀文檔、編寫代碼或參加會議。當然，你也可能會在會議上無私地寫代碼，但你只能做同樣的工作，而不能同時寫代碼和會議。因此，我們可以使用阿姆達爾定律，假設您可以將施工時間降低到0，但項目的整體速度只能稍微加快一點。您的工作效率仍將受到其他因素的限制。

曾經，很難將程序轉換為計算機可以運行的代碼。很久以前，我們甚至需要將程序轉換為1和0，然后不厭其煩地將其輸入計算機。我不知道這需要多長時間，但我們可以假設這項工作占編程時間的90%。這意味著，如果我們能找到更好的方法（如Python）告訴計算機該做什么，我們可以將編程效率提高10倍以上。

然而，現在我們的編程語言越來越好，告訴計算機做什么的時間也越來越少。將程序轉換為代碼不需要90%的時間。假設我們現在只需要10%的時間。這意味著，即使這部分工作時間減少到0，效率也只能提高1.11倍。效率比以前低了81倍。

這是因為其他90%的軟件開發是一項非常艱巨的任務，無論編程語言有多好，不能（直接）減輕我們的負擔。

　　2.為什么編程還這么難？

　　傳達需求

我在這里說的編程工作很困難，但實際上與編程語言無關。為了找出原因，暫時假設我們根本不使用電腦。你不需要告訴電腦該做什么，但你需要告訴你的朋友該做什么。你不能告訴你的朋友你必須為他們做出所有的決定。

　　你會發現解釋關鍵的背景信息需要很多時間。你的朋友需要了解程序需要處理的實際問題，以及你認為程序應該提供什么功能。你必須解釋所有的縮寫字母和術語，并討論各種外部因素。

你的朋友需要知道所有可能的情況，有很多細節需要處理。

　　同時，你還需要考慮不同功能的狀態，用戶可能嘗試的各種動作，以及所有可能的事件，你需要和你的朋友討論很多極端的情況。

向你的朋友解釋這一切有幾個困難。首先，你必須掌握所有的實際細節；其次，你必須了解程序在每種情況下應該執行的操作；此外，你必須通過你的朋友能夠理解的方式傳達所有信息。這意味著你必須組織這些信息，以確保易于理解。

　　請注意，到目前為止，我們甚至還沒有提到計算機，當然，我們也沒有提到編程語言。理解需求，掌握程序應該做什么，以及組織表達是一項非常困難的任務。

描述與規格

　　我們很容易混淆描述和規格之間的區別，這是我們經常進入的思維陷阱。如果你只有一個描述（紅色汽車），你可以測試實際情況是否符合描述（紅色，但不是汽車），但這個描述不足以傳達如何制造汽車。這就是標準化的目的。

創造事物需要做出很多決定。如果你記錄每個決定的結果，你就會得到一個（混亂的）規范。在編寫程序時，你需要做出這樣的決定，所以僅僅通過描述是不夠的，你需要一個規范。當我們看到一個描述（列出文件）時，我們很容易認為這是一個規范，所以我們認為我們應該能夠告訴計算機執行這個動作。但事實上，有很多決定需要考慮（文件應該按什么順序列出？每個文件都有一行嗎？

在編寫程序時，你得到的規范通常只是一個描述。計算機不能繪制矩形，它必須知道矩形的顯示位置、大小和顏色。當你編寫這個代碼時，你會發現很多尚未做出的決定。做出這些決定需要付出很多努力。我們經常犯錯誤，把這些工作歸咎于編程語言，但這只是因為我們很難根據描述創建規范。

　　計算機本身

　　現在，讓我們回到計算機上。開發軟件不僅僅是為了了解軟件應該做什么，并將各種想法轉換為代碼。計算機本身也有許多程序必須解決的問題。您的程序必須在硬件和網絡上快速運行。該程序需要處理機器故障。工具和協議的復雜性使該領域面臨更多的問題。這些困難不是由向計算機解釋該做什么的過程造成的，它們也需要解釋。

此外，你需要在腦海中運行一些程序。有時邏輯很容易理解，但有時你不能把一系列的事件和狀態都塞進腦海里。為了正確理解程序的詳細信息，在錯誤的情況下修復程序，您需要了解程序本身在各種情況下的狀態。

　　編寫代碼的過程可以讓你清楚地掌握程序的工作方法。然而，這個程序永遠不會停止改變。你會發現錯誤，添加新的功能或修改現有的行為。即使最初的組織方法非常有效，這并不意味著它的結構總是正確的。你需要花時間結合各種情況，考慮未來的需求，并在事故發生時清理混亂。

　　人員合作

　　很多時候，我們需要與他人合作編寫程序，這也會帶來挑戰。

所有的團隊成員都必須各司其職。為了不妨礙他們之間的工作，你必須分工。為了建立合理的分工，您首先需要了解程序的結構（請參見康威定律）。

如果你有多個團隊，情況會更復雜。每個團隊都有不同的目標，所以你必須權衡各個方面。有時，一個決定對其他團隊非常有益，但它會阻礙你的工作。很難設身處地為他人著想，找到合理的妥協計劃，但必須完成。

　　在大型項目中，沒有一個團隊能理解整個系統，更不用說一個人了。然而，您仍然需要了解系統的各個部分是如何設計和組織的。這比你自己承擔整個設計要困難。

雖然與人打交道并不是真正意義上的編寫代碼，但它也是軟件開發中非常重要的一部分。

　　3.如何解決軟件開發的外部問題？

　　我們可以找到一些不受阿姆達爾法律限制的方法。如果每個任務的速度不是完全獨立的（例如，優化一個任務可以加快另一個任務的速度），我們希望通過技術解決方案來改善這個問題。

我們需要更好的語言和發展環境。如果我們可以用更少的人編寫程序（例如，兩個人可以取代整個團隊，或者一個團隊可以取代一個部門），我們可以減少組織規模。如果同一個人編寫接口的前后平臺，則無需開會討論。生產率的提高不僅可以降低編寫代碼的成本，還可以改變工作方式，從而降低其他工作的成本。盡管如此，這種方法也有局限性，因為程序員無法將所有業務納入他們的腦海。

迭代速度是另一個杠桿。你需要知道如何編寫程序。