Dmitriy Gakh 著
Conmajia 譯
原文發表于 2018 年 12 月 14 日 CODEPROJECT. 中文版已獲作者授權.

全文約 3700 字，建議閱讀時間 8 分鐘.

主要講述自動化代碼生成的一般性概念，實現了兩個可以寫程序的機器人碼農

第一個碼農（簡單，性能差）

第二個碼農（復雜，性能好）

運行之前先讀讀代碼使用說明. 機器人寫的程序

簡介

為了滿足不斷增長的方法學需求和硬件性能，軟件開發技術已經有了長足進步. 自動化在軟件開發過程中對簡化人工勞動起著越來越重要的作用. 軟件開發自動化包含多個方面，例如代碼構建管理器、靜態代碼分析器、自動測試等系統.

另一方面，人工智能和機器人方面的研究顯著進步，機器人（bot）軟件家族得到了蓬勃發展. 機器人們實現了預設的邏輯操作，只要硬件能跟上，它們的能力幾乎沒有限制. 而現代軟件開發技術可以應用到機器人上，讓它們具備可以編程開發的能力.

這篇文章介紹了創建軟件開發機器人的一般概念，從現代軟件開發的角度展示了這一概念. 文章還附帶了兩個機器人碼農的例子作為演示. 寫作本文是為了拋磚引玉，啟發讀者學習現代編程技術，并應用到現實生活中. 我只是初步闡述了自己的一點想法，讀者中能人眾多，希望能對此篇拙作加以斧正.

導讀

本文兩個主要章節：

• 思路部分主要是一般概念闡述
• 機器人碼農部分主要是兩個機器人碼農的實現

讀者可以從感興趣的部分開始閱讀.

術語

ATDCG，（Automated Test-Driven Code Generation）測試驅動的自動代碼生成
SDB，（Software Development Bot）軟件開發機器人
TDCG，（Test-Driven Code Generation）測試驅動的代碼生成
TDD，（Test-Driven Development）測試驅動的開發

思路

軟件開發的發展

引發 SDB 領域研究的最初問題是“軟件開發技術是如何開發的？”，了解軟件開發技術的趨勢非常重要，這些知識有助于創造未來的愿景. 編程范式的前幾個階段可以簡要描述為：

代碼序列. 早期由于硬件能力較弱，一般的軟件都是程序員單打獨斗完成的. 這些程序通常是以非結構化的形式開發的.

結構化編程. 隨著需要解決的問題涉及范圍不斷擴大，需要不斷增加編程代碼量. 為了更好管理代碼，出現了分塊組織的代碼結構.

面向對象編程. 代碼塊結構不斷增長，最終組合成一種新的稱為對象的結構. 代碼塊之間關系的數量和復雜性也在增加. 引入了一些新的關系結構，比如封裝、集成、多態等. 編程模型反映了復雜系統的特征，不同的單元執行不同的操作，和現實生活中的參與者及過程密切相關.

問題是：下一步是什么？編程方法朝著什么方法發展？

簡化的 TDD 過程

TDD 是開發的進化方向，它結合了測試優先的開發，在開發或重構代碼前編寫測試. TDD 不是一種簡單的編程技術，而是一種重要的敏捷需求和敏捷設計技術，其目標是編寫干凈而有效的代碼. TDD 是解釋本文主要思想的一種簡潔方法. 本文以 TDD 作為進一步闡述的基礎，給出了描述 TDCG 方法論的清晰路徑. 完整的 TDD 過程包含代碼重構階段，通過測試確保代碼正確. 在創建新代碼階段，不需要重構，可以簡化 TDD 過程. 簡化后的 TDD 主要有：創建測試，開發軟件單元，可能重復開發任務，直到代碼通過測試階段.

圖 1 簡化的 TDD 過程

幾乎所有描述 TDD 任務的信息來源都關注到有的處理可以自動進行而減少人工工作這一事實. 其中尤為重要的一項特性是，自動任務運行的是經過證明的算法，性能穩定，但是人工執行的任務反而會引入錯誤. 換句話說，測試及軟件的開發者有責任保證他們工作的質量. 故而考慮簡化 TDD 過程時的主要任務可以從職責角度進行描述：

• 創建測試：影響整個軟件開發單元的主要任務
• 運行測試：經過證明的自動過程，本身不會引入錯誤
• 開發軟件：由程序員實施，通過測試保證其工作的質量

盡管本文考慮減少程序員對其工作的責任，但這意味著只有通過測試才能保證工作的質量. 為保持解釋的簡單性，暫不考慮其他質量指標，如代碼可讀性、開發時間、代碼性能等.

測試驅動的代碼生成

Raphael Marvie 在《測試驅動的代碼生成簡介》[Marvie, 2006]一文中描述了測試驅動的代碼生成（TDCG）技術. Marvie 是在 TDD 處理的范疇內描述 TDCG 的，而本文將自動代碼生成視為一種獨立的技術，而不是 TDD 的一部分. 但是，所考慮的技術與 TDD 和其他信息技術有著密切的關系. 自動代碼生成基于先前編寫的測試，因此可以將其命名為測試驅動的自動代碼生成（ATDCG）.

上述推理表明，只有運行測試是自動化的，但創建測試和開發軟件是 TDD 中的人工實施的任務（這些任務可以部分自動化，但不能完全自動化）. 事實上，由于軟件開發任務的質量是通過測試自動控制的，開發也可以完全自動化. 人類的角色將收縮為僅負責創建測試. 從業務的角度來看，這意味著程序員為軟件單元創建、描述需求，而這些單元將根據需求自動創建. 因此，自動軟件開發可以被看作是上述簡化 TDD 過程的一種演變.

圖 2 自動化 TDD 過程

自動化測試

傳統的自動化軟件測試方法有一個稱為代碼覆蓋率（code coverage）的特性. 這是用于描述在特定測試單元運行時，程序源代碼的執行程度的度量. 較小的代碼覆蓋率意味著存在未經自動測試的代碼. ATDCG 技術從零開始創建代碼，因此可以保證測試完全覆蓋所有代碼. 換句話說，它有 100% 的代碼覆蓋率. 也正是因為這個特性，代碼覆蓋率無法用于衡量 ATDCG 成功與否. 于是，應該考慮引入新的指標，通過測試來衡量實際的業務問題覆蓋率. 這一事實將成功與否的度量從軟件開發領域轉移到業務分析中. 關于這方面的話題已經超出了本文討論的范圍，不再贅述.

ATDCG 中測試的角色

創建測試是 ATDCG 過程中唯一需要人工執行的任務. 測試是軟件單元自動生成過程的主要驅動，同時保證了過程的質量. 因此，ATDCG 中的測試具有以下特點：

• 整個 ATDCG 過程和結果的質量均取決于測試
• 創建測試是 ATDCG 最主要和最敏感的任務
• 與經典方法相比，創建測試與業務需求較創建軟件代碼的關系更為密切
• 需要研究、制定用于創建 ATDCG 測試的方法和規則

機器學習

正如前面提到的，ATDCG 開發的軟件單元質量完全取決于測試. 反過來，測試的創建在很大程度上與業務需求相關，而不是與編程相關. 從另一個角度來看，測試將以聲明性的方式描述，并包含大量的規則、數據. 因為測試創建過程與業務需求相關，所以這些數據應該具有足夠高的抽象級別，以使測試創建者能夠方便地根據業務需求開發測試. 與傳統的測試方法相比，測試設計的高抽象級別和大量數據引入將導致復雜性的增加. 創建測試和運行 ATDCG 可以描述為：

• 以聲明形式創建測試并考慮實際物理數據的數量
• 將創建的測試或其一部分視為軟件單元自動創建的訓練數據

這些觀察結果表明 ATDCG 與有監督學習（supervised learning）有很深的關系，后者的相關理論和技術可以應用于 ATDCG 領域的研究.

社會影響

ATDCG 旨在完成軟件開發任務的自動化，它將使程序員從這個角色中解放出來. 同時，測試分析師和創建者的角色成為成功運行 ATDCG 的關鍵. 此外，ATDCG 的開發顯然將滿足兩條 Unix 編程規則 [Raymond, 2003]：

經濟規則：程序員的時間是昂貴的，節省人的時間優先于機器時間

生成規則：盡可能編寫一些程序，由它們負責編寫其余的程序

因此，ATDCG 可以認為是一種軟件開發技術，它可以帶來更多的機會，為進一步研究這一問題提供機遇.

機器人碼農

這里的機器人指的是軟件機器人（software robot）. 本節講述兩個 SDB 的創建過程.

• 1 號：最簡單的 SDB，用于展示概念，性能較差
• 2 號：更好的性能，可以在 5-10 分鐘內得到結果（Intel i7）

問題

本文試圖給出一個盡可能簡單的解釋，以提出該技術的一般概念. 在這種情況下，最小的軟件單元可以只是一個簡單的函數，由一個寫在高級語言上的代碼行表示. 下面兩個例子的目的都是基于訓練數據在 C# 語言上創建一個簡單的函數. 在每種情況下，測試將檢查輸入功能輸出值的等效性.

訓練數據

輸入參數 \(a\) 和 \(b\)，輸出 \(f\) 在下表列出：

表 1 訓練數據$a$$b$$f$

38	2	1463
4	11	80
51	7	2645
12	32	313
6	21	150
20	38	599
25	43	849
3	19	113
40	34	1779

這些數據是用多項式 \(f=a^2+5b+9\) 得到的. 用這些數據檢查創建的 SDB 是否正確操作. 在現實世界中，目標函數和測試很可能是未知的，并且非常復雜. 根據訓練數據，機器碼農理應找到與上述多項式相等的函數，但其結果可以有不同的形式. 在結果一節可以看到，機器人根據訓練數據發現了多個版本的實現.

1 號機器人

前面說過，1 號機器人用于演示 SDB 的主要概念，它的性能較差，但勝在代碼簡潔. 1 號以 C# 語言創建 \(f(a,b)\) 形式的函數，產生類似這樣的代碼片段：

namespace Program {public class WorkingClass{public static int F(int a, int b){return XXX;}} }

機器人需要做的根據表 1 的訓練數據，找到標為 XXX 部分的正確的 C# 語句，最后輸出完整的程序. 在這個例子里，機器人碼農在編程時將用到四個算術運算符（+、-、*、/）、兩個變量（a、b）和 9 個數字（1、2、3、4、5、6、7、8、9）.

作為例子，1 號機器人程序實現的算法也很簡單：

通過將從字母表中隨機選擇的符號插入到 XXX 位置來創建代碼

把代碼編譯到 RAM。如果編譯失敗，回到 1

運行訓練數據集函數

比較實際的函數輸出和訓練數據集的結果，如果有任何不同，回到 1

打印找到的函數

算法用 C# 實現，使用了反射、動態代碼生成等技術.

性能

這種簡單算法的性能非常之差. 對一個有 4 個操作和 5 個變量的程序來說，最多可以有超過 4100 萬個不同符號組合，這對于簡單的迭代而言計算量太大. 使用普通 PC 是無法勝任的. 就這個例子而言，我在配備 Intel i7 四核處理器的 PC 上花了 10 天時間運行 4 個機器人實例，才找到一個解決方案.

2 號機器人

1 號機器人可以用來理解自動創建軟件代碼的最簡單算法，并研究所需的編程語言命令，但運行性能太差，不便于觀察結果. 為了在合理的時間內得到結果，我對 1 號進行了改進，得到 2 號機器人.

2 號實現了遺傳算法，大大減少了尋找解決方案的時間. 在 Intel i7 CPU 單核運行的情況下，2 號可以在 5-20 分鐘內得到結果. 它的代碼更復雜，不過我加入了不少注釋，理解起來應該不算太難.

結果

下面的圖片顯示了由 2 號產生的幾個結果，注意觀察最終生成的 C# 代碼和運行時間. 讀者可以下載源代碼并自己運行示例（參見使用代碼一節）.

輸出結果圖（點擊小圓點翻閱）

未來發展

本文展示了創建 SDB 的可能性，但現在還不能用在實踐中. 不過相關的技術如機器學習、數據挖掘、TDD、自動代碼生成等都對它有所裨益. ATDCG 的未來發展可能涉及到編譯程序和代碼分析器的構建經驗. 成熟的機器人可以創建軟件單元，避免使用高級語言和編譯階段. 它們可以創建由中間語言（CIL）或 Java 字節代碼（bytecode）組成的單元，這可以顯著加快代碼生成過程. 目前，有很多愛好者研究和開發 ATDCG. 理論研究將為理解 ATDCG 的優點以及如何在實踐中加以實施打下基礎.

代碼使用說明 返回正文

1 號碼農和 2 號碼農開發、運行環境：

• 開發 Microsoft Visual Studio Community 2015
• 編譯 Microsoft .NET Framework 4.5
• 平臺 Microsoft Windows 8.1 64-bit on Intel i7

第一個碼農

第二個碼農

兩個例子都使用了單線程，可以多開，但是 CPU 使用率會達到 100%. 在這樣的高負荷下，CPU 會嚴重發熱，長時間運行時要考慮到這一點. 2 號碼農運行起來會快很多，CPU 負荷更低.

參考資料

[Marvie,06] R. Marvie. An Introduction to Test-Driven Code Generation. EuroPython 2006.

[Raymond,03] E. S. Raymond. The Art of Unix Programming. Addison-Wesley, 2003.

歷史

• 2019-01-22 中文版
• 2018-12-15 更新了圖片
• 2016-11-22 首發

許可

文中內容全部使用 MIT 許可.

關于作者

Dmitriy Gakh，來自阿塞拜疆 ，軟件工程師、分析員、架構師、研究員、IT 應用專家、培訓師.

轉載于:https://www.cnblogs.com/conmajia/p/source-code-generated-by-bots.html

總結

以上是生活随笔為你收集整理的未来一瞥：机器人码农的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。