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

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

自從低程式碼平臺到來之後，程式設計師的競爭就更加激烈了，因為不會程式碼的人幾乎都不用學會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等第三方控制元件來製作圖表。

總結

再回到低程式碼平臺！

對於開發人員來說：

對於業務人員來說：