與複雜性作鬥爭是軟體開發中經常出現的主題，我已經看到過一遍又一遍在各個級別上爭論不休：在函式和方法中應該進行多少註釋？理想的抽象量是多少？框架什麼時候開始具有“太多的魔力”？組織中什麼時候出現太多語言？

我們試圖擺脫複雜性，控制它，並尋求簡單性。我認為這種逃避複雜性的方式進行構架是錯誤的。複雜性必須生活在某個地方。

彈性工程學告訴我的一件事是控制論中的“需要多樣性”的概念：只有複雜性才能處理複雜性。

使用構建工具時，一些事情變得顯而易見：

• 如果簡化構建工具，它將無法處理存在的所有奇怪的邊緣情況
• 如果要處理奇怪的情況，則需要偏離要建立的任何規範
• 如果您想簡化通用預設設定的使用，則通用預設規則必須在工具和使用者之間共享，這些使用者可以調整他們的系統以適應該工具的期望
• 如果允許配置或指令碼，則可以為使用者提供一種方法，以指定必須共享的規則，因此該工具適合他們的系統
• 如果您想保持該工具的簡單性，則必須強制使用者僅在適合該簡單性的引數內播放
• 如果使用者的用例不能很好地對映到您的簡單性，他們將圍繞您的工具建立填充以實現其目標

這是無法避免的。複雜性必須生活在某個地方。無論您是否意識到，解決問題始終是人們解決問題的一部分。

不幸的是，如果我們到達上述列表的最後一點（我們總是以某種方式這樣做），複雜性不會處於休眠狀態。它是每個人的學習經歷的一部分，他們會適應它。

他們解決了這個問題，看到了兩個衝突概念之間的不匹配。必要的複雜性可能會四處移動-回到工具（或新工具）中，或者通過重新組織事物來消除。每個這樣的更改都需要付出努力和更多的調整，並且人們可以看到複雜性，瞭解複雜性並解決複雜性。在某些情況下，更改不會簡化事情，而是會在各個人的假設之間造成新的不匹配，從而使事情複雜化，這將需要新的調整。偶然的複雜性只是表明其年齡的基本複雜性。它是不可避免的，並且一直在變化。複雜性必須生活在某個地方。

在設計心理學，唐·諾曼提到“在頭腦知識”和“知識世界”的概念（類似於概念更學術的Roesler＆Woods的呈現設計的專業知識）。頭腦中的知識是您知道的，已經學習的，記憶中的東西。知識就是一切：記下來的資訊，設計線索（您可以通過檢視電源按鈕的符號來了解電源按鈕，並且知道它可以像按鈕一樣被按下）。一個棘手的事情是，世界上對知識的解釋既是文化的又是上下文的，並且依賴於頭腦中的知識（您知道可以按下電源按鈕，因為您首先知道按鈕是什麼）。

在某些方面，專業知識正在您的腦海中積累知識，使您可以更好地閱讀世界。

我們在軟體設計中的一個常見陷阱來自關注於我們如何以“簡單”的方式讀取和解釋給定的程式碼。專注於簡單性充滿了危險，因為複雜性無法消除：它可以轉移。如果將其從程式碼中移出，它將流向何處？

設計Rebar3時，我們覺得該工具可能很簡單。其簡單性的條件是您對Erlang / OTP專案的預期結構有基本的瞭解。只要遵守這些規則，一切都會順利進行。我們將一些複雜性外部化為更廣泛的生態系統。規則總是需要學習的（因此我們假設），但是工具現在取決於對規則的理解。在為了解規則的人簡化工具使用時，我們使仍在學習規則的人變得更加困難。其他生態系統中用於其他目的的其他工具都在進行類似的權衡。

陷阱在軟體體系結構和架構中是隱蔽的。當我們採用微服務之類的東西時，我們會嘗試使之微不足道，以便每個服務都變得簡單。但是，除非這種簡單性如此之大，以至於您的實際應用程式繼承了它並被迫簡化為簡單性，否則它仍然必須走到某個地方。如果不在單個微服務中，那麼它在哪裡？

複雜性必須生活在某個地方。如果幸運的話，它可以住在定義明確的地方。在您決定應該增加一些複雜性的程式碼中，在支援該程式碼的文件中以及在為工程師提供的培訓課程中。您為它提供了一個位置，而沒有試圖將其全部隱藏。您建立管理它的方法。您知道在需要時可以去哪裡見面。如果您不走運，並且您只是假裝可以完全避免複雜性，那麼這個世界就無處可去。但是它仍然不會停止存在。

它無處可去，它必須在您的系統中漫遊，無論是在程式碼中還是在人們的腦海中。隨著人們四處走走和離開，我們對此的理解逐漸減弱。

複雜性必須生活在某個地方。如果您接受它，請給它應有的位置，在知道它存在的情況下設計系統和組織，並專注於適應，它可能會成為一種優勢。