讓我們一起終結複雜性商人（謝謝你，DHH）

"刪繁就簡三秋樹，領異標新二月花。"

—— 清代鄭板橋（18世紀）

DHH在Rails World 2025的這個視頻太精彩了。DHH在1999年之前就開始了他的職業生涯，而我很幸運能夠在1999年我父親帶我到中國的網吧時開始使用互聯網。在技術世界裡，我認為DHH是我的線上導師，在我整個職業生涯中指導我識破胡扯，包括在微軟和其他公司的經歷。我在與不同的人合作時發現了太多胡扯，我相信至少90%的人不接受我對問題的簡化。他們不斷給他們可悲的項目增加複雜性，最終失敗。一個簡單的項目本來只需要一兩百萬美元的人力成本開發，最終卻花費10倍的時間和2000萬美元。所有這些過度複雜化、過度工程化和過度思考問題最終都會導致巨大的失敗。

從我開始學習編程以來，我一直髮現許多所謂的規則、最佳實踐、編程語言和框架都是胡扯。我當時不是那麼熟練的程序員，所以不敢這麼說。

我可以給你很多例子。拿App Store的代碼簽名系統來說。這不只是代碼簽名，它與蘋果的IDE緊密耦合，蘋果在這上面沒花多少心思，而且很糟糕。到現在，我仍在修復我應用的隨機代碼簽名問題。今天我正在嘗試修復Twilar的代碼簽名問題，這是一個macOS Catalyst應用，處於非常奇怪的位置。

我無法修復它，儘管我的客戶一直要求我修復。這完全是由於蘋果的繁文縟節。

其他編程語言比如DHH提到的Java，不信任程序員，所以它們建立了儘可能多的繁文縟節壁壘。

我認為這種隨意的複雜性胡扯至少佔當前編程世界的50%。以Kubernetes為例。我相信這個世界上只有10家公司，也許100家頂級公司需要它。我花了那麼多時間學習它，但它根本沒用。

構建複雜性胡扯檢測器

那麼我們如何構建一個複雜性胡扯檢測器呢？我認為AI是一個好工具。

DHH提到他一直在使用bash腳本和AI從頭構建Omarchy。

關於AI輔助編程，很多人會說"AI寫出來的代碼不是代碼，只是垃圾"。好，假設這是對的。如果你吃的食物因為大量生產而變得便宜，你能說你在吃垃圾還是食物呢？就是這個道理。很多人有那種自負心態，覺得複雜的東西才是正確的。我認為恰恰相反，越簡單的東西正確性越高。

我認為即使沒有AI，如果某個東西可以很快變得可用，比如在七天內製作出最小可行產品，或者用AI在兩天內完成，那就是一個好信號。否則，我會懷疑，因為真正的阻礙是其他東西，比如法律合規或大平臺的壟斷。

例如，我正在構建一個鍵盤輸入應用，我發現無法使用iOS鍵盤擴展來錄製音頻，而蘋果可以很容易地用他們的內置模型做到這一點。這個市場的每個參與者都在構建變通方案，在變通方案上花費額外的100個小時。蘋果所謂的隱私問題只是為了阻擋新來者和競爭對手。這就是複雜性胡扯。

例子太多了。拿macOS應用的代碼簽名來說。蘋果引入了一種叫做公證的東西，這是自動App Store審查。在大多數平臺上，你可以分發應用而無需徵得某些大公司壟斷的批准。

擁抱開放系統

去年早些時候，我做了一個決定，避免跨平臺技術，儘可能少寫平臺特定代碼，這意味著完全擁抱web技術。

當我有時必須編寫原生代碼比如Swift或C++時，我發現設計和複雜性都很糟糕。這僅僅是因為平臺提供商一直在主導其平臺上的創新。他們不想要新東西，因為如果我們構建新東西，那可能會推翻他們的平臺壟斷。

我認為只有少數開放標準是真正開放的：web標準、Electron、Node.js、Ruby on Rails。這些是我們應該學習和使用的真正開放系統。我們應該構建在這些更簡單、更便宜、更快、更好、為人類設計的框架和語言之上。我們應該狠狠地打擊像Swift這樣的封閉生態系統，確保如果它們選擇成為封閉系統就無法繁榮。

為什麼？因為封閉系統總是不好的。Xcode IDE已經壞了至少一年。如果AI更改太多行代碼，它就無法再構建應用了。它只是拋出隨機失敗。你可能會問蘋果工程師如何完成他們的工作。我相信他們在完全不使用AI的情況下完成工作，因為如果他們有AI編寫Swift代碼，他們一年前就會注意到這個問題。

Xcode的糟糕狀態已經被充分記錄。這篇Medium文章完美地描述了我提到的Xcode構建問題的荒謬性。開發者找到的唯一"解決方案"就是重啟整個IDE，這完全是荒謬的。即使是git分支切換這樣的基本操作也會觸發這些故障。如果蘋果自己的工程師真的使用現代開發工作流程，他們早就修復了這個令人尷尬的錯誤。

人們經常選擇接受權威而不是抱怨。當我在Twitter上抱怨這個問題時，某個隨機公司的某個隨機人說他們沒有看到同樣的問題，這完全是笑話，除非他們不寫Swift或Objective-C代碼。

為什麼DHH的哲學很重要

我很高興12年前開始學習Ruby on Rails。我喜歡DHH的思維方式，儘管我不100%同意他的所有觀點比如強類型。

我完全同意我們應該致力於減少複雜性。我愛蘋果，我愛蒂姆·庫克，我愛史蒂夫·喬布斯，但我不喜歡蘋果建立的繁文縟節。如果我們減少複雜性，一切都會更好。蘋果會更好，開發者會更好。

很難想象10年前我使用Capistrano部署我的Rails應用，現在我們有了Kamal部署。事情變得更容易、更簡單、更好。這也應該發生在iOS開發和macOS開發上。

明天蘋果將發佈他們不重要的iOS重新設計，在這個UI根本不重要的時代，那就是Liquid Glass。新設計看起來很棒，但絕對不在蘋果的首要任務中。人機交互正在回到最自然的形式：對話。

我希望蒂姆·庫克能夠意識到錯誤或錯誤決定，並開始修復蘋果的真正問題。

企業複雜性的完美例子

最近我接手了朋友公司的一些諮詢項目，這些項目是由來自阿里巴巴和埃森哲的程序員構建的。我發現他們添加了如此多的複雜性，將一個只有2000或者最多20000行代碼的簡單項目分割成6個不同的微服務。這就像一個笑話。

在這種小項目中，單體架構會比微服務好一百萬倍。

如果我要說一些嚴厲的話，大公司裡的許多人就像工具一樣，比AI還糟糕，因為他們知道的太少了。他們只是將他們的部分學習應用到現實世界的問題上，不必要地使一切變得過於複雜。

當我閱讀他們過度複雜的代碼時，我有著和Linus Torvalds一樣的感受，他稱谷歌工程師的RISC-V代碼為"垃圾"，並說它"讓這個世界變成一個更糟糕的居住之地"。