軟體複雜性正在殺死我們

軟體在某些方面變得更容易了
在過去的幾十年中，我們的行業已經非常成功地減少了編寫大多數軟體所需的自定義程式碼量。

這種減少大部分是透過使程式語言更具表現力來實現的。像Python，Ruby或JavaScript這樣的語言可以只用C的三分之一的程式碼來實現類似的功能。就像C語言相比組合語言帶給了我們類似的優點一樣。展望未來，語言設計方面大概不再可能帶來像過去幾十年中我們看到的同樣進步了。

但是減少構建軟體所需的程式碼量涉及許多其他途徑，不一定需要使語言更具表現力。迄今為止，我們在過去二十年中取得的最大收益是開源軟體（OSS）。如果沒有個人和公司將資金投入到他們向社群免費提供的軟體中，那麼我們現在所建立的大部分功能就需要花費更多的成本和精力。

這些專案使我們能夠站在巨人的肩膀上解決問題，利用工具讓我們把更多的精力集中在解決業務問題上，而不是花時間建設基礎設施。

業務是複雜的，可笑的複雜性只會越來越多。 OSS非常適合製作框架和工具，我們可以用它來構建系統，但是OSS在很大程度上必須解決大量人員共享的問題，才能獲得牽引力。因此，大多數開源專案必須是相對通用的，或者處於非常受歡迎的地位。只有這樣，這些工具中的大部分才都是構建系統的絕佳平臺，但是最終我們仍然需要在日益複雜和苛刻的系統中構建所有的業務邏輯和介面。

所以我們剩下的是一個看起來像這樣的（對於Web應用程式）的堆疊...

<我們的程式碼>
<庫>
<Web框架>
<Web伺服器>
<資料儲存>
<作業系統>

“我們的程式碼”部分最終變得非常複雜，因為它反映了企業及其流程。如果我們有特殊的業務邏輯和特殊的流程引擎，那麼我們只需構建構成我們應用程式的介面，工作流程和邏輯。當然，我們可以嘗試找到不同的方式來記錄這個邏輯（業務規則引擎？），但是在一天結束的時候，沒有其他人會為你的業務寫出業務邏輯。實際上似乎沒有辦法解決這個問題......至少在人工智慧來幫我們做任何工作之前是這樣。

不喜歡編碼，那麼低編碼呢？

因此，如果我們必須開發我們自己應用程式的介面，工作流程和邏輯，那麼聽起來就這是不可避免地需要編寫程式碼，對嗎？在一定程度上，是的，但我們有幾個選擇。

對於大多數開發者來說，軟體等於程式碼，但這不是現實。構建軟體的方法有很多，其中一種方法就是透過使用視覺化工具。在網路之前，視覺化開發和RAD工具在市場上佔有更大的份額。PowerBuilder，Visual Foxpro，Delphi，VB和Access等工具都具有視覺化設計功能，使開發人員無需輸入任何程式碼即可建立介面。

這些工具涵蓋了您需要編寫的程式碼量，但總的來說，您可以直觀地設計應用程式，然後編寫大量的程式碼來實現應用程式的邏輯。在許多情況下，您仍然以程式設計方式操作介面，因為使用這些工具構建的介面通常會變得非常靜態（不能解決複雜問題）。但是，對於大量的應用程式來說，這些工具可以大大提高生產力，而且大部分都是以喪失靈活性為代價的。

這些工具的普及程度可能在Web網際網路之後就已經減少了，但是企業對這些工具的渴望並沒有，特別是在軟體需求繼續維持不可阻擋的發展程式之時。整個行業的最新趨勢是“低編碼”系統。低編碼開發工具是最新一代的拖放式軟體開發工具。這些工具和他們的以前同行產品之間最大的區別在於，他們現在主要是基於Web（和移動）的，並且通常是基於雲中的託管平臺。

許多公司都跳過這些開發平臺，像Salesforce（App Cloud），Outsystems，Mendix或Kony這樣的供應商提供比“傳統”應用程式開發效率快很多倍。雖然他們的許多說法可能是誇張的，但他們也可能有一些事實，某些型別的應用程式比使用.NET或Java的傳統企業方式能更快地構建。

那麼，問題是什麼？
那麼，帶來幾個問題，首先是有經驗的開發人員經常討厭這些快速開發工具。最嚴肅的開發者™喜歡用Real Code™編寫Real Software™。我知道這可能聽起來像是我的觀點正在迎合一群巨嬰（也許我有點兒），如果你提供的核心價值是技術，這裡觀點不適合你了。

其次，像我這樣的人看著這些有圍牆的平臺，並說“不要在那裡建立我的應用程式”。這是一個合理的問題，也是最讓我困擾的問題。

如果你十年前用PHP構建了一個應用程式，那麼這個應用程式可能會有些年代了，但它現在仍然可以執行。語言和生態系統是開源的，由社群維護。您需要讓應用程式是最新的，但是您不必擔心供應商公司不再花時間來支援您了。

如果你在10年前選擇了一個鎖定了一個平臺供應商，那麼如果他們倒閉或者大幅度改變了他們的工具，你可能會被迫重寫程式碼（記住Parse？）。或者更糟糕的是，你的系統被凍結在一個平臺上，不再滿足你的需求。

對於這些型別的平臺有很多理由要警惕，但是對於許多企業來說，用較少的努力來建立軟體的吸引力就太多了。軟體的複雜性還在繼續，不幸的是軟體工程師在這裡沒有發現任何好處。

什麼需要改變？
有產品化的平臺可以讓我們用Real Code™方式構建真正的軟體™，但不幸的是，我們現在的行業非常擔心跟隨這些大科技巨頭的領導，有時他們的工具不會對我們的專案增加很大的價值。

有多少次開發者告訴我，構建一個單頁面應用程式（SPA）的次數不會比直接使用HTML渲染而增加開銷。我聽說開發人員說每個應用程式都應該基於NoSQL資料儲存編寫，同時，宣稱關聯式資料庫已經死了。我聽說有開發人員質疑為什麼每個應用程式不是使用CQRS和事件溯源來編寫呢？

正是這種思維過程和預設開銷導致了公司認為軟體開發太昂貴了。你可能會說：“但事件溯源是如此優雅！在微服務之上構建一個SPA是如此的乾淨！“當然，這可能是事實，但是當你是編寫這十多個微服務的人時，就不是這樣了。這種額外的複雜性往往是不必要的。

作為一個行業，我們需要設法簡化構建軟體的過程，而不會忽視企業的合法複雜性。我們需要承認，並非所有的應用程式都需要擁有與Gmail相同的介面複雜度和運營可擴充套件性。整個世界的應用程式都需要經過深思熟慮的介面，複雜的邏輯，堅實的架構，流暢的工作流程等等。但不需要微服務或AI或chatbots或NoSQL或Redux或Kafka或容器或任何之類的工具。

現在很多開發者似乎對這個技術的魔術太痴迷了，所以他們不能退後一步問自己是否真的需要這些。

就像MasterChef上的人一樣，他們以美食家的身份進入和銷售自己。他們將食品成分分成不同的組成部分，使用科學的配對方法，然後用產生大量的二氧化碳和液氮作為代價生產出你所見過的最有創意的食物。然後他們在一兩次之後就被踢掉了，因為他們忘記了大多數烹飪的核心宗旨，那就是食物需要口感好。他們似乎真的很驚訝，沒有人喜歡他們的發酵茴香和芒果精華珍珠鱈魚與anch魚泡沫。

我們對靈活性，可組合性和聰明性的痴迷正在給我們帶來很大的痛苦，並迫使公司遠離我們所愛的平臺和工具。我並不是說我上面列出的那些工具不會增加價值; 它們也是為了回應真正的痛點而產生的，尤其是大型公司在大規模作業系統時經常遇到的痛點問題。

我所說的是，我們需要回到簡單化的方向，開始以一種更簡單的方式創造事物，而不是一味地談論簡單。也許我們可以依靠更多的整合技術棧來提供開箱即用的模式和工具，以便軟體開發人員更有效地建立軟體。

...我們將把越來越多的企業推到“低程式碼”平臺和其他工具的手中，這些工具承諾透過減少軟體成本，並將首先帶給我們去除部分程式設計工作，從而降低軟體成本。

我們需要停止掩蓋這樣的事實，我們在20世紀編寫應用程式實際類似需要認真手工縫製的獨特掛毯。

Software Complexity Is Killing Us - Simple Thread