輔助開發的利器：程式碼產生器

對於程式設計者而言，「程式碼產生器（Code Generator）」就算沒有真的使用過，也多半在心裡有過類似的構想。

程式設計者的主要工作之一就是產出程式碼，而且也花去了許多的時間及心力，倘若可以透過一個自動化的工具，快速產出程式碼，而不再需要透過人工的方式逐行地寫下程式碼，那麼開發程式的速度一定可以大幅提升，甚至進一步還可以得到更好的程式碼品質。

程式碼自動產生，增進軟體開發效益

而所謂的「程式碼產生器」即是自動化產生程式原始碼的工具，它本身也是一套軟體，只不過它的作用是在產生其他軟體的原始碼，讓軟體開發人員得以直接利用這套原始碼來產生軟體，或是以這套原始碼為基礎，繼續衍生開發。因為透過程式碼產生器，可以自動化產生出全部或部份的程式碼，省去了開發人員手工逐一寫下原始碼的時間，也因為這些被產生出來的程式碼，通常已經經過了長期的測試，所以也有一定品質，因此，不僅可以節省撰寫程式碼的時間，也能減少測試、修改的時間。這也正是不少開發人員期待程式碼產生器所帶來的效益。

以我自身的經驗來看，的確有一段時間，有好些人想往這個方向發展，甚至也推出了一些程式碼產生器，不過時至今日，程式碼產生器並未成為一種開發軟體的主力方式，倘若真能節省時間、又能確保品質，為什麼沒有在眾多的程式開發者的開發生活中成為要角呢？

程式碼產生器，其實概念上也像是一種將高階語言轉換成為低階語言的工具。它的輸出通常是我們已經熟悉的高階語言，例如C/C++、Java、…… 等等，它的輸入卻是更接近人類的習慣、更簡便的描述方式。

程式碼產生器的發展歷程

在「所見即所得（What You See Is What You Get，WYSIWYG）」的概念開始大行其道時，人們也想將這種方式套用在程式產生器上，我相信不少人心裡都想著：「如果可以透過在GUI上面拖拉元件的方式完成設定，就可以產生軟體的程式碼，那該有多好？」

在GUI上拖拉元件的操作，本質上就是讓開發人員、甚至是不懂程式開發的領域專家，來描述他們想要的軟體究竟該具備何種特質的方式。所以它是一種圖形化的描述方式，也可以被視為是一種更高階的語言，透過它，我們期待人類可以用更容易理解、更高階、更簡便的方式，來描述自己想要的軟體的特性。

而程式碼產生器的工作，就是將這個更高階的描述方式轉換成為現成的高階語言，之後便可憑藉著現成的編譯器工具，來產生出最後的軟體了。

在普羅程式設計圈子裡的這個風潮，大約是從圖形化使用者開發介面的工具開始流行起來的。像早期 Borland 的 Delphi 、微軟的 Visual Basic 等等，都可以透過「所見即所得」、在介面描述上透過視覺化元件的拖拉、以及個別元件屬性的設定、…… 等等方式，明顯降低了使用者開發視窗應用程式的困擾，也減少了許多時間，所以，整個學習曲線都大幅降低。

記得最早開發 Windows 上的視窗應用軟體，沒有任何的應用程式框架、也有沒有所見即所得的整合開發環境，只能憑藉著最原始的Windows SDK，手工刻下每一行的原始碼，不僅很花費時間，還容易出錯，更重要的是，不容易上手，得花很多時間才有辦法學會撰寫的方式。但是自從這些輔助使用者介面開發的所見即所得工具問世以來，開發人員充份享受到這種工具所產生出來的好處。這些工具背後有一套應用程式框架，同時也包括了程式碼產生器，因而可以將開發人員在圖形化介面上所做的設定儲存下來，並且轉換成為基於該應用程式框架的程式碼。

這是程式碼產生器輔助圖形化介面程式開發的例子。在那之後，我也看到了有些工具是針對開發資料庫應用程式而來的。

有些典型的資料庫應用程式型態很固定，例如，以操作資料庫表格為中心的方式來思考應用程式。像是單一表格的新增修改查詢和刪除（即所謂的CRUD），或是一對多、多對多等等的型態。表格可能有主鍵、主鍵的產生規則也是固定的，欄位或許有檢核規則，像是必須是日期或、金額、或數字、……等等。而應用程式的使用者在操作使用者介面時的模式，也都很固定。由於控制、存取資料庫的模式固定、使用者介面的模式也固定，因此，十分的適合使用程式碼產生器來產生。

我們以前在開發 ERP 系統時，就曾經開發過類似的工具，來輔助我們產生此類的程式碼。透過簡單的 XML 設定、搭配自己開發的應用程式框架，工具所產生出來的程式碼就可以處理好操作資料庫及應用程式介面的部份。對於以資料庫操作為中心，又是 CRUD 式的應用程式開發來說，的確可以省去不少時間。

還記得在 JavaBean 還算流行的年代的，最早也是動了腦筋讓 JavaBean 和資料庫中的資料做關聯及對應，使得應用程式端僅面對 JavaBean 的這種物件型態，毋需理會後端資料庫操作時的種種細節。但是大家都知道 JavaBean 有些規範，像是 setter 及 getter，想要對應到資料庫中的資料，逐一的寫下這些 setter 及 getter 可能是相當累人的一件事。於是，我們也做了一個程式碼產生器，它可以讓開發人員指定要對應的資料庫表格，接著工具便會自動化取得表格相關的 metadata ，並且據以產生出 JavaBean 的原始碼。

透過這樣的工具，就可以節省原先要花費用來撰寫 setter 及 getter 的時間，而偏偏那就是最沒有意義的一件事，因為幾乎都是不需要太多腦力、而接近勞力性的工作。

這正是程式碼產生器最能夠派上用場的地方，它能把應用程式中可以歸納成固定規則的部份，自動產生出來，而這些部份，也正是大多程式設計人員覺得最無趣的部份。有了程式碼產生器，不僅節省時間、力氣、也減少犯錯的機會，同時也可以讓程式設計者可以專注在應用程式中獨特、有趣的部份，而不需要將大多數光陰都浪費在這些其實可以讓電腦代勞的地方。

程式碼產生器的局限

但是，即使程式碼產生器具備這樣的好處，卻也無法全面取代人類，正是因為可以歸納成固定規則的部份不見得比例很高，而且，通常隨著領域的不同而有所不同。

有些人在發展特定領域的高階描述語言，透過更高階的描述方式來描述特定應用領域裡規則，這會有助於程式產生工具來產生軟體。但是，不同領域中適合的描述方式多半會不盡相同，這使得不容易有一套放諸四海皆準的描述方式。

即使有了工具輔助處理掉冗餘、勞力密集的部份，但是在現階段，軟體系統中還是有很多組成，是需要人類的思維介入才能妥善完成。

因此，程式碼產生器無法讓優秀的程式設計者失業，它充其量只會淘汰掉那些只能開發冗餘、勞力密集程式碼的程式設計者，卻能讓優秀的程式設計者更專注在應該要專注的地方。