今天我們聊一聊自動化生成程式碼的問題，試想一下，假如有一天機器替代你編寫程式碼，你是應該感到開心還是難過？
方案
目前程式碼生成技術主要有以下幾類：
1）基於模版編排生成程式碼
首先說下基於模版生成程式碼的方式，這種屬於最原始最簡單也是目前應用最廣泛的一種程式碼生成方式，可以說，幾乎所有的程式碼生成方式都是建立在模版的基礎上繁衍而來。
前端最有名的莫過於vue-cli和create-react-app兩款腳手架的程式碼生成了，他們分別基於vue和react框架進行的一鍵初始化專案生成程式碼，包括各公司內部的專案生成的腳手架，其實本質上是一樣的，只是加入了公司內部整合的很多公共的元件和方法而已。
其實最早的程式碼生成並不是前端，因為那個時候還沒有前端這個概念，在WWW全球資訊網的時代，頁面基本是由後端進行開發，因此在模版程式碼生成這一領域我們只是走了後端走過的路。
記得最早接觸模版程式碼生成的是在剛開始開發後端專案的時候，那時候還是採用MVC架構，要開發一個新的功能模組的時候，往往需要分別對controller,service,dbService中進行新的程式碼注入，有點類似於egg中的結構（如果不熟悉後端開發的話），因此這種機械化比較固定的結構化組織中，往往通過命令一鍵生成即可，然後再對service/dbService中寫入獨特的邏輯即可。
這種開發模式能節省很多開發時間，且上手容易，開發者往往只需要關注邏輯開發即可，但往往會出現很多重複性的程式碼，這也是自動化程式碼生成一直存在的弊端。
2）基於視覺化UI生成程式碼
基於視覺化搭建的程式碼生成，這也是目前市場上最多的一種產物，也是很多視覺化搭建文章強行給它帶上的一種帽子，但準確的說它並不完全屬於自動化生產程式碼，只是其中的一個環節而已，由於它需要過多的加入人為干預，最終才能得到我們想要的執行程式，感覺它一點都不自動化，如何對得起“自動化”三字？
但視覺化搭建的確能帶來一些節約生產力的功能，同時也給其他角色賦能，搭建應用的不一定是開發了，他們甚至可以不需要懂任何程式，可以是設計、產品和運營。
其中最為成熟的莫過於汽車行業生成程式碼。對，你沒看錯，就是汽車行業，在我們的印象中，汽車行業屬於比較傳統的行業，似乎與新興產業網際網路的程式碼程式設計八竿子打不著。然而，在2010年之前，大多數的汽車控制軟體，如發動機控制元件、變速箱軟體、車身控制軟體等都是通過手寫C程式碼完成的。開發流程如下：
其中設計師是不懂程式碼的，從設計圖交付開始到最終控制器的完成，這一過程會出現兩個問題，設計師與碼農之間的溝通成本以及碼農的交付質量，專案越大這兩大問題就越突出，直接影響交付日期、成本和質量，通常情況下交付時間與成本成反比，與質量成正比，而時間就是金錢的今天，要同時保證成本和質量，更好的辦法就是設法將將程式碼標準化，同時降低溝通成本。
因此，視覺化UI生成程式碼似乎是最合適的途徑。它從設計師的角度出發，將檢視UI與命令列一一繫結，設計師拖動一個檢視即生成一個對應的C程式碼。最終，碼農下崗了。
上面這種成熟的Simulink軟體處理的視覺化邏輯的控制，只能處理簡單的邏輯，與現代的邏輯編排的設計理念相同。當然它也有自己的缺點就是不適合複雜的專案工程，在這種場景，它反而比直接寫程式碼的效率更低。
另一個著名的視覺化UI生成程式碼例子，便是.NET時代的eclipse的web搭建，使用過eclipse編輯器開發web介面都應該知道這個工具，如圖\
只是它在開發者的使用者體驗上比不上網頁三劍客，最終被淘汰了，畢竟它只是主打JAVA開發的IDE，開發Web視覺化也只是其中一個擴充套件而已，這裡也告訴我們一個道理，一個產品的精而美，比大而強反而更容易獲得成功。專注而頂尖，是很多產品的成功奧祕。
當然目前視覺化搭建的系統，是在太多了，目前主要分為兩種方式，執行時搭建和生成原始碼搭建，這裡就不一一展開介紹了。
3）基於程式碼語料生成程式碼
基於程式碼語料生產程式碼的前提是要有足夠的語料，也就是程式碼片段。這種方式，通常都是基於IDE的外掛而開發的應用。因為它最終的目的是為了開發提效，針對的使用者群體是開發者，必須有開發介入生成一個半成品的程式碼片段或模組。
假如你有耐心閱讀到此，說明你是對程式碼生成領域感興趣的同行，為了表示感謝，接下來會安利一波福利。這裡的福利也只是針對前端開發，主要是針對vscode外掛展開介紹。
這裡其實需要分為簡單和複雜兩種場景：
- 固定語料
- 智慧化語料
固定語料
使用者提前設定的程式碼片段，通過監聽使用者輸入快捷鍵值，搜尋出對應的片段，提示使用者。\
針對vue的提示外掛Vue 3 Snippets\
針對react的提示外掛ES7 React/Redux/GraphQL/React-Native snippets\
上面兩款外掛的下載量都是百萬級別以上的，所以流行程度是絕對槓槓的，當然如果你覺得它們不好用，或者不夠貼切公司內部的程式碼片段，也可以自己定製。
這種生成程式碼方式，簡單而快速，但也存在其弊端，固定化不好擴充套件，而且最令人不快的是使用者需要一定的學習成本，需要提前瞭解鍵值以及對應的程式碼片段。
為了解決這個弊端，於是聰明的程式設計師們便加入智慧化，利用訓練學習法找出對應的程式碼片段，於是有了接下來的智慧化語料。
智慧化語料
1）Kite Autocomplete外掛\
首先介紹第一個智慧化程式碼提示vscode外掛Kite Autocomplete，在超過2500萬個檔案上訓練的ML模型，Kite 為您的程式碼編輯器新增了 AI 驅動的程式碼完成功能，賦予開發人員超能力。\
它會根據使用者輸入的上下文以及當前輸入，預判使用者將要輸入的內容。
在安全方面，kite在本地執行，您的程式碼是私有的，不會離開您的機器。
這種智慧化輸入是依賴n-gram模型（不瞭解n-gram模型的童鞋可以自行搜尋瞭解一下），只不過它比n-gram模型做得更前一步，會預先讀取整個檔案的上下文，結合當前的輸入再推斷出使用者的行為。
總體上，Kite Autocomplete外掛還是蠻好用的，它支援多種語言，使用vscode編輯器的同學強烈建議使用，在這裡給你們種草了，超好用，誰用誰知道。
2）GitHub Copilot外掛\
接下來介紹另一個智慧化程式碼提示vscode外掛GitHub Copilot，它是OpenAI與微軟聯手推出的一款AI程式碼生成程式碼工具，可以說它是vscode官方親兒子也不為過，不過要使用它需要註冊。讓我們看看你它的官方介紹
GitHub Copilot 由 OpenAI 建立的新 AI 系統 Codex 提供支援。GitHub Copilot 比大多數程式碼助手理解的上下文要多得多。因此，無論是在文件字串、註釋、函式名稱還是程式碼本身中，GitHub Copilot 都會使用您提供的上下文併合成程式碼以進行匹配。我們正在與 OpenAI 一起設計 GitHub Copilot，以便在開發人員使用它時更智慧地生成安全有效的程式碼
它最大的核心競爭力便是可以根據註釋自動生成程式碼，也就是說你告訴編輯器功能描述，它便可以自動幫你生成你想要的程式碼了，聽起來是不是很酷？它實現原理如下：
當然，它也可以自動填充重複程式碼，GitHub Copilot 非常適合快速生成樣板和重複程式碼模式，這個功能完全就是將上述介紹的固定語料包含了進去，可以說對需要寫大量模版程式碼的程式設計師是非常香的一個操作。
另一個比較重要的功能便是測試程式碼，官方表示無需辛苦的測試。 測試是任何強大的軟體工程專案的支柱。匯入單元測試包，讓 GitHub Copilot 建議與您的實現程式碼匹配的測試。\
據官網介紹，它是一款基於訓練集卻可以生成從來沒出現過的新程式碼的工具，聽起來是不是很牛？它居然可以“建立”程式碼了。
最後也是最重要的一點，GitHub Copilot外掛暫時只提供有限使用者的試用體驗，目前只有預覽版本，總之一句話，暫時用不了。
4）基於智慧化生成程式碼
1）sketch2code\
介紹完GitHub Copilot後，下面讓我們瞭解微軟的另一款智慧化生成工具sketch2code
它的主要功能是將手繪圖轉化HTML程式碼。
它實現的過程如下：
1.首先，使用者通過網站上傳圖片。
2.自定義視覺模型預測影像中存在哪些 HTML 元素及其位置。
3.手寫文字識別服務讀取預測元素內的文字。
4.佈局演算法使用來自預測元素的所有邊界框的空間資訊來生成容納所有元素的網格結構。
5.HTML 生成引擎使用所有這些資訊來生成反映結果的 HTML 標記程式碼。
於是我趕緊試了一波，效果如下：
左中右分別為草稿原圖，識別分析圖，結果html
由於是橫屏的角度，嗯嗯，我原諒你，再來個正常的吧
識別度還是不太理想呀。
同時它還支援攝像頭識別，也就是說只要加上硬體裝置，產品就可以一邊在上面bibi……哦不對，是一邊規劃，一邊生成程式碼，只不過是原生的html程式碼，我又趕緊試了一波，結果:
上面是攝像頭拍到的快照，上傳之後……
啥？識別不出，好吧。估計是我畫得比較潦草，而且可能圖片背景不是全白的，於是乎我用了它官方提供的示例圖
效果好一點，但還是不能完全識別出來。
所以它目前還是有些缺陷的
- 生成結果只能是原生HTML
- 識別率較低，草稿圖還原度有待提升
2）teleporthq
另一款AI智慧化程式碼生成工具是teleporthq，它與上面的sketch2code原理很相似，只是它更進一步，如圖
產品經理一邊在小黑板上畫圖，後面的機器一邊掃描，識別並生成程式碼，同時實時給出預覽效果。真正做到了一邊畫草稿一邊生成程式碼，實現自動化生成程式碼功能，原文請前往(https://teleporthq.io/blog/we...)。
teleporthq它的官網似乎與普通的視覺化搭建器並沒有什麼不同，然而，如果仔細觀察，你會發現它其實比普通的視覺化搭建器更多一些東西，比如支援草圖到程式碼，視覺API，而這些東西正是結合硬體裝置實現程式碼實時輸出必不可少的東西。當然它識別草稿圖的辨識度就ememem~，除了草稿圖，它也是支援識別Sketch素材的。
目前它支援生成的目的碼有React/Vue/Angular等，更多可前往其官網https://teleporthq.io/
teleporthq與國內阿里的imgcook原理上很相似，只是imgcook識別的是各種設計師的素材(Sketch/PS/Figma)並將其生成多種目的碼，imgcook就不一一展開介紹，讀者可自行鑑賞。
結論
今天我們從網際網路的發展歷史分別介紹了自動生成程式碼的幾種方式：
- 基於模版編排生成程式碼
- 基於視覺化UI生成程式碼
- 基於程式碼語料生成程式碼
- 基於智慧化生成程式碼
無論如何發展，其本質其實從來沒有變過，那就都是基於模版本身，變的只是轉換規則。
文/Alan
關注得物技術，做最潮技術人！