奧卡姆剃刀原理是最強大的解決問題的原則之一，它可適用於生活和軟體開發中。它可能不為人所知，而且經常被誤解且沒有得到充分的利用。
奧卡姆剃刀原理
奧卡姆剃刀原理在中文中被定義為：“
如無必要，勿增實體
”。它提倡：“
當對於同一預測的多個競爭性假設時，人們應該選擇假設最少的解決方案
”。
在沒有證明假設之前，更應傾向於簡單而非複雜。
奧卡姆剃刀原理也即最簡單的方案往往可能就是最正確最好的方案，切勿浪費較多資源去做那些用較少資源也可以做好的事情。
簡而言之，就是保持事情的簡單性，要馭繁於簡，而不要人為地把事情複雜化，自尋煩惱。
奧卡姆剃刀在科研、管理、投資等領域作為一種指導原則而廣泛應用，在沒有經驗證據的狀況下，它可以作為一種快速決策和建立真理的手段。在人工智慧領域，機器學習的過程中，選擇複雜性低一點的數學模型，演算法的表現往往會更好。雖然奧卡姆剃刀不是在所有的場合都適用，但它是一個具有啟發性的指導原則，其
核心意義在於不要將已經很複雜的問題人為地更加複雜化
，而在模型上化繁為簡是相對正確的途徑。
敏捷軟體開發與奧卡姆剃刀原理
“敏捷軟體開發”指的是在多次迭代中構建和測試軟體的策略，因為軟體每次只開發一小部分。敏捷的主要目標是快速交付可工作的軟體，並且儘量沒有bug。
敏捷開發
隨著開發的繼續進行，在開發過程中添加了更多的新特性，不必要的複雜性就會悄悄進入到專案中。這便導致了一項巨大的質量保證任務，即在最後審查一個龐大而複雜的系統。如果你將奧卡姆剃刀原理應用到流程中，就可以大大降低這種不必要的複雜性。
敏捷軟體開發可能變得複雜，特別是在經過多次迭代之後的過程中。
減少這種複雜性的併發症最好方法是將奧卡姆剃刀原理應用到這個過程中。
每個軟體團隊應該從簡單開始，只有在明確確定了要增加功能的需求後才增加複雜性。
在軟體設計中，實現所需功能的最簡單的程式碼通常是最好的。簡單的程式碼不太可能有bug，通常程式執行得速度也會更快。
敏捷軟體開發的複雜性是透過在迭代過程中，以小而頻繁的形式新增，並最終小心的演變成最終產品。這種方式事半功倍，省時省力，避免不必要的錯誤和修正。向專案新增的複雜性越多，編碼實現、測試和審查新新增內容所需的時間就越多。記住，
系統越複雜，失敗的機率就越高。
實現這種策略可以使軟體更容易構想、構建和測試。
保持事情儘可能簡單，也有助於專案相關人士和終端使用者，因為他們更願意評估一個更簡單的系統，而不是一個複雜的系統。
透過應用奧卡姆剃刀原理，軟體開發團隊將取得更快的進展，並且隨著專案的繼續，將更容易應用更正。
軟體架構設計與奧卡姆剃刀原理
為什麼程式設計師之間的工作效率有巨大的差距？研究表明：相同經驗和學歷的兩個程式設計師之間的生產力差異很容易相差一個數量級（10倍），而除錯生產力的差異可能相差25倍。
軟體架構
這些非常有生產力的程式設計師會編寫簡單、優雅、易於理解的程式碼，用很少的程式碼完成很多的事情。
這些“明星”程式設計師以大多數人都無法理解的方式來獲得這些生產力。話雖如此，普通的程式設計師也可以透過做一些事情來提升自己的生產力來達到“明星”程式設計師的水平。
在某種程度上，明星程式設計師透過做的更少來完成更多的事情。這有點反直覺，但如果你考慮到一個程式設計師花時間寫一些不必要的程式碼，或者不得不一致重構程式碼，只是因為他的設計不能簡單處理不斷變化的需求。那麼他們將只有更少的時間來編寫那些“需要的”程式碼，從而降低了生產效率。這些高產出的有效性可以部分透過奧卡姆剃刀原理和少做的原則來體現。
奧卡姆是14世紀的哲學家，他對軟體一無所知。但是，他確實瞭解複雜性的問題以及簡單性在所有事物中相應的有效性。
奧卡姆剃刀原理背後的原則是
告誡人們以簡單為重
，
並透過剔除任何不直接支援結論的東西來實現這一目標
。
現代對奧卡姆剃刀原理經常會被解釋成：“
最簡單的解決方案几乎總是最好的
”。但是現代的解釋忽略了重要的一點即：
“最簡單”意味著“假設最少”
。這個原則也經常被稱為“節儉原則”：“
採用現有最簡單或最簡潔的解釋
”。
“街上的女士是個女巫——是她乾的”，這句話是一個非常“簡單”的、毫不含糊的陳述。它引入了很少的實體，並提供了一個簡單的解釋，最初看起來很像那麼回事。但仔細分析，這句話是建立在幾個非常大的假設之上的。這句話違法了奧卡姆剃刀原理，為了支援一個結論引入了不必要的實體：
1、女巫存在；
2、這個女士是女巫；
3、她幹了；
4、她被任務是個女巫與她是否幹了有關；
實際上，這些因素與她所謂的罪行沒有任何聯絡，但如果我們不質疑他們的真實性就接受他們的話，很可能會導致一個錯誤的結論——她有罪。歷史已經告訴我們，許多無辜的人基於這種似是而非的推理而被判處可怕的死亡。
當涉及到軟體設計時，你確定你的推理沒有類似的缺陷嗎？
你確定你所做的一切是真正為了支援專案目標而做的嗎？
你是否也不必要的引入了一些元素，認為它們是你計劃的結果，結果仔細檢查後發現並非如此？
幸運的是
敏捷軟體開發的一個主要優勢是首先關注重要的事情
。具體而言體現在：
我們較少關注技術，而更多關注於為終端使用者提供價值。
雖然有各種不同的評估，但一般都認為
軟體應用中80%的功能從未或很少被使用
。使用
敏捷軟體開發
可以確保我們在過程中
不斷的評估特性
與功能並
重新確定其優先順序
。
通常，當我們接近
專案的尾聲時
，我們意識到
最初在需求列表中的大部分內容不再相關
，但是因為我們在早期就交付了最高價值的功能，利益相關者也通常會在開發的早期就感到滿意。通常他們會決定，許多最初要求的能力已經不再適用了。
良好的開發方法論將精力集中在提供價值上
，這對奧卡姆所倡導的原則有很大的幫助，但這還不夠。
隨著應用需求的擴大，軟體解決方案的規模和複雜性也在不斷增加。複雜性引入了不確定性，而不確定性意味著風險；風險越大，失敗的機率越高。為支援一個結論
增加實體並不只是增加複雜性，而是使複雜性成倍增加。
我們透過這個簡單的例子說明了這一點：拿一張白紙和一支鉛筆，在紙上畫兩個點，用一條直線把兩個點連線起來。現在新增第三個點，並將其與另外兩個點相連。你現在應該有三個點和三條線。現在新增第四個點，並將其與前三個點相連。你現在應該有四個點和六條線。跳到100個點，你將有4950條線或相互聯絡。每增加一個新的點，連線點與點之間的線的數量就會急劇增加。這是一個很基本簡單的數學問題。
這裡的複雜之處不在於這些點，而在於每增加一個點就會增加連結這些點的線的數量。如果你想到軟體中的實體（類、物件例項、模組、元件、資料庫、表等等），你也會很容易的覺察到，隨著實體數量的增加，系統的複雜性也在增加。
雖然說軟體裡的這些實體並不是所有的之間都有聯絡。但你能肯定的說任何一個實體的變化都不會對其它實體產生影響嗎？如果你有數百甚至數千個實體，那會發生什麼？那將會遠遠超過任何人的實際能理解的數量，那時你還會確定你理解所有直接的相互作用嗎？
那所有實體的整體效應又是如何呢？“如果”系統沒有進行合適的“關注隔離”並且沒有透過良好命名的“自解釋的文件”這樣的優良設計，從而導致每個實體的功能不是那麼清晰怎麼辦？“如果”可以無限地新增，並且它們會隨著你新增的實體的數量而增加。這些“如果”在奧卡姆剃刀原理的觀點中就代表著“假設”，
假設越多，你的系統就越複雜，因此風險就越高，失敗的機率也就越大。
“
假設是偽裝成已知的未知
”，它代表了一種對系統完整性以及專案的成功來說隱藏的、非常真實的危險。
假設是生活中必不可少的一部分。假設幫助我們把生活的複雜性打包成漂亮整潔的小包裹，幫助我們管理每天每分鐘都必須處理的大量資訊。
假設是非常有用的，但不正確的假設會產生災難性的影響
。顯然，我們無法測試每一個假設，這也就是經驗無法替代的地方。
顯然，
複雜性必須要降低，假設必須被挑戰
！但如何做呢？這就是藝術之所在。如果你看看建築（architecture）領域，你會發現它與軟體的世界有很多相似之處。這兩個領域都非常的具有技術性。在兩個領域中簡單性和優雅以及人類與結果互動的便利性是成功的關鍵因素，並且在這兩個領域中，有許多方法和形式可以提供解決方案，所有這些方案都是為了滿足需求。在這些方案中有些解決方案顯然優於其他解決方案。在建築中，“藝術”的成果通常更加明顯且非常清晰可見，因為它們都表現在外觀上。
偉大軟體中靈感、直覺或遠見不亞於偉大建築上的靈感、直覺和遠見。但在軟體中並不是那麼明顯。一
個偉大軟體的解決方案應該是簡單、優雅並且使用起來愉快的
。
這兩個領域進行策劃和設計的人都被稱為架構師，這絕非巧合。在這兩個領域，輝煌的成功都需要獨一無二的人才。
許許多多的架構師中，他們的教育和工作背景也是多種多樣的。但是
優秀的架構師都有一個共同的特點是：他們會毫不留情的問“為什麼”
！
他們質疑設計的關鍵假設，為假設的存在和功能尋找確鑿的理由。
優秀建築架構師和優秀的軟體架構師都會對設計中的每件事都有充分的理由。每個元素的原因都將有充分的理由，並且可以簡單地解釋。
如果一個實體的存在和它的功能不能簡單地解釋，那麼很可能就像街道盡頭的那個女人因為她是女巫的假設而被推理有罪一樣，你的設計可能會受到過多假設的影響。
在很多時候，透過問“為什麼”你會發現，
很多需求不是以需求的形式展現出來，而是以解決方案的形式展現出來
。
透過多問“為什麼”可以消除多層的假設，讓你找到真實的需求，這個需求和被最初陳述的樣子大不相同。（
比如說，客戶需求是“速度更快”，但是卻以“馬車”這樣的解決方案來展現）
具有明確存在目的的實體在大型設計中往往能很好的融合在一起，因為沒有重複有助於實現更簡單、更優雅的設計。
我們需要使用奧卡姆剃刀原理無情的去除不必要的實體，並制定簡單、優雅、易於解釋且不包含假設的設計。
相關原則
簡單性原則
1、KISS：
Keep it simple， stupid。
保持簡單，愚蠢。
KISS原則是軟體設計中的最古老的原則之一。KISS 原則指出，
大多數系統在保持簡單而不是複雜的情況下工作得最好
； 因此，簡單應該是設計的一個關鍵目標，應該避免不必要的複雜性。軟體系統必須由能力有限的人類開發人員維護，因此係統複雜性的任何增加也會增加維護它的難度。
2、YAGNI：
You Aren’t Gonna Need It。你不會需要它。
這是一項來自於極限程式設計的原則，該原則指出：
除非確實需要，否則程式設計師不應新增功能。
3、Last Responsible Moment：
最後響應時刻。
儘可能晚做決定：儘可能推遲決定，直到可以根據事實而不是不確定的假設和預測做出決定。
4、複雜設計
當沒有遵循簡單性的原則，我們所得到的軟體將有如下形式的複雜性：
4。1
不需要的特性
功能蠕變
（Feature Creep）：
在產品中不斷擴充套件或新增新功能過程中， 額外的功能超出了產品的基本功能，因此可能導致過度複雜而不是簡單的設計
。功能蠕變在軟體系統中尤其常見，在軟體系統中，新增原設計中不包含的新功能相對容易。這種特性擴充套件的結果之一就是眾所周知的軟體膨脹。
軟體膨脹
（Software Bloat）：計算機程式的後續版本明顯變慢，使用更多的記憶體或處理能力，或比前一個版本有更高的硬體要求的過程，同時只做了可疑的使用者可感知的改進。
4.2 過度工程化
將產品設計得比其應用所需的更健壯或更復雜
。過度工程的一個典型例子是有太多的抽象層。
5、過度簡單設計
把複雜的問題和問題看得比實際簡單得多。
簡單的軟體設計可能只關注當前的功能需求，而忽略了某些非功能需求，如可維護性、可擴充套件性和可重用性。
相關名言
1、Everything should be made as simple as possible， but not simpler。 – Albert Einstein
一切都應該儘可能簡單，但不能更簡單。
2、The business schools reward difficult complex behaviour more than simple behaviour， but simple behaviour is more effective。 –Warren Buffett
商學院獎勵困難的複雜行為多於簡單行為，但簡單行為更有效。
3、They say the world has become too complex for simple answers。 They are wrong。 – Ronald Reagan
他們說世界已經變得太複雜了，無法找到簡單的答案。他們錯了。
4、Simple can be harder than complex。 You have to work hard to get your thinking clean to make it simple。 - Steve Jobs
簡單可能比複雜更難。你必須努力讓你的思維變得乾淨，才能讓它變得簡單。
5、There are two ways of constructing a software design。 One way is to make it so simple that there are obviously no deficiencies。 And the other way is to make it so complicated that there are no obvious deficiencies。 – C。A。R。 Hoare
有兩種構建軟體設計的方法。一種方法是使其簡單到顯然沒有缺陷。另一種方法是使它變得非常複雜，以至於沒有明顯的缺陷。
6、Always implement things when you actually need them， never when you just foresee that you need them。 – Ron Jeffries
總是實現你真正需要的功能，絕不實現僅僅是預料所需要的功能。
參考資料：
https：//naveenkumarmuguda。medium。com/occams-razor-in-software-development-56ee3e8b8ce8
https：//www。cirdangroup。com/cirdan-blog/occams-razor-in-software-development
https：//michaellant。com/2010/08/10/occams-razor-and-the-art-of-software-design/
https：//effectivesoftwaredesign。com/2013/08/05/simplicity-in-software-design-kiss-yagni-and-occams-razor/
