無代碼平臺，完成業務的最後一公里

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 當今的IT行業，相比十年前有了長足的進步，雲計算、大數據、人工智能、物聯網、中間件、中臺、PAAS、各種先進算法等等概念逐步浮出水面和落地， 各種編程語言、框架、工具如雨後春筍層出不窮，縱觀整個計算機行業的發展歷史，馮諾依曼體系結構的提出使得現代計算機得以實現，計算機不再是計算器，計算器只能進行數值運算，計算機可以根據輸入的數據進行 邏輯計算，這是巨大的進步，有了邏輯，就有了解決領域問題的基礎，現實世界的領域問題歸根結底是邏輯問題，所以計算機的誕生自動化的解決了人類許多領域的領域問題，比如在線購物（電子商務）、企業管理（ERP）等等。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 我們剛纔提到計算機可以根據數據進行邏輯計算，這其中的數據就是我們所說的程序，程序的發展也有一個進化過程，從最開始的電線編排，到接下來二進制編碼寫到打孔紙帶上，再到後來的彙編語言這種方式完成程序的邏輯編寫，讓機器讀取運行，這種編程模式是面向機器的編程，它是依賴硬件的，硬件的運行結構和指令發生變化就得重新編寫程序，非常低效，可移植性很差，問題領域稍微複雜就會讓程序變得非常複雜難以維護，這個時候一些高級語言誕生，比如C、Basic等等，這些語言是面向過程和邏輯的且是線性的，非常符合人類的思考模式，這些語言通過自帶的編譯器將高層語言編譯成指定計算機硬件機器指令讓計算機運行，到現如今它依然是所有高級語言的底層邏輯，這個時候程序和計算機硬件解耦了，人們解決領域問題從以前要關心機器和邏輯到現在可以專注於如何實現邏輯，這一個里程碑的進步導致衆多語言和編譯器、虛擬運行器（例如JVM）的誕生以及到現代操作系統誕生。人類要解決的領域問題越來越大越來越複雜(現代的ERP系統已經是一個規模龐大極其複雜的系統)，試想一下通過C語言去實現這些系統，這種面向過程和邏輯的語言通過一條一條的邏輯語句去實現這些領域問題，代碼的規模得多大，人類幾乎是不可以維護的，並且極容易出現BUG，這就是軟件開發歷史上所謂的軟件危機，這個時候面向對象的方法被提出，通過面向對象的方法去分析和抽取領域問題的模型來提供計算機運行，領域問題就變成了如何分析和抽取計算機模型的問題，於是一些面向對象的語言誕生了,例如我們現在常使用的JAVA、C#等等，面向對象的方法更能真實反應現實世界的對象和問題的複雜性，這種面向領域問題的編程模型更容易去實現更復雜的業務。這其中我要強調的一點是，語言的發展史不是取代的過程，是疊加的過程，面向對象並沒有取代面向過程（C語言）和麪向機器（彙編語言）這些，面向對象依然需要過程邏輯，依然需要編譯運行器將其編譯成機器代碼輸入給計算機執行。下圖是編程語言的演進過程："}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/fc/fc93942c8ac30e5784dac8c140190b83.png","alt":null,"title":"","style":[{"key":"width","value":"100%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 前面講了那麼多，似乎跟無代碼平臺沒有關係，前面都是前人總結的經驗和提出的解決方法，從歷史去發現事物的發展規律和發展邏輯是我們常用的手段和方法，從這個底層邏輯出發，所以筆者前面講了一下計算機和編程的發展歷史，讓接下的觀點和思考有一定的依據（這裏更多是思考，不是總結和經驗）。做過系統設計的朋友都知道，在使用面向對象進行系統設計的時候，我們經常會用到UML（統一建模語言）對系統的對象進行建模並建立對象之間的關係，然後程序員根據UML模型圖將這種圖形化的表達設計語言翻譯成JAVA、C#等面向對象的程序代碼，這過程中是由程序員來完成的，那模型是由誰來完成，這裏通常是架構師和系統分析師,它們肯定要理解和深入瞭解問題領域才能設計這些對象模型，否則如何解決領域問題，你都不瞭解商品、訂單、物流這些領域對象怎麼能設計出合理的電子商務模型呢，這裏需要就是一個理解業務的人去做這項工作（不一定是架構師和計算機專業人員，對業務足夠深入和理解面向對象，並學會使用UML建模工具的人都可以做），那爲什麼是UML，UML具備那些特質了呢，第一最重要的是它是標準的語言（不是方言，方言各說各話大家聽不懂），第二是它是圖形化的表達，有句話怎麼說來着能用圖的就不要用文字（機場指個路都用箭頭加文字呢），一圖勝千言，有了這個邏輯，我們是不是可以想象一下，能不能發展出一種語言，例如圖形化表達語言，UML算是一個嘗試，它解決一部分問題，但是需要人工翻譯成JAVA等文本語言代碼（有些UML工具可以自動生成代碼，但是這些代碼通常是需要修改調整的），那我們是不是能發明一種圖形編程語言加上編譯器和運行器，直接可以運行這些定義的圖形語言，其實已經有LabView這些嘗試的案例了，UML是一種統一建模語言，它是一種標準，大家都共同遵守標準都能理解，那是不是筆者剛纔講的所謂“圖形編程語言”要制定一個標準呢？前面說過新的語言誕生並不是取代，是疊加，這個“圖形化編程語言”是不是吸收面向對象的特質，將對象模型圖形化（UML也是如此），對象之間的交互圖形化（UML也是如此），它既解決人難以理解和維護文本語言的問題（使用門檻大大降低，可以直接由能理解業務的人去寫代碼，解決程序員和產品經理溝通鴻溝問題），又不會丟失面向對象提出的通過對領域問題的分析和抽象來實現複雜業務的方法。那是不是我們所有的基礎設施例如操作系統、中間件、框架、中臺用這種圖形化語言重寫，筆者的觀點並不是，縱觀軟件的開發歷史從來也不是，筆者一直強調的疊加，操作系統解決底層邏輯和基礎設施問題，中間件解決更上一層的問題，中臺越來越接近業務，但是中臺沒有解決業務的最後一公里問題，最後一公里需要基於中臺進行組裝和二次開發最終形成能交互的軟件交付到客戶和使用者手中，就像我們經常聽到的一個概念，物流系統的最後一公里問題，整個物流系統通過基礎設施建設（各地建倉庫和物流站）快速運轉，今天在線訂購的商品，明天就能達到你所在城市或者區域，但是商品沒有到消費者手中，最終商品要到家到消費者手中才是完成了整個物流邏輯，所以雲計算、大數據、人工智能、物聯網、中間件、中臺、PAAS、各種先進算法能讓複雜需求更夠快速得到滿足，但是他沒有形成用戶最終交付產物,所以回到“圖形化編程”，它是一種無代碼的編程手段，筆者認爲定位於解決業務最後一公里問題更加合適，它可以嵌入運行在各種基礎設施（操作系統、瀏覽器、嵌入式設備）和編程框架（Winform、WPF、Vue、Spring、Spring Cloud）中，這些基礎設施和編程框架本質上提供了編程模型和入口讓程序員去寫業務代碼，例如Winform事件模型，程序員只要要將自己的代碼塊掛載到相應的事件即可完成各種應用邏輯，不用過分關心Winform這種編程模型的底層邏輯和依賴是怎麼樣的），基於以上思考，“圖形化語言”更像是直接面對更能解決領域問題的勞動者（過去是程序員現在是業務人員）去解決領域問題（勞動對象），並依附於這些框架和基礎設施，無處不在（想象如果能像UML標準化，它的生態會非常大，所有需要解決業務最後一公里的基礎設施、框架、中臺都能運行它），解決業務系統最後一公里交付到客戶手中。我看到網絡上有一種觀點，無代碼不能解決複雜問題，我想表達是無代碼從來不是要解決複雜問題，我相信很多聰明的人和偉大的公司能很好的解決複雜問題（框架、算法、中間件、中臺、新型硬件等等），我們只解決一個問題那就是由理解業務的人（勞動者）快速的把軟件（勞動對象）交付給最終的用戶，就像整個龐大的物流系統一樣，建倉庫和物流站等基礎設施我們幹不了，我們只充當一個快遞小哥角色把東西送到用戶的手中。如果把無代碼平臺要解決的問題定位錯了，你就會不自覺的否定它和排斥它。下圖表達是一個編程的核心要素："}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/b8/b8c71f66fcaa77a6a8c7c8507bf86f5b.png","alt":null,"title":"","style":[{"key":"width","value":"100%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 以上所有觀點和思考都是基於軟件的歷史發展規律和要解決的問題，並且筆者也做過小小的理論研究和實踐，這篇文章沒有講如何具體實現無代碼平臺，只是提供了一個思路並暢想了它未來的生態和定位，是不是有點激動和興奮？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}