最近拼多多的員工猝死事件鬧得沸沸揚揚，這場痛心的事件不僅讓人們看到了無良企業的冷血殘酷，更讓很多人深深感受到了程式設計師內卷的危機感。

當年程式設計師還屬於稀缺崗位的時候，並沒有太多的加班現象，然而隨著國外低程式碼平臺逐漸在國內興起，一場搶奪“低程式碼”市場份額的拉鋸戰正在上演。

自從低程式碼平臺到來之後，程式設計師的競爭就更加激烈了，因為不會程式碼的人幾乎都不用學會SQL，甚至零程式設計基礎的人都能迅速湧入這一行業。

但是程式設計師也不用太過於擔心，因為低程式碼並不能解決一切資料問題，你想一想如果阿里中臺都交給一群沒有程式設計基礎的人，假如雙十二崩了誰來負責呢？所以專業的開發者更熟悉資料庫、結構等知識，工作起來會更高效。

低程式碼工具的出現

現在很多的低程式碼平臺主要面向的都是企業管理軟體開發，說到企業管理軟體很多人第一時間想到的就是ERP系統，但其實低程式碼平臺是針對整個軟體開發行業的工作模式提出的，並不單單只是針對ERP系統。

而低程式碼最常見的就是將功能模組進行元件化，減少重複編寫程式碼，能夠降低業務部門、公司對IT部門的依賴，程式設計師也就不用重複去編寫程式碼，這樣能夠縮短開發週期。

但是低程式碼僅僅是一種工具，工具的價值來自使用它的人。那麼我們怎麼應該選擇低程式碼平臺呢？在阿里呆了兩年的我總結了下面三條經驗：

1、明確選型

首先要確定自己的平臺是不是用低程式碼工具開發的，是否是用自己產品開發的；其次，就要看教程和文件，看看數量質量，是否收費，然後看時間？很多平臺時間太短，啥都沒有，讓人家怎麼學？另外我覺得也不應該收費。

還有一些更邪門的，例如ClickPaaS，根本就找不到任何文件。看時間，主要是看平臺教學有沒有更新，例如牛刀，我看影片有2000年左右的，也就是20年前！

2、選擇架構型別

一般來說，C/S架構目前已經很老舊落後了，一般都比較落後，這個和低程式碼平臺的複雜性相關，如果一開始設計不好，有已經有了使用者，後期想要更新產品就會比較困難，畢竟C/S大家懂的，不光難看，而且確實這種產品早晚要被淘汰的，而且也不符合雲計算的發展方向。

因此現在比較流行的架構是B/S架構，B/S在安全性、系統擴充套件、雲支援等方面有著無可比擬的優勢，是否支援Oracle、Mysql、Mongo等多種資料庫。

比如現在市場上常見的低程式碼報表平臺FineReport，這個報表平臺就是CS(設計)+BS(使用)架構，其直接連線資料來源進行計算和展示。

3、選擇平臺分類

就以FineReport這個類Excel的報表工具，主要用於搭建財務管理、進銷存等應用，無須學會Java、PHP等各種複雜的程式語言，只需要會簡單的sql就可以進行企業級報表的開發。

其實在國內很多公司裡，絕大部分報表開發人員都不是程式設計師出身，因此就需要FineReport這樣簡單易學、使用門檻較低的工具。

對於IT人員來說，相比於其他的報表工具和程式碼報表工具，能夠大大降低學習成本，提高報表製作的效率，使用FineReport之後，只要配置好資料，1到2個小時就可開發出一張報表。

以前我們都是請第三方軟體公司來開發報表，但是有時候軟體公司不能做出來，因為他們對我們的業務和報表完全不能理解。

其次我們的報表需求變化非常大，今天是這樣，明天可能就是另外一個樣子了，而軟體公司的開發是一次性的，不滿足我們的長期需求。

最後，軟體公司來做來開發，但響應速度也很難保證，影響公司決策執行。因此我們使用了FineReport搭建報表平臺，有了這個報表平臺，我們自己的人員就可以製作報表，很方便很快捷，不需要開發人員，省了不少人力成本。

FineReport的很大優勢，是不需要專業的開發人員，隨便來一個人，只要稍微懂一點資料庫的東西，就可以做出報表。

4、實現低程式碼視覺化

FineReport不同於普通報表製作，決策報表由各個元件構成，支援圖表/佈局/引數/控制元件等元件拖拽操作；

這個工具是比較流行的響應式設計，元件擴充套件獨立支援區域性重新整理，支援元件聯動；完美實現自適應，更好地支援移動端和大屏的使用；

其實大多數是由FineReport自帶的H5圖表，此前有提到FineReport良好的開放性，可讓IT同時寫程式碼開發，所以在製作時，也可接入Echarts等第三方控制元件來製作圖表。

總結

再回到低程式碼平臺！

對於開發人員來說：

低程式碼開發解放了開發過程中繁冗、重複性編碼工作，可以有效地降低人工成本。提升開發效率：支援跨平臺部署，可以同時為多個平臺構建應用程式。

對於業務人員來說：

減少業務團隊與IT部門的溝通成本，IT人員普遍無法切身體驗業務人員實際痛點，業務人員可以透過低程式碼開發平臺自定義demo，最終交付IT團隊技術實現。降低產生差錯的機率，低程式碼開發元件化，拖拽式降低了因為人為失誤而導致的損失，且出現錯誤可以及時找到錯誤來源並加以完善。

從事網際網路5年，個人認為需要有靈活的思維方式，有效的解決方案，能夠高效低成本的解決現實中的問題，這種能力在職場中是不可替代的。低程式碼也是一種低成本的解決方案的體現。無論在什麼領域，都需要高效的生產。

1.網際網路更新的速度較快，使用者的需求在不斷變化，作為程式設計師，應不斷地學習充實自己的專業知識，提高專業技能。

2.關注領域發展的趨勢，在機遇來臨前武裝好自己，才能成為弄潮兒。

“低程式碼”最近確實很火，很多公司都在或多或少的進行低程式碼的研發或者佈局工作，何為低程式碼？不需要技術人員，普通的HR即可完成的業務工作，比如設定請假單、報銷單、審批單等功能。現在使用率比較搞的產品比如：釘釘（迎合企業、壓榨員工的一款App）。

但是站在個人角度，我很討厭釘釘，程式設計師何苦難為程式設計師，程式設計師用程式設計的思維、固定化的條條框框來限制或者制約著現在社會的勞動者，從這一點出發，中國的小學生最有發言權，這個是大資本家馬先生的功勞。

返回正題，個人感覺低程式碼研發可以從下面幾個方面入手或者解決。

1、靈活的表單設定

目前常用的表單設定或者開發，我專案中整合的技術包括（以下三種）：

自定義表單（透過ueditor設定表單，繫結資料表與表單的關聯關係）拖拽表單（透過拖拽技術，拖拽元件，將表單的內容透過視覺化拖拽佈局，比如：輸入框、單選框）程式碼生成器（我們的專案中集成了單表、主子表、樹表的程式碼生成器功能）2、線上流程設計器

有了表單如果沒有流程，表單則沒有了靈魂，如果一個表單的佈局只能增刪改查，而沒有其他輔助工具的關聯使用，則價值意義不大。

流程設計器可以線上設計流程圖、指定流程節點辦理人、流程表單關聯關係、代辦任務、已辦任務、我發起的任務、歷史任務、歷史流程定義等等功能的設定。

亮點：線上設計流程+自定義表單=無需編碼即可實現流程審批。

3、視覺化拖拽報表

有了業務資料，如果對業務資料最大化的處理，報表工具的用途就凸顯出來了，但是個人認為如果較為複雜的報表，可不比從新開發，採用目前市面上比較成熟的報表工具即可，比如：水晶報表、潤乾報表等。透過第三方工具設計完成報表後，透過外鏈的模式進行專案引用。（專案選單可靈活配置。）

我們的專案目前沒有整合業務報表，我們集成了拖拽視覺化echarts報表，透過拖拽影象化頁面、靜態、動態資料來源設定，可以無需開發即可實現視覺化報表的展示。

4、視覺化拖拽大屏

現在也是比較火的一個方向，透過畫布、各種元件、多種資料來源配置等方式，透過拖拽元件研發視覺化大屏專案，無需在重新編碼，這個方向目前比較成熟的有：阿里的datav、百度Sugar等產品，但是很多企業也在研發，因為元件一直在更新，所以產品的研發也一直在更新。（有這個興趣的朋友，可以關注下我，聯絡我，說不定我們可以一起做些事情，我下一步的計劃）

5、程式設計師的價值

隨著上面幾種情況，可能還會有其他的情況出現，更好的低程式碼意見。話說回來，所有的低程式碼只是輔助快速開發的一種手段而已，即使沒有上面的集中情況，很多程式的研發對於程式設計師來說也是非常快的，低程式碼的弊端就是靈活性大大降低，如果出現低程式碼無法解決的情況透過二次程式碼開發的話，難度可能會更大，所有程式設計師的方向或者價值：多學習新的技術和知識，時代在發展，社會在進步，一天不學習都跟不上時代，所以多接觸、多學習、多瞭解，時刻保持為程式碼獻身的精神（哈哈，玩笑話，996 請遠離）

6、低程式碼開源專案

青鋒的低程式碼開源專案，目前已實現了自定義表單、流程設計器（基於activiti的OA流程）、拖拽視覺化echarts報表、程式碼生成器、全方位的許可權系統、其他系統基礎架構的功能。

我想在這裡交接更多的朋友。

不長久，只適合內部使用。因為低程式碼就等於是低可維護性，程式語言的變革會導致低程式碼框架過時甚至成為大量軟體更新換代的瓶頸進而只能從頭再來。要知道保持自己的開放性，是一種安全，擁有較低的替換代價，否則因為一時的爽，高度依賴性會導致替換成本巨大。未來一定不堪回首。

其實只要搞清楚什麼是低程式碼就知道，程式設計師依舊是不可替代的，程式設計師最大的價值是創新，而不是從事可重複操作勞動。

目前所謂低程式碼主要是運用在一些流程比較規範成熟的專案裡，比如OA、報表、甚至簡單遊戲製作等，這些專案共同特徵就是有一套比較成熟的開發流程，就可以抽象出一些公共功能進行模組化，低程式碼要做的就是把這些模組拼裝在一起，實現一個更高階的功能。

但是人類的需求是千變萬化的，一定會有各種新想法新需求，所以就存在按需定製，就像買衣服、搞裝修，要衣服合身最好找裁縫師傅量體裁衣，要住的舒心找裝修公司按需設計。

同時，計算機技術的發展也是日新月異，一套資訊化系統不可能管用100年，即使將來出現管用100年的系統，那也是有程式猿在背後不斷更新維護的。

程式設計師想要不被替代，只有不斷學習新技術，這和是否流行低程式碼完全沒有關係，是這個行業的特性。

事物發展都具有兩面性，低程式碼平臺也有它的優勢和不足，它有自己的使用場景和目標人群。

我也做過三款類似的產品，很多都是基於元資料驅動，執行時動態解析，儲存釋出立即生效，設計時又主要有那麼幾部分：視覺化拖拽的表單設計器、業務流程設計器、報表設計器、BI 大屏設計器、組織架構（多組織體系）等，再結合移動終端等，基本就能形成一個完整的閉環，總結來說有以下幾個優點吧：

減少重複的編碼工作，提升開發效率

- 我們測算過，相比以前硬編碼的方式，開發效率提升了 60% 左右

統一規範與實現方式，減少 Bug，提高產品質量

- 統籌規劃整體的業務架構和開發規範，減少各業務組各自為政、相同功能有不同版本實現的問題

快速滿足客戶個性化需求，提升交付速度和質量

- 大部分場景不需要開發介入，實施就能處理好客戶的個性化需求，甚至有時候客戶都能自己處理

當然，這裡面也面臨著一些問題，比如：客戶個性化開發後與標準產品之間的相容和衝突的問題，既然是動態解析也會帶來一些效能的損失，當平臺功能滿足不了的時候怎麼辦...

如果你是業務開發人員，我的建議是：先會用，學習人家的設計理念和玩法，再嘗試自己動手去實踐，轉化成自己的知識沉澱下來。

在軟體開發的過程中，只有適度改進，沒有包治百病的銀彈，脫離業務場景談技術架構都是扯淡。

低程式碼火了，低程式碼開發平臺也越來越多，有人說低程式碼的興起預示程式設計師行業的沒落。其實不然，雖然低程式碼平臺已經完成了大多數的基礎功能，只需要簡單拖拽就可以實現，普通人學習一下教程就能完成，但是，低程式碼平臺只是完成了基礎框架的構建，讓開發人員不用重複的編碼，提高了開發效率，想要對程式進行二次開發還是需要開發人員來完成。還有一點，低程式碼平臺本身是在不斷的升級換代的，同樣需要優秀的程式設計師，因此，程式設計師行業是不會被低程式碼平臺替代的。不過各個行業都是一樣不進步就意味著淘汰，程式設計師需要不斷的學習新知識，跟上時代進步的步伐，提高自己的水平才不會被淘汰。