當前位置:
首頁 > 知識 > 每個程序員都該知道的五大定律

每個程序員都該知道的五大定律

定律 - 或稱法則,可以指導我們並讓我們在同伴的錯誤中學習。這篇文章中,我將介紹我每次設計或實現軟體時出現在我腦海的五大定律。其中有些和開發有關,有些和系統組織有關。它們可以幫助你成為合格的軟體工程師。

墨菲定律

「凡事可能出錯,就一定出錯」

「墨菲定律」 是一種心理學效應,是由愛德華 · 墨菲(Edward A. Murphy)提出的。他的主要內容是:(1)任何事都沒有表面看起來那麼簡單;(2)所有的事都會比你預計的時間長;(3)會出錯的事總會出錯;(4)如果你擔心某種情況發生,那麼它就更有可能發生。

墨菲定律根本內容是:如果事情有變壞的可能,不管這種可能性有多小,它總會發生。即 「凡事可能出錯,就一定出錯。」 而墨菲定律很容易引入軟體工程領域。例如:

當你將軟體暴露給終端用戶,他們會創造性地輸入一些出人意料的內容,使系統宕機。所以你需要讓你的軟體足夠健壯,能夠檢測並警告非預期行為;

當你在機器上運行軟體時,任何地方都有可能發生問題 —— 從硬碟上的系統到數據中心的電力供應。所以你必須確保你設計的架構在每個層級都可以應對故障。

在舉個具體的例子,我曾經在一個批處理框架中使用字元串 「null」 來表示空值,我並不認為這有問題,直到有個名字叫 「Null」 的用戶提交了一個交易訂單,我們的報表流程中斷了幾個小時…… 還有一次,在另一個項目中。當所有東西都準備好部署到生產環境了,突然 Azure 基礎設施故障導致我們運行自動化腳本的伺服器宕機了。這些正是 「凡事可能出錯,就一定出錯」 的最好體現。

Knuth 定律

在 (至少大部分) 編程中,過早優化是萬惡之源

「現代計算機科學的鼻祖」Donald Knuth 曾說過 「在 (至少大部分) 編程中,過早優化是萬惡之源」。這條定律是高德納 (Donald Knuth) 的經典語錄之一,它告誡我們不要過早優化應用程序中的代碼,直到必須優化時再優化。因為:讓正確的程序更快,要比讓快速的程序正確容易得多。

的確,簡單易讀的源碼可以滿足 99% 的性能需要,並能提高應用的可維護性。最開始使用簡單的解決方案也讓後期性能出現問題時更容易迭代和改進。

在項目開發中,總是有程序員浪費寶貴的時間去改進那些不需要改進的代碼,而沒有通過所做的改進增加價值。在對項目進行優化時,究竟哪些地方應該優化,應該如何優化,哪些不應該優化呢?你需要先來了解一下這 7 件事。 究竟要優化什麼?究竟要優化什麼?優化在刀刃上;優化層次越高越好; 不要過早優化; 依賴性能分析,而不是直覺;優化不是萬金油,這樣優化往往更有意義。

過早優化是萬惡之源

North 定律

「每一個決定都是一次權衡」

嚴格的說它目前還不是公認的定律,這是取自 Dan North 的演講 「Decisions」,Decisions 這條語錄強調無論你做的選擇是什麼,你總會放棄一個或多個選項,但這不是最重要的。最重要的是理智地做出決定,了解其他選項,清楚你為什麼不選擇它們。開發者日復一日的生活中,我們每天都做無數個大大小小的決定。從命名變數到自動化(手動)任務,再到定義平台架構,你要始終根據當前你掌握的信息來權衡並做出決定,記清楚你為什麼做出那個決定,重新評估新的選項之後再做出新的理智的決定。

Conway 定律

「系統設計的架構受限於生產設計,反映出公司組織的溝通架構」

在 60 年代,一位名叫 Melvin Conway 的工程師注意到公司組織結構影響到他們開發的系統的設計。他用一篇論文描述了這個觀點,並命名為 「Conway 定律」。

這條定律很適用於軟體開發領域,甚至體現到代碼層面上。交付軟體組件的各個團隊組織結構直接影響到組件的設計。

例如,一個集中式的開發者團隊會開發出各組件耦合的整體應用。另一方面,分散式的團隊會開發出單獨的(微)服務,每一部分關注點分離清晰。

這些設計沒有好壞之分,但它們都是受到團隊溝通方式的影響。在全球有大量獨立開發者的開源項目,通常是模塊化和可重用庫,這就是很有說服力的例子。

當前,將大的集成應用解耦成微服務已成趨勢。這很棒,因為這可以加速交付使用項目。但你也應該牢記 Conway 定律,在公司組織構建中投入與技術開發同樣多的工作。

瑣碎定律

「組織成員投入大量精力到瑣碎的事情上」

瑣碎定律 (帕金森瑣碎定律) 源於英國著名歷史學家諾斯古德 · 帕金森 1958 年出版的《帕金森定律》一書中。帕金森瑣碎定律是時間管理中的一個概念。帕金森定律表明:只要還有時間,工作就會不斷擴展,直到用完所有的時間。

這條定律論點是在會議中花費的時間與事情的價值成反比。的確是這樣,人們更願意把注意力和觀點放在他們熟悉的事物上,而不是複雜的問題上。

帕金森給出一個例子,一場會議中,成員們討論兩件事:為公司建核反應堆和為員工建車棚。建反應堆是一件巨大而複雜的任務,沒有人能完全掌控全局。他們完全信賴流程和系統專家,並很快接受了項目。

另一邊,建車棚是一般人都可以做的,每個人都可以對顏色有意見。事實上,每個會議成員都會表達自己的意見,使得建車棚的決議所花費的時間遠遠超過建反應堆的。

這條定律在軟體行業十分出名

舉個例子,開發者會花費更多時間到討論正確縮進或函數命名,而不是討論類的職責或應用架構。這是因為每個人都能認知幾個字元的變動,但項目架構的變動則需要巨大的認知負載

你能注意到的車棚效應的另一個例子是 Scrum 演示。不要誤會我,我喜歡演示,我認為這是一個很好的機會來面對用戶並獲得對應用程序的反饋。但通常 Scrum 演示過程中的討論會轉向瑣碎問題,而不是審視全局。這些討論也很重要,但你應該注意權衡更重要更複雜的問題。

隨著軟體開發經驗的增長,我們將會學會更多。儘管其中某些定律現在看起來是常識,但是了解這些原則可以幫助你識別這些模式並做出反應。


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 程序員之家 的精彩文章:

程序員偷偷深愛的 9 個不良編程習慣
程序員必須掌握的6種軟技能
是什麼使一名好程序員變得偉大
不完全指南:程序員怎麼找海外工作
當程序員成為了爸爸,畫風……

TAG:程序員之家 |