過度設計會扼殺你的產品 - mindtheproduct

我相信這是因為我們將討論建立產品時最普遍的問題之一：過度設計。在我看來，與缺乏良好的開發實踐相比，過度設計殺死了更多的產品。

在詳細介紹之前，讓我先和您談談我的背景。在成為產品經理之前，我是一名工程師。事實上，我的正規培訓是電腦科學。雖然在我的職業生涯中，我一直更接近業務而不是自己編寫程式碼，但我建立、擴充套件和管理工程和產品團隊都是平等的。

所以我並不是從外部談論過度設計。我為造成並遭受了它而感到內疚。正因為如此，我知道了解它是什麼、它的成本以及我們如何預防它是至關重要的。

什麼是過度工程？

過度工程 （或過度工程， 或過度殺傷）是以過於複雜的方式設計產品或為問題提供解決方案的行為。

在軟體方面，我喜歡Paweł Głogowski 的這個定義：

解決您沒有的問題的程式碼或設計。

現在你會想，誰設計或編碼來解決她沒有的問題？看起來很可笑，對吧？好吧，因為經過 20 年的職業生涯並自己完成了這件事，我可以向您保證，過度設計也不例外；這是常態。

過度設計的原因

沒有人懷著惡意這樣做。在很多情況下，過度工程的發生是因為我們試圖預測未來 併為未知事物做好準備。

當我們編寫一個功能時，很容易認為我們可以通過多花一點時間“以防萬一”來使它面向未來。

現實情況是，十有八九，“以防萬一”永遠不會到來。但在此過程中，我們失去了寶貴的時間並增加了專案的複雜性，而這將貫穿其整個生命週期。

過度設計的另一個原因通常是缺乏經驗。一般來說，你的資歷越高，你就越不容易過度設計，因為你已經經歷了很多人為複雜性在你面前爆炸的情況。

關於工程師經驗的學習曲線通常遵循與此非常相似的模式：

1. 您可以從直接程式設計開始。
2. 您會發現諸如物件導向程式設計之類的正規化，並跟上潮流。
3. 您閱讀了設計模式並開始尋找在各種情況下實現它們的機會。
4. 在經歷了幾年不必要的複雜性之後，你又回到編寫簡單的程式碼。

鬆散定義的需求也 增加了這個問題。如果工程師沒有明確定義的問題，他會傾向於過度設計以保護自己免受不確定性的影響。

無聊也會導致過度設計。如果工程師沒有要面對的激動人心的挑戰，他可能會通過嘗試新事物而最終使任何問題複雜化。

過度設計的後果

當我在文章開頭說過度設計會殺死初創公司時，我並不是在開玩笑。它對任何系統都有兩個特別有害的影響。

一方面， 它增加了我們的開發成本。如果我們的工程師不選擇最簡單的解決方案來解決問題，我們的時間和金錢成本就會增加，從而阻止我們更快地迭代。

另一方面，它也會增加您的維護成本。簡單的程式碼更容易程式設計、測試和修改。當我們將其複雜化時，複雜性會呈指數級增長，從而影響我們的迭代速度。

所以我再次肯定自己。過度設計會扼殺產品。不僅僅是缺乏良好的工程實踐。

過度工程示例

首先想到的是基於微服務的架構。幾年前，它們就像一波又一波的浪潮，他們應該取消比合並的專案更多的專案。

我將它們作為過度設計的一個例子，因為它們在 99% 的情況下都不是必需的，特別是對於必須找到適合市場的初創公司，並且將從使用更直接的架構模式。

過早優化 通常是過度設計的另一個典型例子。一種常見的情況是，當您仍然沒有使用者時，準備一個系統以通過過於複雜的基礎設施設定來吸收大量流量。在大多數情況下，您只需在單個伺服器上執行單體應用即可驗證您的業務模型。

過早優化最糟糕的例子之一就是我們花費大量時間設計一個系統，試圖防止在未來重複我們自己，並且不得不丟棄部分已完成的工作。

如果你從來沒有看到它工作，因為你以前破產了，那麼你的設計或實現有多完美並不重要。世界上幫助你驗證假設的最糟糕的程式碼比因為害怕重複自己而停滯不前要好。

，軟體重寫是過度設計的一個明顯例子。通常，工程師不喜歡在遺留程式碼庫上工作。他們的自然傾向是從頭開始做任何事情。重寫很少能達到目的，甚至會奪走你的業務。

說起來很明顯，但你的客戶並不關心你的系統內部有多優雅。你的客戶關心你幫助他解決他的問題。投入到不給他們價值的每一分鐘都是浪費的一分鐘。

...

防止過度設計的心理模型

• YAGNI

過度設計的問題在行業中非常普遍，以至於工程師們自己有一個術語來指代“以防萬一”新增程式碼的情況：YAGNI，“你不需要它”的首字母縮寫詞。

YAGNI 試圖阻止您新增任何對於解決您面前的問題並非絕對必要的內容，因為現實情況很可能是“您不需要它”。

• KISS

術語 KISS，“保持簡單愚蠢”，指的是簡單系統更容易修復、發展和維護的事實。因此，簡單應該是任何設計的目標之一，避免任何不必要的複雜性。

• 更糟更好

越差越好，我們強調的是，選擇越少，選擇越多。這樣做是因為它可以簡化我們產品的使用，使其對更廣泛的市場具有吸引力。

換句話說，它鼓勵我們保持產品最基本的功能，避免新增會增加產品複雜性的脂肪。

如何防止過度設計？

在我看來，防止過度設計的最佳方法是將您的工程師變成真正的產品工程師。

我們可以通過讓他們參與日常業務，在每個計劃之後解釋原因，並將其與對組織及其願景重要的指標聯絡起來來實現它。觀看此MTP 皮膚以瞭解有關定義重要指標的更多資訊。

我們需要讓他們更接近我們的使用者，邀請他們與他們進行訪談和發現會議。您希望您的團隊密切關注使用者的問題，以便他們可以迅速放棄任何無法儘可能有效解決問題的工程工作。

如果您將工程團隊視為單純的生產鏈資源，其唯一任務是從積壓工作中實現使用者故事，那麼不要期望您的工程團隊有動力去避免複雜性。他們需要了解每個決定背後的原因。

與上述相關，很好地定義問題以減少歧義。您的工程師需要知道原因，但他們也需要知道會發生什麼。你越能縮小問題的範圍，他們就越沒有理由保護自己免於過度設計解決方案。定義系統期望的一個好方法是使用SLI 和 SLO來使用服務目標。

工程師是任何公司中最具創造力的人物之一。如果您的團隊信任您的標準，他們可能會出現日常想法或計劃，這可能表明他們正在考慮未來的“假設”情景。當您有直覺可能是這種情況時， 請問：這如何幫助解決我們當前使用者的問題？如果我們現在不這樣做會怎樣？ 這些答案將幫助您區分是否存在過度設計的情況。

最後，更偏向於創始人，優先招聘已經在產品公司有過一些經驗的高階工程師。在面試中尋找戰爭疤痕。詢問他們最痛苦的經歷以及他們如何處理這些經歷。堅持那些將使用者和簡單性置於簡單技術解決方案之前的人。

詳細點選標題

banq：過度這個詞語，與好 壞詞語一樣非常主觀化，業內也無法達成共識，因此定義模糊的情況下爭論沒有意義。其實這是一個複雜的社會技術系統，不要超過團隊認知負荷，也不能不足，與智商、認知天花板多少有點關係。過度設計是一個偽命題，花費在偽命題上正確廢話閱讀，越浪費時間和腦力，不如打坐冥想。

黑客新聞討論

我不認為你可以在事後判斷它是否過度工程。除非你在房間裡，或者可以訪問一個精心記錄的團隊的書面規範，否則你不瞭解編寫程式碼的條件上下文。

可能公司當時會押注於整合市場或大量合作伙伴關係，因此構建了一個強大的整合平臺。然後，該公司在新平臺上只編寫了一兩個整合後，就轉向了另一個賭注。沒有人在這裡過度設計。一切都是按照規範建造的。但是三年後，新開發人員將在其中一個整合中發現一個錯誤，並感嘆程式碼是如何過度設計的。

許多來自戰壕的故事，包括這個執行緒中的許多故事都犯了這個錯誤。“科技債務”也是如此。如果你不在那裡，你不知道。（身在廬山不識廬山真面貌）

我認為這裡的教訓是，產品市場契合度高時，一切都是設計不足；產品市場契合度差時，一切都過度設計。從統計上講，與構建具有良好市場契合度的設計不足的產品相比，您更有可能構建出產品市場適應性較差的過度設計的產品。

某些東西可能曾經被精心設計過，而今天仍然被過度設計。C 和 C++ 中的標頭檔案就是這種現象的一個例子。他們解決了 40、50 年前技術限制的一個非常現實的問題，無論是在計算機能力還是編譯器技術方面，但是，由於這些問題不再存在，它們起到了過度設計的作用。

根據我的經驗，您所描述的情況更多地會導致“草率”程式碼——它似乎令人費解、不明顯。

過度設計的程式碼乍一看通常看起來很整潔，甚至可能令人印象深刻，尤其是對非技術利益相關者而言。然後當你真正深入研究它時，你會注意到一堆錯誤的抽象，這些抽象引入了間接層，而沒有提供任何有價值的靈活性。

你花在它上面的時間越多，多次重構的程式碼庫越有意義，過度設計的程式碼庫越少。