這篇是我在 2023/09/07 聊到關於 Code Generator (底下簡稱 codegen or CodeGen) 的經驗與想法。

Codegen 經驗談

2008: codegen banking system design patterns

我大約 2008 一個案子開始接觸 codegen，從一開始我就很喜歡這個模式，因為生產力很高。可以透過這樣的方法快速產生 project template (Java Project using EJB for eclipse project)、design pattern for best practice，然後執行各項 Unit Test. 下圖則是當時用 CodeGen 產生後，執行 UT 的紀錄：

2010: codegen for automation test

Designing Test Architecture and Framework 一文分享了過去設計 Automation Test Framework 的紀錄，主要都在討論框架怎麼設計，以及流程面。不過其中沒提到的就是如何寫 Test Case，這個過程也是用 Codegen 產生標準的 Test Case 框架，讓 QA / Tester 依照標準框架開發，包含 Config / Data / Log 等。

2012: codegen improves ORM productivity

類似的概念，也用在我自己曾經開發過的 ORM (背後設計想法有點像 MyBatis)。那個時候大部分主流的 ORM (MyBatis / Hibernate) 還是要寫一些基本的東西，像是 repostory、VO、entity … etc。

但我實在很懶得再寫這堆重複性很高的東西，所以整個設計就是直接把傳統 ORM 要做的雜事，用 CodeGen 直接產生。實作概念是直接掃描整個 database，用 codegen 直接產生出整個 ORM 的 skeleton，也就是 用 java 產生出 java，整個生產力非常高。下圖則是用這個 ORM 開發的 app … 主要是用來管理一堆 Server Rack 的管理介面。

這個做法讓我很專注在設計 Database Schema 以及處理 Service Layer 的商業邏輯，省去很多時間處理 ORM 中間的重複性很高的任務。

API First

除了上述的應用場景，另一個 CodeGen 用很多的地方是導入 API First 的過程。

OpenAPI 的規格 swagger.yaml 可以透過設計優先 (Design First) 的概念，先完成規格的設計，透過 CodeGen 產生出對應程式語言的 RESTful skeleton，這個 skeleton 會依據 Spec 描述的 Data Model 產生對應的程式碼，同時也完成一些基本的處理，像是 Data Validation、Response 等，而開發者只要專注在商業邏輯的處理即可。

API First 背後的精神都在於 Spec 是否完善，後面才會跟著完善。

Objective and Key Result

做每一件事情，背後都有其動機，CodeGen 最重要的目的 (Objective) 是：

提高開發 生產力 (Productivity) 與 品質 (Quality)

這個目的背後更具體的就是標準化開發過程所共同 (Common) 的東西，像是 Log / Config / Security / Coding Style … 等 標準化，而這些標準化的工作其實就是 Internal Developer Platform (IDP) 的基本工作之一。

更多關於 IDP 參閱個人著作：個人著作《SRE 實踐與開發平台指南》

導入的問題

codegen 概念對我個人來講，算是很熟捻的東西，包含怎麼活用、怎麼提升產能、或者降低開發過程的一致性問題 ..

不過在工作中導入，也遇過一些問題，像是:

• 被嗆說這種東西是一次性的，沒啥屁用
• 這種東西大多都失敗，不要浪費時間

這兩個問題的源頭都不在技術本身，在於用的人懂不懂軟體工程 …

所有的 IDE 在 create project 的原理就是 codegen，所有 open source 網站上文件的 reference part，都是 codegen，一些 SDK for multiple languages 也都是 codegen，然後 MVC 的 View 本質上就是 codegen …

軟體工程 的價值 在於:

1. reusable (可重複使用，提高開發生產力、品質)
2. scalable (可拓展業務)

codegen is 1) for most of cases, for advanced case, such as #IDP, is 2)

一些想法

判斷一家公司是否是上軌道的軟體公司，不是用規模或人數來判斷，反而是可以從以下過程的速度當指標：

idea -> poc -> MVP

這個過程的速度有多快，就是軟體開發成熟度的指標。

而且 MVP 出來的東西要符合公司既定開發政策，像是 metadata、logging、config、security、coding conversion … 等老生常談的 guideline 或者 discipline (紀律) ，而這些都是 codegen 可以直接秒殺的東西，只要有持續迭代。

如果每個團隊都還要重新理解、自己寫、或者問要遵守哪一套，那有兩個問題是要留意的：

1. 管理與治理 - 管理團隊的管理能力
2. 軟體工程的能力 - 專業團隊的專業能力與專業素養

如果要做 Platform Engineering, or Internal Developer Platform (IDP)，Codegen 是直接呈現產能最直接的方式，否則一堆規範 / 制度 / 紀律 …. 都只是紙上談兵的東西。

AI

AI 已經是趨勢，而可以 CodeGen 代表背後要被 AI 直接產生就更簡單了，也代表 AI 其實可以直接透過其他動態的方式，完成 CodeGen 的任務。

延伸閱讀

• Designing Configuration Loading Strategies
• Designing Test Architecture and Framework
• 個人著作《SRE 實踐與開發平台指南》