多開發(fā)者認為,，編程的難度依然非常大,，但是這些困難與編程語言無關，本篇主要介紹了軟件開發(fā)的難點,，通過發(fā)現這些問題,，來及時找到自己的問題。

有的人認為,，一款好的編程語言可以減輕軟件開發(fā)者身上的負擔,，且能夠相應地提高他們的效率。

毫無疑問,，這一點在很久前的匯編與 Fortran 時代確實如此,。

然而，如今編程語言已經足夠好了,，我們仍然面臨著一些其他方面的困難與挑戰(zhàn),。時下，很多開發(fā)者認為,，編程的難度依然非常大,，但是這些困難與編程語言無關，原因有以下幾點。

阿姆達爾定律

在需要執(zhí)行一系列的任務時,，我們就會想起阿姆達爾定律,。這條定律告訴我們，僅通過加速某一項任務而獲得的整體速度提升有硬性限制,。

假設把水燒開需要10分鐘,，然后煮面條也需要10分鐘。即便你找到一種方法加快燒開水的速度,，做飯的時間也不會少于10分鐘,。任憑爐子再旺，也不可能將做飯的速度提高到兩倍,。

該定律的數學公式為：假設某件事的總時間比為p,，則你永遠無法獲得大于1/(1 – p)的加速比。假設這部分工作占用了90%的時間,，即p = 0.90,，在優(yōu)化的過程中，如果將這部分的時間降至0,，則整體的工作速度將提高1/(1 – 0.90) = 10倍,。

阿姆達爾定律的關鍵在于，你能夠獲取的最大速度提升受限于優(yōu)化的工作所占的比例,。

造成編程工作難度非常大的原因有很多,。簡單來說，我們可以認為這是由于我們需要處理的工作必須按照一定的順序完成,。畢竟人類不是很擅長同時處理多項任務,。

在某個時間點，你可能在使用構建工具,、閱讀文檔,、編寫代碼或參加會議,。當然你也有可能在開會的時候忘我地寫代碼,，但你只能做一樣工作，無法同時兼顧寫代碼和開會,。因此,，我們可以應用阿姆達爾定律，假設你能設法將構建時間降至0,，但項目的整體速度也只能加快一點點,。你的工作效率仍然會受到其他因素的限制。

曾經,，將程序轉化成計算機可以運行的代碼非常困難,。很久以前，我們甚至需要將程序轉換成1和0，然后不厭其煩地將其輸入到計算機,。我不知道這中間需要花費多少時間,，但我們可以假設這項工作占據了90%的編程時間。

這意味著,，如果我們能找到一種更好的辦法（比如Python）告訴計算機干什么,，就可以將編程效率提高10倍之多。

然而,，如今我們的編程語言越來越好了,，告訴計算機干什么的時間也越來越少了，將程序轉化成代碼也不需要花費90%的時間了,。假設現在我們只需要10%的時間,。這意味著，如今即便將這部分工作的時間降至0,，也只能提高1.11倍的效率,。效率提升比以前減少了81倍。

這是因為其余90%的軟件開發(fā)工作都是非常艱巨的任務,，即便編程語言再好也無法（直接）減輕我們的負擔,。

為什么編程的工作還是這么難？

傳達需求

這里我所說的編程工作很難,，實際上與編程語言毫無關系,。為了找出其中的原因，暫時假設我們完全不使用計算機,。你無需告訴計算機做什么,，但你需要告訴你的朋友該做什么。別作弊,，也不能告訴你的朋友自己看著辦,，你必須為他們做所有的決定。

你會發(fā)現,，你需要花費大量時間才能解釋清楚關鍵的背景信息,。你的朋友需要了解程序需要處理的現實問題，以及你認為該程序應該提供哪些功能,。你必須解釋清楚所有的縮寫字母和術語,，而且還需要討論各種外部因素。

你的朋友需要知道所有可能出現的情況,，需要處理的細節(jié)非常多,。

同時，你還需要考慮不同功能的狀態(tài)兩兩組合,，用戶可能會嘗試的各種動作,，以及所有可能出現的事件,，你需要與朋友討論大量的極端情況。

向你的朋友解釋清楚這一切的難點有好幾個,。首先,，你必須掌握所有的實際細節(jié)；其次,，你必須了解程序在每種情況下應該執(zhí)行的操作,；再者，你必須通過朋友能夠理解的方式來傳達所有的信息,。這意味著你必須有條理地組織這些信息,，以確保便于理解。

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

描述與規(guī)格

我們很容易搞混描述與規(guī)格之間的區(qū)別,，這是一個我們經常會踏入的思維陷阱。如果你只有一段描述（“紅色汽車”）,，則你可以測試實際情況是否符合該描述（“是紅色,，但不是汽車”），但是這段描述并不足以傳達如何制造一輛汽車,。而這就是規(guī)范的用途,。

創(chuàng)造事物需要做出很多決定。如果記錄下每個決策的結果,，就會得到一份（雜亂無章的）規(guī)范,。編寫程序的時候，你需要做出這樣的決定,，因此僅憑描述還不行,，你需要一份規(guī)范。在看到一段描述（“列出文件”）時,，我們很容易認為這是一個規(guī)范,，因此我們覺得應該能夠告訴計算機執(zhí)行該動作,。但實際上,，這中間有大量的決定需要考慮（“文件應以什么順序列出？每個文件一行嗎,？”）

在編寫程序的時候,，你拿到的規(guī)范常常只是一段描述,。計算機無法“繪制矩形”，它必須知道這個矩形的顯示位置,、大小以及顏色,。在編寫這段代碼的時候，你會發(fā)現很多尚未做出的決定,。做這些決定需要付出很多努力,。我們經常會弄錯引發(fā)這些工作的緣由，將其歸咎于編程語言,，但其實這只是因為我們很難根據一段描述創(chuàng)建規(guī)范,。

計算機本身

下面，說回計算機,。開發(fā)軟件不僅僅是了解軟件應該做什么,，并將各種想法轉變成代碼。計算機本身也有很多程序必須解決的問題,。你的程序必須在硬件和網絡上快速地運行,。程序需要處理機器故障。而工具和協議的復雜性導致該領域所要面對的問題更多,。這些困難都不是由向計算機解釋做什么的過程引起的,，它們也是需要解釋的事情。

另外,，你需要在腦海中運行某些程序,。有時邏輯很容易理解，但有時你無法將一系列的事件和狀態(tài)盡數塞入腦海中,。為了正確理解程序的詳細信息,，在出現錯誤的情況下修復程序，你需要了解各種情況下程序本身的狀態(tài),。

編寫代碼的過程,，可以讓你清楚地掌握程序的工作方式。然而,，程序永遠不會停止變化,。你會發(fā)現錯誤、添加新功能或修改現有的行為,。即便程序最初的組織方式非常有效,，但也不意味著它的結構永遠正確。你需要花費時間組合各種情況,，考慮未來的需求,，并在出現意外的時候收拾爛攤子。

人員合作

很多時候,，我們需要與其他人合作編寫程序,，而這也會帶來挑戰(zhàn),。

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

如果你有多個團隊,，則情況會更復雜。每個團隊都有不同的目標,，因此你必須權衡各個方面,。有時，某個決定非常利于其他團隊,，但會阻礙你的工作,。設身處地為他人著想，并找到合理的妥協方案是非常艱難的工作,，但必須完成,。

在大型項目中，沒有任何一個團隊能夠了解整個系統(tǒng),，更不用說一個人了,。但是，你依然需要弄清楚系統(tǒng)的各個部分是如何設計的,，又是如何組織到一起的,。這比你自己承擔起整個設計還要難。

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

如何解決軟件開發(fā)的外在難題？

我們可以尋找一些不受阿姆達爾定律限制的方法,。如果各個任務的速度不是完全獨立的（比如優(yōu)化一個任務能夠加快另一個任務的速度）,，我們就有希望通過技術解決方案改善這個問題。

我們需要更好的語言和開發(fā)環(huán)境,。如果我們可以用更少的人編寫程序（比如兩個人能代替整個團隊,，或者一個團隊代替一個部門），則可以大大削減組織規(guī)模,。如果由同一個人來編寫接口的前后臺,，就不需要開會討論了。生產率的提升不僅可以降低編寫代碼的成本,，而且還會改變工作的方式,，從而降低其他工作的成本。雖說如此,，但這種方式也有局限性,，因為程序員無法將所有業(yè)務都納入他們的腦海中。

迭代速度是另一個杠桿,。為了編寫程序,，你需要了解領域知識以及需要做出的決定。為此,，你需要了解所有細節(jié),，然后建立一種思維模型。雖然這種方法可行,，但可能不是最有效的方法,。還有一種方法，根據一些顯而易見的細節(jié),，構建一個小型的思維模型,。

然后，根據這個模型創(chuàng)建一個小程序,，并實際驗證這個思維模型,。然后根據得到的反饋進行迭代，這樣每次創(chuàng)建的模型就會越來越豐富,，越來越準確,。這種方法似乎更好，因為它更符合人們學習的過程,。為了保證這種方法的有效性,，你需要快速測試并獲得反饋。理想狀態(tài)是在輸入完代碼后,，新的代碼就立即開始運行,。改變開發(fā)環(huán)境，實現更快的迭代周期,，可以讓開發(fā)人員從第一種方法轉變成第二種,，從而幫助他們理解問題。

更具表現力的編程語言是否能夠顯著地提高生產力,？我并不是很樂觀,。然而，我認為仍然有可能出現更好的開發(fā)環(huán)境,。如果我們能通過更好的工具來理解現有代碼,，實現更快的開發(fā)迭代周期，并減少繁瑣的“體力”勞動,，就有可能改變軟件開發(fā)的方式,，并從多方面改善我們的工作。

文章來源：網絡  版權歸原作者所有

上文內容不用于商業(yè)目的,，如涉及知識產權問題,，請權利人聯系小編,，我們將立即處理