我一個小鎮(zhèn)青年，大學學的電子信息專業(yè)，畢業(yè)幾年過后，就一直開始承接外包項目，才開始還行，團隊小，業(yè)務不復雜，小日子過得還算不錯，這種樣子持續(xù)好幾年，中途兜兜轉(zhuǎn)轉(zhuǎn)，團隊也沒有做大做強。有天突然幡然醒悟，找到了原因，就是團隊一旦規(guī)模大了，研發(fā)質(zhì)量不可控，研發(fā)管理難度太大，很難保證多快好省完成項目交付，我相信這是很多小的開發(fā)團隊的通病。

找尋了很久之后，發(fā)現(xiàn)自己要構建低門檻開發(fā)框架（現(xiàn)在所謂很火的低代碼開發(fā)工具），是解決這個問題的核心關鍵，然后找了一個志同道合的投資人，開始了跌跌撞撞的研發(fā)工作，一邊保持日常的項目外包，一邊開啟燒腦的做低代碼，我們的產(chǎn)品名稱為JVS，通過幾年的推進，現(xiàn)在產(chǎn)品也算是成型了，兩次推到完全重來的經(jīng)歷回想起來絕對是漫長的恐怖片。

一開始我們最簡單的想法是，低代碼開發(fā)就是像Delphi、VB那樣拖控件，然后功能就實現(xiàn)了，但這種就有個問題，那就是業(yè)務邏輯復雜化后，很難通過拖拽的組件實現(xiàn)復雜的業(yè)務，這樣導致整個平臺的靈活性受到限制，特別是開發(fā)很多業(yè)務需求復雜的定制的軟件功能時，基本上這個東西對關鍵的問題解決使不上勁了。

后面為了要滿足很多定制化的需求，結(jié)合市面上看到的已經(jīng)有成型的代碼生成的框架，又開始推進，借著mybatis這種就可以在數(shù)據(jù)庫更抽象一層來獲取元數(shù)據(jù)，由系統(tǒng)自動生成一些通用的crud的代碼，這樣可以縮減程序員的機械性重復性的勞動，程序員補充相關的邏輯代碼。這個過程一直持續(xù)了好久，在生產(chǎn)項目上也是使用這種方式，但真正執(zhí)行下來，分析出來的結(jié)果，并沒有省掉多少開發(fā)工作量。又開始絞盡腦汁找原因。

我們發(fā)現(xiàn)，在很多外包項目過程中，甲方的領導高瞻遠矚，但是他們內(nèi)部缺乏IT建設的專業(yè)性人才，往往在落地設計業(yè)務需求的過程中，缺失承上啟下的過渡，那么這個過程中，就非?？简炍覀兊漠a(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理理解能力、溝通能力強，且干事情積極主動的項目 ok，一旦缺失任何一個方面的執(zhí)行力，項目鐵定會出問題。當時就要 尋求一條新的路，去優(yōu)化這個問題。

我們找到一個關鍵點，傳統(tǒng)的產(chǎn)品經(jīng)理或者需求經(jīng)理 設計原型 需要給客戶看設計圖或者axure，很多客戶看不懂，很難意識到交付的預期效果，那么是否能把產(chǎn)品經(jīng)理設計原型這個步驟改進為直接配置可見的業(yè)務系統(tǒng)，并伴有簡單的業(yè)務操作邏輯，客戶直接上手操作，這樣大大縮短前端還原，客戶需求確認的過程，客戶看到的實際系統(tǒng)更加具象化，需求確認之后的變更大大縮減，從而減少了大量的研發(fā)浪費。 當然這個前提要求是產(chǎn)品經(jīng)理配置的工作量不能太大，門檻不能太高。

當時參考多種技術與產(chǎn)品，像Sap不光是做到這種元數(shù)據(jù)的動態(tài)加載，還做到了像程序的在線編譯，不需要通過傳統(tǒng)的編譯發(fā)布，這點像在java的groovy語言一樣，可以動態(tài)編譯運行。同時，也思考權限控制，需要比傳統(tǒng)的信息管理系統(tǒng)更加靈活，可能需要控制到數(shù)據(jù)行的權限，權限的方式也更多。這樣有了權限 元數(shù)據(jù)管理 動態(tài)語言，基本上就可以搭起來了。后面需要加入像OA這種動態(tài)表單設計，實現(xiàn)和數(shù)據(jù)庫互通，解決傳統(tǒng)OA只是文檔的問題，把表單提交的數(shù)據(jù)放入數(shù)據(jù)庫中，配搭對應的邏輯執(zhí)行，讓配置的功能真正能跑起來。

再后面就是整個系統(tǒng)的多租戶設計，還有像復雜查詢條件，多種界面控件，內(nèi)置報表集成，API和界面的動態(tài)生成，有的是加入了代碼生成器，對于復雜應用可以生成代碼，再用程序來調(diào)式應用。

這樣設計出來的整個系統(tǒng)需要很多引擎，與數(shù)據(jù)庫交互的動態(tài)數(shù)據(jù)引擎，實現(xiàn)表單功能的設計引擎，實現(xiàn)列表頁配置的列表配置引擎，實現(xiàn)報表功能的引擎，實現(xiàn)動態(tài)功能的邏輯引擎，實現(xiàn)人工業(yè)務流轉(zhuǎn)的流程引擎，實現(xiàn)權限管理靈活性的方案，實現(xiàn)數(shù)據(jù)管理的功能的方案，實現(xiàn)API開發(fā)的動態(tài)化，實現(xiàn)界面動態(tài)設計的引擎。這些你想全部都集成完美，實際上是一個很大工作量，如同開發(fā)一個高端動態(tài)化的ERP引擎一樣，這樣實現(xiàn)后，一個明顯的缺點就是整個程序很重，如在加載時需要加載很多庫，也需要專業(yè)的經(jīng)驗去操作。

當然優(yōu)點也是很明顯，就是開發(fā)速度快，數(shù)據(jù)私有化安全可控，對人員的依賴度遠遠低于傳統(tǒng)開發(fā)，而且是基于柔性的交付，靈活性相對于傳統(tǒng)系統(tǒng)要高，基本上屬性配置、熟悉需求的人員，一般普通的管理系統(tǒng)1-2周的時間就可以配置完成，大大縮短了開發(fā)的成本。

但難點就是前期客戶不解這些，客戶的技術水平一般也不高，需要培訓才能使用，或者最好有以前的程序員經(jīng)驗才能使用，這樣就限制住了客戶，相當于一個半成品的中間件一樣，不像傳統(tǒng)的產(chǎn)品是一個很簡單的使用，這樣軟件的使用需要有一定的技術水平。

大廠做這些有優(yōu)勢，也有缺點，缺點就是大廠的人工成本很高，對于客戶的定制化修改功能成本很高或者基本上就不響應，優(yōu)點就是可以充分利用現(xiàn)有的資源，快速打磨產(chǎn)品。所以這個也是決定我們的產(chǎn)品與大廠產(chǎn)品的不同之處。

我在市場上看到有的廠家使用PHP來做這樣的系統(tǒng)，其實PHP真的不適合做這種高度復雜，N多功能雜化的軟件，后面維護起來，像面條一樣，一拉動全碗，真的會導致后期復雜度指數(shù)增長。軟件開發(fā)造型時語言最好是選擇java或c#這種面向?qū)ο蟮恼Z言，使用分層框架設計，做好整個軟件的框架，這樣后面可能需要改動的比較小，也比較適合多個團隊分開功能開發(fā)。

最后發(fā)現(xiàn)，我們很多功能與簡道云、宜搭的產(chǎn)品在思路實現(xiàn)層面比較相似，或者是殊途同歸吧，但區(qū)別在于我們側(cè)重于私有化、定制化、構建技術開放的輔助研發(fā)工具，而非是靠生態(tài)的聚合平臺，畢竟體量、資源不同，所以商業(yè)模式與出路也不同。