{eval=Array;=+count(Array);}
最近拼多多的員工猝死事件鬧得沸沸揚揚,這場痛心的事件不僅讓人們看到了無良企業的冷血殘酷,更讓很多人深深感受到了程序員內卷的危機感。
當年程序員還屬于稀缺崗位的時候,并沒有太多的加班現象,然而隨著國外低代碼平臺逐漸在國內興起,一場搶奪“低代碼”市場份額的拉鋸戰正在上演。
自從低代碼平臺到來之后,程序員的競爭就更加激烈了,因為不會代碼的人幾乎都不用學會SQL,甚至零編程基礎的人都能迅速涌入這一行業。
但是程序員也不用太過于擔心,因為低代碼并不能解決一切數據問題,你想一想如果ucloud中臺都交給一群沒有編程基礎的人,假如雙十二崩了誰來負責呢?所以專業的開發者更熟悉數據庫、結構等知識,工作起來會更高效。
現在很多的低代碼平臺主要面向的都是企業管理軟件開發,說到企業管理軟件很多人第一時間想到的就是ERP系統,但其實低代碼平臺是針對整個軟件開發行業的工作模式提出的,并不單單只是針對ERP系統。
而低代碼最常見的就是將功能模塊進行組件化,減少重復編寫代碼,能夠降低業務部門、公司對IT部門的依賴,程序員也就不用重復去編寫代碼,這樣能夠縮短開發周期。
但是低代碼僅僅是一種工具,工具的價值來自使用它的人。那么我們怎么應該選擇低代碼平臺呢?在ucloud呆了兩年的我總結了下面三條經驗:
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等第三方控件來制作圖表。
再回到低代碼平臺!
對于開發人員來說:
對于業務人員來說:
“低代碼”最近確實很火,很多公司都在或多或少的進行低代碼的研發或者布局工作,何為低代碼?不需要技術人員,普通的HR即可完成的業務工作,比如設置請假單、報銷單、審批單等功能。現在使用率比較搞的產品比如:釘釘(迎合企業、壓榨員工的一款App)。
但是站在個人角度,我很討厭釘釘,程序員何苦難為程序員,程序員用編程的思維、固定化的條條框框來限制或者制約著現在社會的勞動者,從這一點出發,中國的小學生最有發言權,這個是大資本家馬先生的功勞。
返回正題,個人感覺低代碼研發可以從下面幾個方面入手或者解決。
目前常用的表單設置或者開發,我項目中集成的技術包括(以下三種):
有了表單如果沒有流程,表單則沒有了靈魂,如果一個表單的布局只能增刪改查,而沒有其他輔助工具的關聯使用,則價值意義不大。
流程設計器可以在線設計流程圖、指定流程節點辦理人、流程表單關聯關系、代辦任務、已辦任務、我發起的任務、歷史任務、歷史流程定義等等功能的設置。
亮點:在線設計流程+自定義表單=無需編碼即可實現流程審批。
有了業務數據,如果對業務數據最大化的處理,報表工具的用途就凸顯出來了,但是個人認為如果較為復雜的報表,可不比從新開發,采用目前市面上比較成熟的報表工具即可,比如:水晶報表、潤乾報表等。通過第三方工具設計完成報表后,通過外鏈的模式進行項目引用。(項目菜單可靈活配置。)
我們的項目目前沒有集成業務報表,我們集成了拖拽可視化echarts報表,通過拖拽圖像化頁面、靜態、動態數據源設置,可以無需開發即可實現可視化報表的展示。
現在也是比較火的一個方向,通過畫布、各種組件、多種數據源配置等方式,通過拖拽組件研發可視化大屏項目,無需在重新編碼,這個方向目前比較成熟的有:ucloud的datav、百度Sugar等產品,但是很多企業也在研發,因為組件一直在更新,所以產品的研發也一直在更新。(有這個興趣的朋友,可以關注下我,聯系我,說不定我們可以一起做些事情,我下一步的計劃)
隨著上面幾種情況,可能還會有其他的情況出現,更好的低代碼意見。話說回來,所有的低代碼只是輔助快速開發的一種手段而已,即使沒有上面的集中情況,很多程序的研發對于程序員來說也是非常快的,低代碼的弊端就是靈活性大大降低,如果出現低代碼無法解決的情況通過二次代碼開發的話,難度可能會更大,所有程序員的方向或者價值:多學習新的技術和知識,時代在發展,社會在進步,一天不學習都跟不上時代,所以多接觸、多學習、多了解,時刻保持為代碼獻身的精神(哈哈,玩笑話,996 請遠離)
青鋒的低代碼開源項目,目前已實現了自定義表單、流程設計器(基于activiti的OA流程)、拖拽可視化echarts報表、代碼生成器、全方位的權限系統、其他系統基礎架構的功能。
代碼已開源,托管到(gitee),可以去搜索青鋒系統 下載,了解更多的關注我,私信發您下載鏈接。
我想在這里交接更多的朋友。
事物發展都具有兩面性,低代碼平臺也有它的優勢和不足,它有自己的使用場景和目標人群。
我也做過三款類似的產品,很多都是基于元數據驅動,運行時動態解析,保存發布立即生效,設計時又主要有那么幾部分:可視化拖拽的表單設計器、業務流程設計器、報表設計器、BI 大屏設計器、組織架構(多組織體系)等,再結合移動終端等,基本就能形成一個完整的閉環,總結來說有以下幾個優點吧:
- 我們測算過,相比以前硬編碼的方式,開發效率提升了 60% 左右
- 統籌規劃整體的業務架構和開發規范,減少各業務組各自為政、相同功能有不同版本實現的問題
- 大部分場景不需要開發介入,實施就能處理好客戶的個性化需求,甚至有時候客戶都能自己處理
當然,這里面也面臨著一些問題,比如:客戶個性化開發后與標準產品之間的兼容和沖突的問題,既然是動態解析也會帶來一些性能的損失,當平臺功能滿足不了的時候怎么辦...
如果你是業務開發人員,我的建議是:先會用,學習人家的設計理念和玩法,再嘗試自己動手去實踐,轉化成自己的知識沉淀下來。
在軟件開發的過程中,只有適度改進,沒有包治百病的銀彈,脫離業務場景談技術架構都是扯淡。
其實只要搞清楚什么是低代碼就知道,程序員依舊是不可替代的,程序員最大的價值是創新,而不是從事可重復操作勞動。
目前所謂低代碼主要是運用在一些流程比較規范成熟的項目里,比如OA、報表、甚至簡單游戲制作等,這些項目共同特征就是有一套比較成熟的開發流程,就可以抽象出一些公共功能進行模塊化,低代碼要做的就是把這些模塊拼裝在一起,實現一個更高級的功能。
但是人類的需求是千變萬化的,一定會有各種新想法新需求,所以就存在按需定制,就像買衣服、搞裝修,要衣服合身最好找裁縫師傅量體裁衣,要住的舒心找裝修公司按需設計。
同時,計算機技術的發展也是日新月異,一套信息化系統不可能管用100年,即使將來出現管用100年的系統,那也是有程序猿在背后不斷更新維護的。
程序員想要不被替代,只有不斷學習新技術,這和是否流行低代碼完全沒有關系,是這個行業的特性。
低代碼火了,低代碼開發平臺也越來越多,有人說低代碼的興起預示程序員行業的沒落。其實不然,雖然低代碼平臺已經完成了大多數的基礎功能,只需要簡單拖拽就可以實現,普通人學習一下教程就能完成,但是,低代碼平臺只是完成了基礎框架的構建,讓開發人員不用重復的編碼,提高了開發效率,想要對程序進行二次開發還是需要開發人員來完成。還有一點,低代碼平臺本身是在不斷的升級換代的,同樣需要優秀的程序員,因此,程序員行業是不會被低代碼平臺替代的。不過各個行業都是一樣不進步就意味著淘汰,程序員需要不斷的學習新知識,跟上時代進步的步伐,提高自己的水平才不會被淘汰。
不長久,只適合內部使用。因為低代碼就等于是低可維護性,編程語言的變革會導致低代碼框架過時甚至成為大量軟件更新換代的瓶頸進而只能從頭再來。要知道保持自己的開放性,是一種安全,擁有較低的替換代價,否則因為一時的爽,高度依賴性會導致替換成本巨大。未來一定不堪回首。
從事互聯網5年,個人認為需要有靈活的思維方式,有效的解決方案,能夠高效低成本的解決現實中的問題,這種能力在職場中是不可替代的。低代碼也是一種低成本的解決方案的體現。無論在什么領域,都需要高效的生產。