軟體的複雜性正在殺死我們

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

現在有一個常見現象：企業想要更快更便宜地構建軟體。

這當然是一個可以理解和值得稱讚的目標。且每個工程師都應該全心全意支援這個目標。

然而事與願違。雖然並非是故意的，但是隨著時間的推移，我們會因為軟體構建中難以預料的複雜性而陷入困境，然後訓練自己去尋找邊緣案例，分析差距，以及單點要求所帶來的所有隱藏的影響。

我們深陷複雜性和優雅的泥沼：再來個抽象層！自己動手！分離關注點！組合優於繼承！這也是可以理解的，但是在這個過程中，我們常常忽略了要解決的業務問題，忘記了管理複雜性是軟體開發人員的第二重要職責。

那麼我們怎麼會走到這一步？

在某些方面……軟體變得更容易了

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

這種減少大部分是通過使程式語言更具表現力來實現的。像Python，Ruby和JavaScript這樣的語言可以只用C語言三分之一的程式碼來實現類似的功能。而C語言在編寫彙編程式時也提供了類似的優點。展望未來，有很大的可能，語言設計也將提供同樣的改進。

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

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

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

所以遺留給我們的是一個看起來像這樣的（針對web應用程式）的堆疊…

<Our Code>
<Libraries>
<Web Framework>
<Web Server>
<Data Stores>
<Operating System>

“Our Code”部分最後會變得非常複雜，因為它反映了業務及其流程。如果我們有自定義的業務邏輯和自定義的流程，那麼我們只需構建構成我們應用程式的介面、工作流程和邏輯。當然，我們可以嘗試找到不同的方式來記錄這個邏輯（還記得業務規則引擎麼？），然而恐怕最後再沒人願意為你的業務寫業務邏輯。實際上似乎沒有辦法解決這個問題……至少在機器人橫空出世來拯救我們免於做任何工作之前。

不喜歡程式碼，那麼low-code呢？

因此，如果我們必須開發組成應用程式的介面\工作流程和邏輯，那麼看上去困難重重，對嗎？在一定程度上，是的，但我們有一些選項。

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

這些工具涵蓋了你需要編寫的程式碼量，總的來說，你可以直觀地設計app，然後編寫大量的程式碼來實現app的邏輯。在許多情況下，你仍然以程式設計方式操作介面，因為使用這些工具構建的介面通常會變得非常靜態。但是，對於大量的應用程式來說，這些工具可以大大提高生產力，大部分以犧牲靈活性為代價。

這些工具的普及程度可能在web接管之後就減弱了，但是企業對它們的渴望卻並沒有減弱，特別是在軟體需求的步伐依然不可阻擋之後。整個行業的最新趨勢是“low code”系統。low code開發工具是最新一代的拖放式軟體開發工具。這些工具和它們的同胞之間最大的區別在於，它們現在主要是基於web（和移動）的，並且通常託管在雲的平臺上。

許多公司前赴後繼地湧向這些平臺。像Salesforce（App Cloud），Outsystems，Mendix或Kony這樣的供應商都希望可以建立比“傳統”應用程式開發快很多倍的應用程式。雖然他們的許多說法可能是誇張的，但可能也有一些事實。雖然依賴這些平臺缺點不少，但卻能使得構建某些型別的應用程式比使用.NET或Java的傳統企業專案更快。

那麼，問題是什麼？

首先是有經驗的開發人員討厭這些工具。最嚴謹的開發者喜歡用Real Code編寫Real Software。我知道這聽起來好像是在吹毛求疵(也許是有點)，但是如果你的核心價值是技術，那麼採用那些最好的開發人員不願使用的工具並非是一個好主意。

其次，像我這樣的人看著這些有壁壘的平臺，打從心眼裡就“不願意在那裡構建我的應用程式”。這是一個合理的擔憂，也是最困擾我的問題。

如果你十年前用PHP構建了一個應用程式，那麼這個應用程式雖然可能會略顯滄桑，但它現在可能仍然可以工作良好。語言和生態系統是開源的，還有社群的維護。你需要保持應用程式的更新，但是你不必擔心供應商決定不再花時間來支援你。

像我這樣的人看著這些有壁壘的平臺，打從心眼裡就“不願意在那裡構建我的應用程式”。這是一個合理的擔憂，也是最困擾我的問題。

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

對於這些型別的平臺要警惕，但是對於許多企業來說，用較少的努力來建立軟體更有吸引力。軟體的複雜性還會繼續，不幸的是軟體工程師在這裡不能給自己任何裨益。

需要改變什麼？

有那麼多高效的平臺允許我們用Real Code構建Real Software，但不幸的是，我們現在的行業太過關心跟隨科技巨頭的領導，以致不能意識到有時他們的工具不會給我們的專案增加很大的價值。

不知道有多少次我碰到開發者告訴我，構建一些如單頁面應用程式（SPA）這樣的東西不會增加開銷，而只是渲染HTML。我曾聽開發人員說每個應用程式都應該寫在NoSQL資料儲存的基礎上，而關聯式資料庫已經玩完了。我也聽到過開發人員質疑為什麼每個應用程式不是使用CQRS和Event Sourcing編寫的。

正是這種思維過程和預設開銷導致企業認為軟體開發太昂貴了。你可能會說：“但Event Sourcing是如此優雅！在微服務之上有SPA是如此的乾淨！“當然，可能是這樣的，但是當你成為編寫這10個微服務的人時，情況就並非如此了。這種額外的複雜性往往是不必要的。

作為一個行業，我們需要設法簡化構建軟體的過程，而不忽視業務的合法複雜性。我們需要承認，並非所有的應用程式都要有與Gmail相同的介面複雜度和運營可擴充套件性。全世界的app都需要經過周詳考慮的介面，複雜的邏輯，堅實的架構，流暢的工作流程等等，但並不需要微服務或AI或chatbots或NoSQL或Redux或Kafka或Containers或任何錦上添花的工具。

現在很多開發者似乎對技術魔法本身太過痴迷了，因而不能清醒地問自己是否真的需要這些。

我們對靈活性、可組合性和智慧的痴迷正在給我們帶來很大的痛苦，並迫使公司拋棄我們所喜愛的平臺和工具。我並不是說我上面列出的那些工具不會增加價值；它們的出現是為了應對真正的痛點，儘管那些通常是大公司操作大規模系統時所遇到的問題。

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

…我們將把越來越多的業務推到“low code”平臺和其他工具的手中，這些平臺和工具承諾首先通過簡化和刪除把我們帶往這些平臺和工具的部分，來降低軟體成本。

注重簡單性

寫到這裡，我可以預見肯定有很多開發人員會磨刀霍霍，但是我相信，如果我們繼續堅持編寫、配置、組合所有內容，對所有規模的問題使用相同的堆疊，那麼我們將把越來越多的業務推到“low code”平臺和其他工具的手中，這些平臺和工具承諾首先通過簡化和刪除把我們帶往這些平臺和工具的部分，來降低軟體成本。

我們對業務越來越複雜的解決方案不能是增加開發過程的複雜性——不管它看起來多麼優雅。

我們必須設法通過簡化開發流程來管理複雜性。因為即使管理複雜性是我們第二重要的責任，我們也必須時刻牢記軟體開發人員最重要的責任：通過軟體的工作來實現價值。