開發(fā)人員有必要過度追求軟件靈活性嗎？

代碼量少了不代表軟件的復雜度降低了，而是編程語言的表達力更強了。太多開發(fā)人員癡迷于框架，過度追求軟件靈活性、可組合性等等，而忘記自己是不是真的需要這些。

在有軟件之前，只有黑暗。自從時代的黎明到來后，一直存在一個不變的事實：企業(yè)想要構建價格更低、運行更快的軟件。

當然，這是可以理解并且值得稱贊的目標——尤其是你曾經(jīng)花費時間跟軟件開發(fā)人員打過交道。每個工程師都應該全心支持此目標，并且在當前環(huán)境的約束下，應該始終努力盡可能有效率地創(chuàng)造產(chǎn)品。

然而，事實上，我們經(jīng)常做不到這一點。并非故意為之，只是隨著時間流逝，在構建軟件時會因為意料之外的復雜性而陷入困境，因此自我訓練以尋找邊界案例、差距分析以及所有可能起源于同一個需求要點的隱藏故障。

我們被大量的復雜度以及設計優(yōu)雅解決方案的精神執(zhí)念所迷惑：另一層抽象！干起來！分離相關量！繼承構成！這也是可以理解的，但是在這個過程中，我們經(jīng)常忽略正在被解決的業(yè)務問題，忘記管理復雜度是軟件開發(fā)人員次重要的責任。

為什么會造成現(xiàn)在這樣的局面？

軟件在某些方面上已經(jīng)變得更加簡單了

在過去的幾十年里，軟件產(chǎn)業(yè)非常成功地降低了編寫大多數(shù)軟件所需要的自定義代碼量。

這種減少大部分是通過使編程語言更有表現(xiàn)性來實現(xiàn)的。像 Python、Ruby 或 JavaScript 這些語言可以用不到C 語言三分之一的代碼來實現(xiàn)相似的功能。使用 C 語言取代匯編語言編寫程序也同樣帶來了類似的優(yōu)勢?？梢灶A見，在未來，語言設計不大可能帶來如同過去幾十年一樣的改進。

然而也有很多其他不需要讓語言更具有表現(xiàn)力的方法，可以精簡構建軟件的代碼總量。截止到現(xiàn)在，在過去的二十年里，我們最大的收獲是開源軟件（OSS）。如果沒有個人和公司將資金投入到他們?yōu)樯鐓^(qū)免費贈予的軟件中，沒有這么多的代價和努力，那么我們今天所構建的大部分軟件將不會實現(xiàn)。

這些項目使我們能夠站在巨人的肩膀上解決問題，利用工具讓我們更專注于解決業(yè)務問題，而不是花時間建設基礎設施。

也就是說，業(yè)務是復雜的?？尚Φ膹碗s，而且只會更多，開源軟件非常適合生成用以構建系統(tǒng)的框架和工具，但在很大程度上為了獲得關注，又必須解決大量人員共享的問題。因此，大多數(shù)開源項目要么是相對通用的，要么是處于非常受歡迎的領域。因此，這些工具中的大部分都是建立系統(tǒng)的絕佳平臺，但最終我們?nèi)匀恍枰谌找鎻碗s且要求苛刻的系統(tǒng)中構建所有業(yè)務邏輯和接口。

所以我們剩下的是一個看起來像這樣的棧（對于 web 應用程序）…

“Our Code”部分最終變得非常復雜，因為它反映了業(yè)務及其流程。如果我們有自定義的業(yè)務邏輯和自定義流程，那么我們只需編寫組建應用程序的接口、工作流程和邏輯即可。當然，我們可以嘗試用不同的方式來記錄該邏輯（記住業(yè)務規(guī)則引擎？），但最終，沒有其他人會為您的業(yè)務編寫業(yè)務邏輯。實際上似乎沒有辦法解決這個問題……至少是在機器人到來并將我們從工作中解救出來之前。

不喜歡代碼，那么低代碼（Low-Code）如何？

如果我們必須開發(fā)應用程序的接口、工作流程和邏輯，這聽起來像是難住我們了，對嗎？ 在某種程度上，是的，但我們?nèi)杂袔讉€選擇。

對于大多數(shù)開發(fā)者來說，軟件等于代碼，現(xiàn)實并非如此。 開發(fā)軟件有許多方法，其中一種是使用可視化工具。 在網(wǎng)絡普及之前，視覺開發(fā)和 RAD 工具在市場上占有更大的地位。 諸如 PowerBuilder、visual Foxpro、Delphi、VB 和 Access 等工具都具有可視化設計功能，允許開發(fā)人員在不輸入任何代碼的情況下創(chuàng)建界面。

這些工具涵蓋了需要編寫的代碼，但總的來說，你可以直觀地設計應用程序，然后編寫大量代碼來實現(xiàn)應用程序的邏輯。 在很多情況下，你仍然用編程操作接口，因為使用這些工具構建的接口通常是靜態(tài)的。 但是，對于大量應用程序，這些工具通過舍棄其他性能獲得了巨大的生產(chǎn)力，主要是以靈活性為代價。

自從網(wǎng)絡興起后，這些工具可能已經(jīng)不再流行，但公司對它們的渴望并沒有降低，尤其是因為勢不可擋的軟件需求仍然持續(xù)不斷。 整個行業(yè)最新趨勢是“低代碼”系統(tǒng)。 低代碼開發(fā)工具是最新一代拖放式軟件開發(fā)工具的現(xiàn)代術語。 這些工具和其他工具之間最大的區(qū)別在于，它們主要基于 Web（和移動端），并且通常被托管于云平臺。

許多公司正活躍于這些平臺上。Salesforce（App Cloud）、Outsystems、Mendix 以及 Kony 等廠商承諾能夠比“傳統(tǒng)”應用程序開發(fā)快許多倍。 雖然他們的很多說法可能很夸張，但也有一定的可信度。依賴類似上述平臺的所有弊端，可能的確導致某些類型的程序比使用 .NET 或 Java 的傳統(tǒng)程序開發(fā)更快。

那么，問題是什么呢？

的確有幾個問題。 首先，有經(jīng)驗的開發(fā)人員經(jīng)常討厭這些工具。 大多數(shù)嚴肅的開發(fā)人員? 喜歡使用真實代碼? 編寫真正的軟件?。 我知道這聽起來像我正在迎合一群嗚咽的嬰兒（也許我有點兒），但如果你傳遞的核心價值是技術，那么采用頂尖開發(fā)人員不喜歡使用的工具并非是個好主意。

其次，像我這樣的人看著這些被封裝的平臺，說“不，不要在這里構建應用程序”。這是合情合理的憂慮，也是最讓我困擾的事情。

如果你10 年前用 PHP 搭建了一個應用程序，那么這個應用程序可能會顯老，但它現(xiàn)在仍然可以嗡嗡作響。 語言和生態(tài)系統(tǒng)都是開源的，并由社區(qū)維護的。 你需要保持應用程序持續(xù)更新，卻不必擔心供應商斷定不再值得花時間支持。

像我這樣的人看著這些被封裝的平臺，說“不，不要在這里構建應用程序”。這是合情合理的憂慮，也是最讓我困擾的事情。

如果你 10 年前選擇了有自己平臺的供應商，那么如果他們關閉工具或頻繁更改工具（還記得 Parse 么？），你可能會被迫重寫程序?；蛘吒悖愕南到y(tǒng)會停滯在一個停止更新、不再支持服務的平臺上。

有很多理由去警惕這類平臺，但對許多企業(yè)來說，以更少的付出來搭建軟件太具誘惑以至于不忍拒絕。 軟件的復雜性仍在持續(xù)，不幸的是軟件工程師幫不上任何忙。

什么需要改變？

有高效的平臺，可以讓我們用真實代碼? 構建真正的軟件?，但不幸的是，軟件行業(yè)太過擔心于跟隨科技巨頭地領導，以至于沒有意識到他們的工具并沒有對項目添加任何價值。

我無法告訴你有多少次，曾遇到開發(fā)人員跟我說，相比于僅僅渲染 HTML，構建單一頁面應用程序（SPA）類似的東西并不會增加開銷。我曾聽開發(fā)人員說過，所有應用都應該基于 NoSQL 數(shù)據(jù)庫來開發(fā)，而關系數(shù)據(jù)庫逐漸沒落了。也曾聽開發(fā)人員質疑為什么應用程序不是用 CQRS 和事件溯源編寫的。

正是這種思維過程和常規(guī)的開銷導致公司認為軟件開發(fā)過于昂貴。 你可能會說，“但事件溯源如此優(yōu)雅！在微服務之上搭建 SPA 如此整潔！”當然，它可能是，但對你這種正在寫十個微服務的人來說不是這樣的。這種額外的復雜性往往是不必要的。

作為從業(yè)人員，我們需要找到各種方法來簡化搭建軟件的過程，并且不忽視業(yè)務的合理復雜性。 我們需要承認，并非每個應用程序都需要與 Gmail 相同層次的界面復雜性和運營擴展性。 有很多應用程序需要經(jīng)過深思熟慮的界面、復雜的邏輯、堅實的體系結構、流暢的工作流程等。但不需要微服務、AI、chatbots、NoSQL、Redux、Kafka、Containers 或任何類似的工具。

如今很多開發(fā)人員似乎對技術能力非常著迷，以至于他們不能退后一步，問問自己是否真的需要這些。

就像 MasterChef 上的人一樣，他們以分子美食家的身份入場兜售自己。 他們將原料分成不同的組成部分，使用科學配對口味的方法，然后用大量的二氧化碳和液氮來制作你見過的最有創(chuàng)意的食物。 然后他們會在一兩集之后被踢開，因為他們忘記了大多數(shù)烹飪的核心原則，即食物需要口感好。 他們似乎真的很驚訝于沒有人喜歡他們發(fā)酵的茴香和芒果精華珍珠加上抹了鳀魚沫的鱈魚肉。

對靈活性、可組合性和機敏性的癡迷正在給我們帶來巨大的痛苦，并迫使公司遠離我們所喜愛的平臺和工具。 并不是說我上面列出的那些工具不會增加價值，盡管大公司在大規(guī)模操作系統(tǒng)時會遇到典型問題，工具也僅是為了解決真正的痛點而產(chǎn)生的。

我所說的是，我們需要回到簡單化的方向，并開始以更簡單的方式創(chuàng)造事物，而不是僅僅一直討論簡單性。 也許我們可以依靠更多的集成技術棧來提供開箱即用的模式和工具，以便軟件開發(fā)人員能夠更高效地創(chuàng)建軟件。

我們將把越來越多的業(yè)務添加到“低代碼”平臺和其他通過簡化、移除起初寫過的代碼來降低軟件成本的工具中。

我們需要停止假裝二十行的程序是一些需要認真手工縫制的獨特掛毯。

聚焦簡單性

寫完之后，我仿佛聽到一百萬位開發(fā)人員磨刀的聲音，但我相信如果我們繼續(xù)堅持如下方向：想寫所有東西、配置一切、編寫所有內(nèi)容、無論多大規(guī)模的問題都使用相同的堆棧，那么我們將把越來越多的業(yè)務添加到“低代碼”平臺和其他通過簡化、移除起初寫過的代碼來降低軟件成本的工具中。

我們對業(yè)務日益復雜的回答不會增加開發(fā)過程的復雜性 – 無論它看起來多么優(yōu)雅。

我們必須設法通過簡化開發(fā)流程來管理復雜性。 因為管理復雜性是次重要的責任，我們必須始終記住軟件開發(fā)人員最重要的責任：通過使用軟件來實現(xiàn)價值。