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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

那么，問題是什么呢？

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

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

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

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

如果你 10 年前選擇了有自己平臺的供應(yīng)商，那么如果他們關(guān)閉工具或頻繁更改工具（還記得 Parse 么？），你可能會被迫重寫程序。或者更糟，你的系統(tǒng)會停滯在一個停止更新、不再支持服務(wù)的平臺上。

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

什么需要改變？

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

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

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

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

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

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

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

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

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

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

聚焦簡單性

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

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

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