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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

拒絕當(dāng) 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)限、審計(jì)日志，等等。在大多研發(fā)人員選擇「一切從頭開始開發(fā)」的現(xiàn)狀下，他們所投入大量的時(shí)間精力可能都不是在解決真正的業(yè)務(wù)問題，而是在重復(fù)性的造輪子以及大量粘合代碼、模板代碼中。

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

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

寫在最后

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

我選擇低代碼，與此同時(shí)我堅(jiān)信自己是一名「真正的」開發(fā)者，因?yàn)檎缭凇傅痛a的本質(zhì)是在更高的抽象層次上開發(fā)」這一章中提到的，如果沒有站在「巨人的肩膀」上，我很難獨(dú)立從頭開始敲代碼。NASA 的瑪格麗特·漢密爾頓，一位偉大的軟件開發(fā)先驅(qū)，她所寫的代碼量用紙質(zhì)形式呈現(xiàn)足足有一人高?？扇缃裎覀冇卸嗌偃四茏龅竭@樣呢？這難道就意味著我們不是「真正的」開發(fā)者了嗎？我不這么認(rèn)為。

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

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

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

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

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