作者丨Peter Wayner

譯者 | 晶顏

審校 | 重樓

軟件開發是一門具有挑戰性的學科，它建立在數以百萬計的參數、變量、庫以及更多必須絕對正確的因素之上。即便是一個字符不合適，整個堆棧也會隨之瓦解。

多年來，軟件開發團隊已經想出了一些完成工作的規則。從復雜的方法論到新興的學科和哲學，軟件開發的規則手冊使每個人都能夠協作，并以有效的方式到達終點。然而，即便如此，仍然存在失敗模式：有時是這些方法被誤用了，或是好的想法過于偏向理論化；有時開發者只是忘記了他們應該做什么，或是故意為之。

軟件開發中的這些錯誤幾乎可以破壞任何項目。因此，如果想要確保您的團隊能夠構建偉大的項目，那么是時候停下來考慮一下以下錯誤行為了。

1、選擇錯誤的方法   

所有的軟件開發方法都有狂熱的擁躉，他們熱衷于那些定義自己最喜歡的團隊組織方式的規則。但問題往往是如何為您的團隊選擇合適的工具。

一個很大的錯誤是從高層強加這些規則。如果程序員是另一種方法的忠實信徒，那么當他們被迫使用另一種方法時，他們通常會抱怨和發牢騷。另一個錯誤是讓程序員自由地選擇他們最喜歡的方法，然而這可能并不是對整個團隊最好的方法。

選擇正確的方法并不能解決所有的問題，但是它可以減少組織工作流程時產生的摩擦。團隊將了解他們的角色，以及他們將如何在其中編寫代碼。

2、忽略可擴展性   

一些軟件開發問題可以稍后修復，但這絕不包括構建一個能夠有效擴展以處理數百萬或數十億個事件的應用程序。當應用程序最終全面運行時，創建沒有瓶頸的有效代碼需要足夠的深謀遠慮和高層領導的支持。這不是以后用一些有針對性的編碼和虛擬管道就能解決的問題。

算法和數據結構需要從一開始就進行規劃。這意味著架構師和管理層需要仔細考慮將為每個用戶存儲和處理的數據。當100萬或10億用戶出現時，信息洪流會淹沒哪一層？我們該如何提前為這些時刻做好計劃呢？

有時候，這種架構上的深謀遠慮意味著扼殺一些偉大的想法。有時，管理層需要權衡大規模交付功能的收益和成本。有些數據分析在大范圍內并不適用。一些公式隨著用戶的增加呈指數級增長。計算使硬件不堪重負，并阻塞了通信。

開發者并不總是想要考慮大局。他們很容易就會一頭扎進去開始創作。但是聰明的開發團隊和管理者會花時間預測這些問題，因為如果他們不這樣做，就會面臨失敗的結局。

3、沉迷最新趨勢   

眾所周知，軟件開發人員很容易被新奇的想法所吸引。也許它是一種提供更復雜查詢的新型數據庫；也許它是一種新的編程語言，可以修復舊語言造成的所有錯誤。

有時候這些想法是有價值的。然而，很多時候，由于每個人都試圖學習新技術，最終會減慢開發速度。有時候，新想法中會存在隱藏的缺陷，只有在項目必須交付之前，每個人都投入到工作中之后，這些缺陷才會顯現出來。

謹慎往往是采用新技術的最佳準則。這也是一些規模最大、歷史最悠久的公司仍在繼續運行由COBOL編寫的軟件的原因所在。趨勢變化無常，但運行代碼中的工作邏輯不會過時。

4、保留過多的數據   

程序員是天生的囤積狂，他們喜歡儲存信息以備不時之需，而此舉可能會導致安全漏洞或侵犯用戶隱私。

對于出生日期或其他詳細個人信息，問題可能更大。一些領域（如財務記錄或健康記錄）受到嚴格監管，更容易違反規定。

好的軟件架構需要提前計劃，以盡量減少存儲的數據量。它可以保護每個人，并節省存儲費用，甚至可以通過減少移動數據量來加快系統速度。

5、外包錯誤的工作   

關于究竟是自行構建還是購買軟件的爭論由來已久，目前尚無明確定論。然而，軟件開發人員的選擇往往很糟糕。也許有一個價格合理的完美解決方案，但他們卻不舍得把自己的定制堆棧與內部團隊閑置一邊。相反的情況也會發生。一些管理者購買了外部供應商的產品線，結果卻眼睜睜地看著供應商在鎖定完成后大幅提高價格。

不幸的是，對于軟件開發團隊及其管理者來說，決定使用哪種外部工具是一個持續的挑戰。利用合適的外部資源是天才之舉，但選擇了錯誤的供應商則是通往高價監獄的門票。

6、忽略測試   

高效的軟件開發人員及其管理者都知道，測試是一個持續的挑戰，就像編寫遞歸代碼或設計優雅的數據結構一樣，是工作的一部分。測試過程應該從一開始就包含在內，因為單元測試和集成測試對于確保代碼在整個開發過程中保持可行性至關重要。

測試對于處理大規模負載也很重要。當我們是唯一的用戶時，編寫在桌面上運行順暢的代碼十分容易。如果應用程序擁有數百、數千甚至數十萬用戶，則需要確保代碼是高效的，且部署能夠處理大規模負載。

許多團隊會引入質量保證測試人員，以發現并糾正程序員所犯的錯誤。比如說，他們知道如何將一個參數設置為0，只是為了看看它是否會導致除0錯誤（divide-by-zero error）。當用例變得如此復雜，以至于任何一個人都很難想到所有的變化并編寫干凈的代碼來預測它們時，這種對測試的持續關注是必不可少的。

7、低估了計劃的力量   

大多數代碼在構建前期都需要進行一定的計劃。但大多數程序員通常只是想直接進入并開始編寫代碼。

資深程序員的經驗告訴我們，最好的步驟是停下來，計劃，測試計劃，然后再完善計劃。寫計劃可能看起來很乏味，但當你進行抽象思考時，嘗試新想法的速度可能會快10倍。

計劃還意味著包括來自其他團隊和涉眾的輸入。他們將是將來使用代碼的人，因此花時間討論項目并了解他們的需求，將在之后避免大量的挫折。這是避免上述列出的許多錯誤的最好方法。

參考鏈接：https://www.cio.com/article/654284/7-sins-of-software-development.html