全文共2900字，預計學習時長
9分鐘
圖源：Unsplash
簡單的成功遠遠勝過複雜的失敗。
這句話像一個魔咒，在各行各業、各種場景似乎都得到了驗證。
巴菲特早在1996年說過：“大部分投資者，包括機構投資者和個人投資者，早晚會發現，最好的投資股票方法是購買管理費很低的指數基金。”
無數股民的親身經歷驗證了巴菲特建議的正確性。
“投資方法往往越簡單效果越好。”
“簡單常能勝過複雜。”
在一次關於代碼評審的無傷大雅的辯論中，我突然發現，在所有與編碼相關的決策中，我只有幾個基本的想法。其中之一就是: 簡單勝過複雜。大約三秒鐘後，我意識到這既不是一個眾所周知的咒語，也不是一個可以很快解釋完的咒語。這是一個伴隨你成長的信念。但是，我該如何向我的隊友解釋這個信念呢？
對我來說，“簡單勝於複雜”是對不同問題的務實回答，就像一把簡單的Occam剃刀。它帶給我兩個好處:
· 它可以讓我把一個問題分解成現在需要解決的部分和可以推遲的部分。
· 它讓我對自己的決定有了信心，因為它得到了許多其他定理、原理、規則和指導方針的支持。
那麼“簡單勝於複雜”到底是什麼意思呢？
圖源：Unsplash
這個指導方針希望你選擇更簡單的解決方案。你應該經常問自己：你能簡化你的代碼而仍然得到相同的結果嗎？你能在簡化設計的同時達到一樣的目標嗎？
可以是一些小事，比如：你是否過度使用了強大的語言結構？使用try-except語句對你有好處嗎，還是簡單的 if 語句更適合你的流程？
或者可以是更大的問題，比如：你真的應該支持20個不同的場景嗎？或者你能通過提供最常見的三個場景來獲得可比的用戶體驗嗎？
這個指導方針是引導您對複雜性保持警惕，並要求縮小它的好理由。
複雜性如何影響一個項目
在一個項目的開始，沒有代碼，沒有規範。未來，或者是我們必須創造的東西是令人畏懼的，但過去，也就是我們創造初的東西是簡單的。到目前為止，我們還沒有創造出任何東西，這很簡單，任何人都可以做到。
現在我們需要創造一些東西。我們不能一下子創造出所有的東西，我們應該從什麼開始呢？
圖源：Unsplash
如果我們相信欣欣向榮的創業場景，務實的做法是從一個MVP開始。它代表最小可行產品，一個包含足夠有用特性的產品，它成功地完成了其主要任務。這個階段的目標是保持開發項目的低成本，直到我們有證據證明我們正在開發正確的特性。
MVP原則就是“簡單比複雜好”的不同說法。應該使用最簡單的解決方案來解決您的問題。不要增加複雜性，例如，成本，直到你有充分的理由。
類似的概念也出現在《帕雷託法則》中，它也被稱為二八法則或少數人的法則。它指出，對於許多事件，大約80% 的影響來自20% 的原因，也就是說，80% 的故障（bug）報告是由20% 的故障引起的; 在80% 的時間中，只有20% 的特性被使用。
帕雷託法則起源於統計學和經濟學，但已經應用於廣泛的領域中。它很好地支持了我們的簡單勝於複雜的概念。如果80%的客戶只使用了20%的可能工作流，那麼為什麼還要費力去支持我們軟件所能想到的每一個工作流呢？
因此，要決定哪些特性應該首先開發，我們必須挑剔。我們所建立的一切，我們也必須在一段時間內能及時提供支持。我們添加到軟件中的任何東西都會產生維護成本，並且會影響我們如何以及以何種成本構建其他完全不相關的新東西。
提高複雜性的好理由是什麼？
從理論上講，上述內容似乎都是合乎邏輯的。但它也非常模糊。沒有任何東西像複雜性或簡單性的實際定義一樣，沒有任何東西可以作為我們的經驗法則來判斷哪個特性值得花費一個月的努力，哪個特性值得花費六個月的時間，哪個特性只值得投入一天即可。這就是模糊產生和爭吵變得激烈的地方。
開發人員和管理人員不關心這個指導方針的真正原因是我們不能就“簡單”的含義達成一致。
如果在一個會議上，我們最大的客戶明確表示，如果我們在本季度末未交付 x，他們就會離開我們的公司。那麼在我看來，這似乎是一個“我們的公司面臨生死存亡”的局面，也是增加複雜性絕對的好理由。
然而，如果我是這個項目的新開發人員，並且我能看到這個軟件在過去拙劣的項目中極差的表現，我可能也會相信，如果我們現在不採取行動，並開始為我們過去的錯誤判斷付出代價，那麼這個項目無論如何都是註定要失敗的。
所以我們該如何做？
圖源：Unsplash
我們提前做出計劃。
這種情況可能無法解決，而最有效的解決方法就是避免它。我們不希望處於一個複雜性增長如此之多的環境下，以至於我們很難維持這個項目。
只要一個項目是簡單的，就很容易讓更多的人員加入其中，而且關鍵的是，我們很容易記住我們所涵蓋的所有場景。
一個項目越複雜，新人提供有意義的幫助所需的時間就越長。這個項目變得越來越依賴於它的原作者，那些仍然知道在哪裡和為什麼增加了這些複雜性的作者。但是由於忘記了特性和流，這個項目也變得越來越有缺陷。
而與此同時，它的靈活性也一再降低。相當數量的bug遲早會成為特性。用戶不知道哪些功能是設定的，哪些不是。他們開始依賴壞掉的功能，而且從現在開始的每一個改變都是一個無法修補的承諾。
有趣的是，團隊有時藉助測試來緩解這個問題。即使有些事情是無意的，只要測試斷言了它，它也會警告我們，尤其是我們不小心改變了邏輯的時候。但我認為這是無用功。很少有測試被正確的閱讀、理解或維護。這樣的測試就像把永遠醉醺醺的邊防軍官送到邊境一樣。我們能看到他們，但我們不會認真對待他們。
每個例外都是惡性的嗎？
圖源：Unsplash
另一方面，編寫代碼時，我們希望有人能在現實生活中的問題上使用它們。現在，告訴我一個自然界中的問題，它有一個乾淨，簡單的解決方案，並且沒有例外！結果是一個也沒有。生活是複雜的，代碼也是。
只有在理論上，我們才能“在這個物理公式中忽略空氣阻力”。
但簡單仍然更好
儘管如此，我們仍然需要知道理想狀態是什麼樣子的。我們需要知道我們在為什麼而奮鬥，這樣我們才能知道什麼時候我們偏離了它，以及我們為什麼偏離了它。
沒有神奇的解決方案，也沒有三步指南。是否在簡單性和複雜性之間取得了良好的平衡，只有到後來才會變得明顯。一旦做出決定，這個決定通常是不可改變的，或者改變決定的代價是昂貴的。
但是，如果我們計劃在某個項目上再繼續工作一段時間，我們應該考慮未來的自己，誰將不得不忍受這個決定？以及從長遠來看，這個特性真的好用嗎？
圖源：Unsplash
專注和簡單是成功的秘訣之一。簡單肯能比複雜更難做到：你必須努力理清思路，從而使其變得簡單。但最終這是值得的，因為一旦你做到了，便可以創造奇蹟。
我們一起分享AI學習與發展的乾貨
閱讀更多 讀芯術 的文章
