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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

那么，問(wèn)題是什么呢？

的確有幾個(gè)問(wèn)題。 首先，有經(jīng)驗(yàn)的開發(fā)人員經(jīng)常討厭這些工具。 大多數(shù)嚴(yán)肅的開發(fā)人員? 喜歡使用真實(shí)代碼? 編寫真正的軟件?。 我知道這聽起來(lái)像我正在迎合一群?jiǎn)柩实膵雰海ㄒ苍S我有點(diǎn)兒），但如果你傳遞的核心價(jià)值是技術(shù)，那么采用頂尖開發(fā)人員不喜歡使用的工具并非是個(gè)好主意。

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

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

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

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

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

什么需要改變？

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

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

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

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

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

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

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

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

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

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

聚焦簡(jiǎn)單性

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

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

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