程式碼量少了不代表軟體的複雜度降低了，而是程式語言的表達力更強了。太多開發人員痴迷於框架，過度追求軟體靈活性、可組合性等等，而忘記自己是不是真的需要這些。
在有軟體之前，只有黑暗。自從時代的黎明到來後，一直存在一個不變的事實：企業想要構建價格更低、執行更快的軟體。
當然，這是可以理解並且值得稱讚的目標——尤其是你曾經花費時間跟軟體開發人員打過交道。每個工程師都應該全心支援此目標，並且在當前環境的約束下，應該始終努力盡可能有效率地創造產品。
然而，事實上，我們經常做不到這一點。並非故意為之，只是隨著時間流逝，在構建軟體時會因為意料之外的複雜性而陷入困境，因此自我訓練以尋找邊界案例、差距分析以及所有可能起源於同一個需求要點的隱藏故障。
我們被大量的複雜度以及設計優雅解決方案的精神執念所迷惑：另一層抽象！幹起來！分離相關量！繼承構成！這也是可以理解的，但是在這個過程中，我們經常忽略正在被解決的業務問題，忘記管理複雜度是軟體開發人員次重要的責任。
為什麼會造成現在這樣的局面？
軟體在某些方面上已經變得更加簡單了
在過去的幾十年裡，軟體產業非常成功地降低了編寫大多數軟體所需要的自定義程式碼量。
這種減少大部分是通過使程式語言更有表現性來實現的。像 Python、Ruby 或 JavaScript 這些語言可以用不到 C 語言三分之一的程式碼來實現相似的功能。使用 C 語言取代組合語言編寫程式也同樣帶來了類似的優勢。可以預見，在未來，語言設計不大可能帶來如同過去幾十年一樣的改進。
然而也有很多其他不需要讓語言更具有表現力的方法，可以精簡構建軟體的程式碼總量。截止到現在，在過去的二十年裡，我們最大的收穫是開源軟體（OSS）。如果沒有個人和公司將資金投入到他們為社群免費贈予的軟體中，沒有這麼多的代價和努力，那麼我們今天所構建的大部分軟體將不會實現。
這些專案使我們能夠站在巨人的肩膀上解決問題，利用工具讓我們更專注於解決業務問題，而不是花時間建設基礎設施。
也就是說，業務是複雜的。可笑的複雜，而且只會更多，開源軟體非常適合生成用以構建系統的框架和工具，但在很大程度上為了獲得關注，又必須解決大量人員共享的問題。因此，大多數開源專案要麼是相對通用的，要麼是處於非常受歡迎的領域。因此，這些工具中的大部分都是建立系統的絕佳平臺，但最終我們仍然需要在日益複雜且要求苛刻的系統中構建所有業務邏輯和介面。
所以我們剩下的是一個看起來像這樣的棧（對於 web 應用程式）…
<Our Code/我們的程式碼>
<Libraries/庫>
<Web Framework/Web 框架>
<Web Server/Web 伺服器>
<Data Stores/資料儲存>
<Operating System/作業系統>
“Our Code”部分最終變得非常複雜，因為它反映了業務及其流程。如果我們有自定義的業務邏輯和自定義流程，那麼我們只需編寫組建應用程式的介面、工作流程和邏輯即可。當然，我們可以嘗試用不同的方式來記錄該邏輯（記住業務規則引擎？），但最終，沒有其他人會為您的業務編寫業務邏輯。實際上似乎沒有辦法解決這個問題……至少是在機器人到來並將我們從工作中解救出來之前。
不喜歡程式碼，那麼低程式碼（Low-Code）如何？
如果我們必須開發應用程式的介面、工作流程和邏輯，這聽起來像是難住我們了，對嗎？ 在某種程度上，是的，但我們仍有幾個選擇。
對於大多數開發者來說，軟體等於程式碼，現實並非如此。 開發軟體有許多方法，其中一種是使用視覺化工具。 在網路普及之前，視覺開發和 RAD 工具在市場上佔有更大的地位。 諸如 PowerBuilder、visual Foxpro、Delphi、VB 和 Access 等工具都具有視覺化設計功能，允許開發人員在不輸入任何程式碼的情況下建立介面。
這些工具涵蓋了需要編寫的程式碼，但總的來說，你可以直觀地設計應用程式，然後編寫大量程式碼來實現應用程式的邏輯。 在很多情況下，你仍然用程式設計操作介面，因為使用這些工具構建的介面通常是靜態的。 但是，對於大量應用程式，這些工具通過捨棄其他效能獲得了巨大的生產力，主要是以靈活性為代價。
自從網路興起後，這些工具可能已經不再流行，但公司對它們的渴望並沒有降低，尤其是因為勢不可擋的軟體需求仍然持續不斷。 整個行業最新趨勢是“低程式碼”系統。 低程式碼開發工具是最新一代拖放式軟體開發工具的現代術語。 這些工具和其他工具之間最大的區別在於，它們主要基於 Web（和移動端），並且通常被託管於雲平臺。
許多公司正活躍於這些平臺上。Salesforce（App Cloud）、Outsystems、Mendix 以及 Kony 等廠商承諾能夠比“傳統”應用程式開發快許多倍。 雖然他們的很多說法可能很誇張，但也有一定的可信度。依賴類似上述平臺的所有弊端，可能的確導致某些型別的程式比使用 .NET 或 Java 的傳統程式開發更快。
那麼，問題是什麼呢？
的確有幾個問題。 首先，有經驗的開發人員經常討厭這些工具。 大多數嚴肅的開發人員™ 喜歡使用真實程式碼™ 編寫真正的軟體™。 我知道這聽起來像我正在迎合一群嗚咽的嬰兒（也許我有點兒），但如果你傳遞的核心價值是技術，那麼採用頂尖開發人員不喜歡使用的工具並非是個好主意。
其次，像我這樣的人看著這些被封裝的平臺，說“不，不要在這裡構建應用程式”。這是合情合理的憂慮，也是最讓我困擾的事情。
如果你 10 年前用 PHP 搭建了一個應用程式，那麼這個應用程式可能會顯老，但它現在仍然可以嗡嗡作響。 語言和生態系統都是開源的，並由社群維護的。 你需要保持應用程式持續更新，卻不必擔心供應商斷定不再值得花時間支援。
像我這樣的人看著這些被封裝的平臺，說“不，不要在這裡構建應用程式”。這是合情合理的憂慮，也是最讓我困擾的事情。
如果你 10 年前選擇了有自己平臺的供應商，那麼如果他們關閉工具或頻繁更改工具（還記得 Parse 麼？），你可能會被迫重寫程式。或者更糟，你的系統會停滯在一個停止更新、不再支援服務的平臺上。
有很多理由去警惕這類平臺，但對許多企業來說，以更少的付出來搭建軟體太具誘惑以至於不忍拒絕。 軟體的複雜性仍在持續，不幸的是軟體工程師幫不上任何忙。
什麼需要改變？
有高效的平臺，可以讓我們用真實程式碼™ 構建真正的軟體™，但不幸的是，軟體行業太過擔心於跟隨科技巨頭地領導，以至於沒有意識到他們的工具並沒有對專案新增任何價值。
我無法告訴你有多少次，曾遇到開發人員跟我說，相比於僅僅渲染 HTML，構建單一頁面應用程式（SPA）類似的東西並不會增加開銷。我曾聽開發人員說過，所有應用都應該基於 NoSQL 資料庫來開發，而關聯式資料庫逐漸沒落了。也曾聽開發人員質疑為什麼應用程式不是用 CQRS 和事件溯源編寫的。
正是這種思維過程和常規的開銷導致公司認為軟體開發過於昂貴。 你可能會說，“但事件溯源如此優雅！在微服務之上搭建 SPA 如此整潔！”當然，它可能是，但對你這種正在寫十個微服務的人來說不是這樣的。這種額外的複雜性往往是不必要的。
作為從業人員，我們需要找到各種方法來簡化搭建軟體的過程，並且不忽視業務的合理複雜性。 我們需要承認，並非每個應用程式都需要與 Gmail 相同層次的介面複雜性和運營擴充套件性。 有很多應用程式需要經過深思熟慮的介面、複雜的邏輯、堅實的體系結構、流暢的工作流程等。但不需要微服務、AI、chatbots、NoSQL、Redux、Kafka、Containers 或任何類似的工具。
如今很多開發人員似乎對技術能力非常著迷，以至於他們不能退後一步，問問自己是否真的需要這些。
就像 MasterChef 上的人一樣，他們以分子美食家的身份入場兜售自己。 他們將原料分成不同的組成部分，使用科學配對口味的方法，然後用大量的二氧化碳和液氮來製作你見過的最有創意的食物。 然後他們會在一兩集之後被踢開，因為他們忘記了大多數烹飪的核心原則，即食物需要口感好。 他們似乎真的很驚訝於沒有人喜歡他們發酵的茴香和芒果精華珍珠加上抹了鯷魚沫的鱈魚肉。
對靈活性、可組合性和機敏性的痴迷正在給我們帶來巨大的痛苦，並迫使公司遠離我們所喜愛的平臺和工具。 並不是說我上面列出的那些工具不會增加價值，儘管大公司在大規模作業系統時會遇到典型問題，工具也僅是為了解決真正的痛點而產生的。
我所說的是，我們需要回到簡單化的方向，並開始以更簡單的方式創造事物，而不是僅僅一直討論簡單性。 也許我們可以依靠更多的整合技術棧來提供開箱即用的模式和工具，以便軟體開發人員能夠更高效地建立軟體。
我們將把越來越多的業務新增到“低程式碼”平臺和其他通過簡化、移除起初寫過的程式碼來降低軟體成本的工具中。
我們需要停止假裝二十行的程式是一些需要認真手工縫製的獨特掛毯。
聚焦簡單性
寫完之後，我彷彿聽到一百萬位開發人員磨刀的聲音，但我相信如果我們繼續堅持如下方向：想寫所有東西、配置一切、編寫所有內容、無論多大規模的問題都使用相同的堆疊，那麼我們將把越來越多的業務新增到“低程式碼”平臺和其他通過簡化、移除起初寫過的程式碼來降低軟體成本的工具中。
我們對業務日益複雜的回答不會增加開發過程的複雜性 – 無論它看起來多麼優雅。
我們必須設法通過簡化開發流程來管理複雜性。 因為管理複雜性是次重要的責任，我們必須始終記住軟體開發人員最重要的責任：通過使用軟體來實現價值。