軟件的復雜性正在殺死我們

       長春軟件開發,現在有一個常見現象：企業想要更快更便宜地構建軟件。

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

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

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

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

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

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

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

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

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

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

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

　　“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”平臺和其他工具的手中，這些平臺和工具承諾首先通過簡化和刪除把我們帶往這些平臺和工具的部分，來降低軟件成本。

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

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