軟件開發的定律大部分的人都不認識你呢
與軟件開發的其他領域一樣,有一些非常有趣的法律.程序員,技術總監和架構師經常在聊天會話和中中提及它們.像小白一樣,通常只會眨眼,因為我們不想離開另一部分知道我們不知道誰是布魯克,摩爾或維斯.成都app開發
這些法律包括一些軟件開發的法律或神.它們非常有趣,值得我們探索,每個法律背后都有令人驚訝的背景故事.成都app開發
在這篇文章中中,我將分享我對軟件開發中最著名和最常見的法律的解釋和想法.
墨菲定律
可能是最著名的法律之一,主要是因為它不僅適用于軟件開發.
如果出現問題,就會出錯.成都app開發
有效的(代碼)的第一個推斷:,不能寫它.
第二個推斷:詛咒是所有程序員都可以流利地說的唯一語言.
結論:計算機將執行它所寫的(代碼)而不是它想要的東西.
防御性編程,版本控制,世界末日場景(對于那些該死的僵尸服務器攻擊),TDD,MDD等.這些是這項法律的防御性做法.
法律布魯克(布魯克定律)
大多數開發人員故意經歷過或不符合法則布魯克,即
將員工添加到已推遲的軟件項目中只會進一步延遲項目.
如果一個元素被推遲,簡單地添加更多人可能會產生災難性的后果.審查編程效率,軟件開發方法,技術架構等因素將始終帶來更好的結果.如果沒有,那么請記住,霍夫施塔特的定律也有效.
法律霍夫施塔特(霍夫施塔特定律)
霍夫施塔特的法則由Douglas Hofstadter提出并以他的名字命名.
當然,不要在電視連續劇《大爆炸》中將此法與Leonard Hofstadter混淆,盡管他說的一些事情對某些人來說有些重要.成都app開發
該法律規定了
即使你考慮到法律霍夫施塔特,項目完成的實際時間總是比預期的要長.
這種"法律"指的是難以準確估計完成復雜任務所需的時間.這個定律是遞歸的,反映了估算復雜項目的難度,盡管你可能已經做得最好并且知道任務.復雜性.

這就是為什么在進行項目估算時應該有一個緩沖區的原因.

法律康威(康威定律)
軟件的結構反映了開發軟件的組織結構.
或者使它更清晰
組織設計的系統結構受到組織通信結構的限制.
許多組織根據其功能劃分團隊,因此有前端開發團隊,后端開發團隊和數據庫開發團隊.簡而言之,如果有人想要改變屬于他人的東西,那么他很難改變.這些東西
越來越多的組織正在基于有限的上下文創建團隊,而諸如微服務之類的架構也在基于服務邊界而不是孤立的技術架構分區創建團隊.
因此,基于目標軟件架構的團隊的創建便于軟件架構的實現,這是打擊法律康威的有效方法.成都app開發
波斯 Postel法則或穩健法
保守輸出,免費進入.
它最初用作實現強大TCP的原則.這個原則也反映在HTML中中. HTML的成功或失敗可歸因于其許多屬性,但如果HTML成功與否,不同的人會有不同的意見.
規則帕累托(帕累托原則)或80/20規則
對于許多現象,80%的后果來自20%的原因.
錯誤%來自20%的代碼,即帕累托規則.
其他人說,公司80%的工作是由20%的員工完成的.問題在于,不知道20%的員工是誰.
彼得的原則
這是一個非常令人沮喪的法律,特別是如果你親自體驗它.
在中層次結構中,每個員工往往被提升到他們無法執行的職位.
保持伯特(Dilbert)漫畫系列有一些例子.