我們公司是做機器視覺的，也在做低程式碼平臺，我覺得很有用，不知道我理解的這個低程式碼和你說的低程式碼是不是一回事。

以往的視覺專案需要根據專案需要編寫程式碼，例如用winform+halcon的話需要用c#拖拽個介面，按需求新增顯示控制元件和引數對話方塊等等，然後編寫各個控制元件、按鈕和對話方塊等相對應的程式碼，還需要自己呼叫halcon運算元實現視覺功能，最後各種通訊也需要不少程式碼。但是用我們公司的軟體平臺，常用的各種電氣裝置和相機，包括各個常用品牌常用型號，都封裝好了，用哪個直接拖拽就可以。常用的視覺功能也封裝好了，找線找圓輪廓匹配這些都有，還提供了halcon版本，visionpro版本，海康visionmaster版本等等，想用哪個自己選，這已經能解決很大一部分專案需求了，工程師做專案根本不需要寫一行程式碼。除此之外，還有針對一些行業的行業模組，可以說是定製化的運算元，如果這些都不能滿足需求，還可以在腳本里自己寫一些功能，這就是工程師唯一需要寫的程式碼。

這個低程式碼平臺對工程師來說可以節省很多時間，可以現場進行專案驗證，不需要再回公司搭建平臺寫程式碼，專案的開發週期也極大的縮短了，我覺得這個平臺用處還是蠻大的。

如果這種東西普及了，很多廠家不需要再花那麼多錢招程式碼經驗豐富的視覺工程師了，畢竟程式碼能力強的和程式碼能力一般的工資差距還是很大的，只要視覺專案經驗夠了就好，而這個的門檻要比程式碼的門檻低一些，人員選擇也就多一些。

其實低程式碼和我們傳統的開發框架本質是一樣的，大家不要為了低程式碼而低程式碼，沒有必要，也沒有太多意義去證明， 凡是能降低成本，提高交付支援，提升交付效率的方式肯定會逐步流行起來的。

我們 只需要做好產品的體驗就好，推廣交給使用者體驗後的選擇。 frame.bctools.cn

用完的感受就是：

本來1小時的活用低程式碼縮到15分鐘幹完。但是，本來2小時的活得4個小時才能幹完。

我就是做低程式碼的，客戶之前用的定製ERP，壓根沒法滿足需求，購買幾萬塊，修改調整幾乎改核心沒個五七萬以上不可能，在我們這裡花費5000多做出一整套在用，以後迭代我也說過，看需求，其實改起來很容易，一般迭代幾百塊。其他純程式碼的，你想想，如果自研軟體維護一年就幾千一萬，還不能大改（改就要破費，當然你有錢除外），所以我覺得低程式碼0程式碼是未來大勢所趨。

可能是某天某個不懂軟體系統的大佬看到個動態表單能拖拽感覺很神奇，又覺得叫動態表單太low了，還不容易懂，就自己發明了個詞，低程式碼，感覺一下高大上了，找幾個寫手忽悠一下，弄個不倫不類的東西拿出來趕緊騙錢，十幾年前做工作流的時候就有的東西，還在吹來吹去，華人能不能不騙華人

為什麼會有低程式碼?

因為傳統的有程式碼開發效率低、週期長、成本高，所以出現了低程式碼，旨在提升開發效率、降低專案成本。

降本增效的目的達到了，那為什麼大家又不相信低程式碼開發是未來的趨勢?

核心問題是-功能受限。為了提升效率，把原來程式碼實現的功能封裝成了前後端的元件，然後這些元件透過配置呈現不同的樣式或功能，這些封裝破壞了“圖靈完備性”，導致原有的有程式碼功能得不到實現，限制了軟體的功能。

所以，不光使用者不看好低程式碼，資本市場也越來越不看好低程式碼。

任何一個行業，成本越來越高、效率越來越低，必將引發變革，但軟體行業還圍繞著低程式碼和無程式碼進行變革，似乎始終跳不出程式碼開發的圈子，感覺需要有另外一種製作軟體的形式，大家覺得呢？

低程式碼更像一個商業模式/產品， 目前平臺技術能解決的是在通用/重複 場景下 非專業人員快速完成場景搭建的過程。

所以只有低程式碼無法滿足全場景的需求，只能解決特定情況下特定問題，大家可以翻閱下目前的低程式碼平臺，他們能實現的能力和場景都是非常有限的，因此 也許低程式碼 是趨勢下的階段產物，未來一定會出現基於低程式碼 之上更最佳化的架構模式。

個人鼓勵，優秀的開發者還是需要遠離低程式碼開發框架，可以更多創造低程式碼功能模組，從而提高生產力，而必須具備底層邏輯能力。就像目前幼兒程式設計學習，那就應用於教育的低程式碼框架場景，小朋友們透過拖拽，定製引數實現機器動作，這個裡面不需要寫一句程式碼，主要目的是讓小朋友具有計算機邏輯，所以我們也不能期望基於這個場景下的小朋友能立刻成為”開發者“ ，只有持續的學習，從模組到程式碼，從程式碼到語言 才能成為正真的開發者。

這是我們家老大 6歲 學習樂高程式設計圖片，興趣還不錯。

兒童樂高程式設計

低程式碼在實際生產中也有它的一些優勢，例如軟體工程的生產力提升，例如對於核心技術的保護，所以目前低程式碼的發展情景還是不錯的， 圍繞生產場景，還有更多的機會去開拓。是個好專案。

低程式碼是一類趨勢，並不是唯一的趨勢。

低程式碼要做到在不丟失細節的情況下一言以蔽之

低程式碼做相容性的業務流程還是不錯的選著，簡單化必定約束性也更強，各取所需，適合就是最好的

低程式碼是開發的未來不敢說，但確實能提高開發效率，如果未來開放更多的模板，定製+通常來縮短開發週期。

GeneXus官網截圖

我相信低程式碼開發是未來的大勢所趨。我記得我第一次接觸低程式碼是2008年在中科院軟體所讀研究生的時候，當時老闆從國外引進了一款叫做GeneXus的軟體，號稱第五代程式語言，面向流程的程式設計技術，好像是烏拉圭的一個公司，據說當時微軟也要收購這家公司，被拒絕了。

從那時起，我便用GeneXus進行開發，主要是開發服裝行業的供應鏈軟體，沒想到軟體開發還能這樣，透過簡單的拖拉拽就能自動生成表單，只需少量程式碼就可以構建複雜的業務系統，還能跨平臺生成各種語言（Java、C#等）的原始碼，開發人員可以節省大量的時間，從而專注於系統的業務邏輯設計，生產效率提升一個數量級。

當然，那時的GeneXus也存在著不少缺陷，與傳統的軟體程式設計相比，靈活度和自由度還是比較侷限，而且互動介面也非常一般，經常出一些莫名其妙的bug。但是瑕不掩瑜，GeneXus確實顛覆了我對軟體開發的認知。

最近幾年，我一直在一些中小型醫療企業擔任數字化轉型負責人，面對靈活多變的業務模式和捉襟見肘的預算，我選擇了低程式碼工具氚雲作為工具，結合智慧辦公平臺釘釘，取得了四兩撥千斤的效果。目前的低程式碼工具幾乎能覆蓋普通企業百分之九十的日常需求場景，而且對於和其他系統之間的資料互動也提供了多種解決方案，是中小型企業實現數字化轉型的不二之選。

氚雲官網截圖

我相信，低程式碼工具會進一步降低程式設計門檻，讓更多懂業務不擅長技術的人能夠開發出自己想要的軟體。未來，人人都是程式設計師！

低程式碼有它的市場，但相對整個市場來講，佔比不會太高，至少在人工智慧還不能完全替代人寫程式碼的時代是這樣，而且真到那個時代，就不叫低程式碼了，直接上人工智慧寫程式碼就好，這是我的看法。

首先，業務是靈活多變的，而非固定的形式，它的靈活性，低程式碼是很難適配到這種複雜的變化中，需要極高的針對定製化，而這種定製化，高昂的成本，過度的定製，已經違背了低程式碼設計的初衷。我對低程式碼的理解，它是一個共性的抽象罷了，為解決某類問題的公共方案，所以他就好比SaaS，針對普適性做成努力，而往往很多不缺資金的大企業，更寧願針對自己的特點來做開發，這樣一方面更能有效解決自身問題，同時也非常靈活自主，不受外部侵擾，當然，這其中也存在資料安全問題。

其次，它面向的是前臺，這是它應用的受限，因為很難說把後臺的東西，搬到低程式碼上去做，這將造成很多你無法控制的細節，而這些細節，可以讓你損失慘重。

最後，至少目前還沒有形成一個標準，連一個最基本的行業標準都沒有，更別談通用標準，無標準，如何做統一，統一，怎麼做聯動，在網際網路世界裡，資訊是聯通的，而不是孤立的，孤島即死亡，這是當前的商業法則，生態很重要。

所以，至少就目前瞭解到的資訊，我認為他存在確實有價值，但絕非“趨勢”，而是某些場景的應用方案罷了。

就問問軟體設計的時候，概要設計裡把業務流程設計，到資料庫設計，到邏輯設計物理設計，不寫程式碼夠低程式碼了吧，看看那些財務人員，操作員能不能做到

因為做低程式碼的公司自己都不用低程式碼

但我相信是趨勢，時代發展就是在不斷的抽象

只能說現在的低程式碼開發，還不算成熟吧，估計得等人工智慧發展到一定程度的時候，才有低程式碼平臺的市場。

20年前就有過了，我記得當時叫元件式開發，零件拼裝式開發，炒作過兩年，後來就沒聲音了。現在改個名叫低程式碼又拿出來糊弄人，商業營銷嘛，吸引眼球很重要，很正常。

無論什麼“程式碼”軟體，都是人開發的，你低程式碼開發實際上是別人幫你高程式碼開發掉了，有點哲學思維的一想就能明白。

很多公司自己在主流框架上封裝的各種業務框架都能算 低程式碼，但 低程式碼 這個能力要抽象出來，成為獨立的產品，確實很難。

低程式碼本質上就是讓開發越來越容易。計算機軟體發展幾十年了事實上確實是軟體開發門檻越來越低，但是到目前為止不管多低，在開發軟體的至少還是程式設計師。技術進步省下來的只是那些非業務程式碼。不管用什麼技術，業務邏輯本身的複雜度不會變，不經過訓練普通人很難把現實世界的邏輯轉換成計算機邏輯

低程式碼和程式碼複用是兩回事。低程式碼試圖把非計算機專業人員拉入到業務研發內完成最後的業務對接這本身就不可能。框架，工具是為了減少重複勞動，降低行業內部壓力，而不是把這個行業的責任交給非專業人士。就好像我給你一本說明書一張圖紙，你就能蓋房了？