首發(fā)于為什么說低代碼是內(nèi)部系統(tǒng)開發(fā)的未來趨勢？ | 碼匠技術(shù)博客

開發(fā)人員的大量時間花在構(gòu)建內(nèi)部系統(tǒng)上

據(jù)國外的一份研究報告顯示，開發(fā)人員 30% 的時間用來構(gòu)建內(nèi)部系統(tǒng)。隨著公司規(guī)模越大，這個問題會愈發(fā)嚴重，你可以想象一家擁有 5000 員工的公司，開發(fā)人員花費近 45% 的時間在內(nèi)部系統(tǒng)開發(fā)上嗎？

圖1：來自動視暴雪員工技術(shù)分享（https://youtu.be/xCu73WVg8Ps），拳頭產(chǎn)品的背后離不開多個內(nèi)部系統(tǒng)支持

圖2：企業(yè)規(guī)模與構(gòu)建內(nèi)部系統(tǒng)所投入時間關(guān)系

如果開發(fā)內(nèi)部系統(tǒng)是用來提高我們的生產(chǎn)力，那么浪費大量開發(fā)人員的生產(chǎn)力來實現(xiàn)它是否事與愿違？

多數(shù)開發(fā)人員停留在 「從頭構(gòu)建內(nèi)部系統(tǒng)」 階段

650 名開發(fā)者/技術(shù)leader中，約 2/3 的人仍在從頭開始開發(fā)一個自定義應(yīng)用（build from scratch）。同時，大家選擇的編程語言主要是 JavaScript、HTML/CSS、SQL、TypeScript 和 Python，選擇的框架集中在 React、Express、jQuery、Angular 和 VUE.js（jQuery 能在更新?lián)Q代如此迅速的互聯(lián)網(wǎng)時代依舊受歡迎，應(yīng)該是很多老公司仍在開發(fā)和維護遺留系統(tǒng)的「功勞」）。

目前，低代碼采用者仍為少數(shù)，對于這些用戶來說，這是一個正確并且愿意繼續(xù)采用的選擇；但是對于剩下的大多數(shù)呢，伴隨著一種心理上的「傲慢與偏見」，很多開發(fā)者對嘗試低代碼猶豫不決，他們更相信他們所面臨的業(yè)務(wù)問題只能通過自己寫下的一行行代碼才能解決。

圖3：內(nèi)部系統(tǒng)開發(fā)技術(shù)選型

低代碼的本質(zhì)是在更高的抽象層次上開發(fā)

但縱觀編程語言的發(fā)展，無論是從機器語言到匯編，還是從 COBOL/FORTRAN/C 到面向?qū)ο蟾呒壵Z言，都是在朝著更高的抽象層次發(fā)展。更高的抽象化，既包括開發(fā)者便于識別、易于閱讀、更符合自然思維習(xí)慣，也意味著讓人在使用這門語言時，能夠更有效率地實現(xiàn)功能，達成業(yè)務(wù)目標。

當你在使用 React 開發(fā)一個 Web 應(yīng)用時，那么相較于寫 JavaScript 代碼，你已經(jīng)站在「巨人的肩膀」上了 —— 用傳統(tǒng)的 JavaScript 想實現(xiàn)相同的結(jié)果，需要更多更繁瑣的代碼。試問，一遍又一遍地復(fù)制粘貼相同的 HTML，還是迭代數(shù)組稍稍修改一下就呈現(xiàn)出相同結(jié)果，如果是你你會如何選擇？

圖4：純 JavaScript 與 React 實現(xiàn)一個長度為 3 的 <ul /> 對比，如果長度為 50 呢？

又試想一個場景：如果你的團隊需要為公司的網(wǎng)站實現(xiàn)一個新的支付系統(tǒng)，這個系統(tǒng)能夠提供像支付寶和微信支付一樣強大的服務(wù)嗎？況且開發(fā)與迭代像這樣復(fù)雜又龐大的程序，需要大量的時間、金錢和人力資源，等等；既然如此，我們何不將這份工作代理到支付寶或者微信等其它三方支付平臺，讓它們幫我們完成這件事呢？

天下武功，唯快不破，讓研發(fā)能專注于業(yè)務(wù)邏輯，將艱難、枯燥的工作交給框架/平臺來解決，這何樂而不為？

顯然，我們都在致力于減少編寫的代碼量、提高開發(fā)效率、更加專注于業(yè)務(wù)邏輯而不是與底層技術(shù)細節(jié)纏斗。應(yīng)運而生的低代碼便是時代變化的產(chǎn)物。

拒絕當 CRUD Boy

「內(nèi)部系統(tǒng)」的主要目的是企業(yè)內(nèi)部信息管理，包括 BI 數(shù)據(jù)看板、Admin后臺、數(shù)據(jù)錄入系統(tǒng)、客服系統(tǒng)，等等。

圖5：程序員開發(fā)的部分內(nèi)部應(yīng)用類型

這些系統(tǒng)往往業(yè)務(wù)邏輯復(fù)雜，研發(fā)們需要考慮數(shù)據(jù)庫的 CRUD 操作、UI 界面的搭建、交互的串聯(lián)，此外還有一大堆成員管理、權(quán)限、審計日志，等等。在大多研發(fā)人員選擇「一切從頭開始開發(fā)」的現(xiàn)狀下，他們所投入大量的時間精力可能都不是在解決真正的業(yè)務(wù)問題，而是在重復(fù)性的造輪子以及大量粘合代碼、模板代碼中。

圖6：開發(fā)者都不甘心只做 CRUD Boy

相比枯燥重復(fù)的工作，相信大多數(shù)人更想去解決有趣的事情（建模并解決實際業(yè)務(wù)問題）。重復(fù)性 CRUD 已經(jīng)走向末路，低代碼應(yīng)用開發(fā)時代已經(jīng)到來。

寫在最后

作為開發(fā)人員，很多人希望對我們開發(fā)和維護的東西擁有所有權(quán)，當他們被分配一項使用低代碼平臺拖放（drag & drop）加少量代碼就可以完成的任務(wù)時，他們或許會覺得自己不再是一名「真正的」程序員。類似的問題像是網(wǎng)上經(jīng)常會有人討論使用可視化編輯器 WordPress 的人是否是一名「真正的」程序員，使用 Shopify 快速搭建電商網(wǎng)站的人是否是一名「真正的」程序員…… 這種情況數(shù)不勝數(shù)，但我們對這類問題的答案很簡單：是的。

我選擇低代碼，與此同時我堅信自己是一名「真正的」開發(fā)者，因為正如在「低代碼的本質(zhì)是在更高的抽象層次上開發(fā)」這一章中提到的，如果沒有站在「巨人的肩膀」上，我很難獨立從頭開始敲代碼。NASA 的瑪格麗特·漢密爾頓，一位偉大的軟件開發(fā)先驅(qū)，她所寫的代碼量用紙質(zhì)形式呈現(xiàn)足足有一人高。可如今我們有多少人能做到這樣呢？這難道就意味著我們不是「真正的」開發(fā)者了嗎？我不這么認為。

圖7：瑪格麗特·漢密爾頓，程序員版本的「著作等身」

此外有一種現(xiàn)象叫「宜家效應(yīng)」，是指消費者對于自己投入勞動、情感而創(chuàng)造的物品，產(chǎn)生高估的價值判斷偏差的現(xiàn)象；這解釋了為什么即使有更好、更簡單的替代方案，很多研發(fā)仍會選擇從自己的敲下的一行行代碼中獲得很多成就感。因此，越來越多的低代碼平臺，如碼匠、海外的 Appsmith、Retool、Budibase 等，也開始注意到平臺的可編程性、可擴展性與靈活性，并不斷摸索最佳實踐，力圖為程序員提供更多的發(fā)揮空間，讓他們享受「宜家效應(yīng)」所帶來的快樂。以碼匠為例，我們在保留了低代碼高度抽象化特性的同時，提倡「到處可寫 JavaScript」：「{{ }}」 中的語句都會被執(zhí)行為 JavaScript 代碼并在沙箱（Sandbox）中執(zhí)行；我們也支持模塊化（Module）編程，你實現(xiàn)的代碼塊可以快速為團隊其他成員復(fù)用……等等。

圖8：碼匠 「{{ }}」中的語句會在 JavaScript 沙箱（Sandbox）中執(zhí)行

圖9：碼匠幾乎可以在任何地方通過編寫 JavaScript 解決實際業(yè)務(wù)問題

閱讀到這里，如果還有人問我如何看待低代碼，我可能會這樣來反問 Ta：倘若有五個開發(fā)人員，你是愿意讓他們五個從頭開始，全職開發(fā)與迭代一個內(nèi)部系統(tǒng)，還是選擇一個低代碼工具，讓其中一位去開發(fā)它，其余四位來開發(fā)公司的實際產(chǎn)品呢？