最近學生報告了一篇有趣的論文。研究團隊開發了一個系統 CodeConjurer（程式碼魔術師），說的是可以憑空產生的程式碼。你會想，這怎麼可能？
它的原理很簡單，首先各位都知道 google 搜尋引擎可以去找全世界網頁的資料，其實還有許多是針對程式碼的搜尋引擎。例如 Merobase。研究團隊利用 Merobase 到一些 opensouce 的地方（例如 SourceForge）找程式碼，程式設計者只要寫出你想要用的物件的功能（也就是定義他的介面），CodeConjurer 就幫你找出一些可能的軟體元件，你可以進去看裡面的程式碼檢驗是否這就是你要的元件，如果是的話，可以馬上下載並整合到你的專案中。這無疑的可以幫你節省一些時間。
當然，光是透過介面的定義就認定該原始碼就是你要的可能會有些風險。為了進行 semantic check, CodeConjurer 也與 JUnit 作整合，開發者在使用這些元件前應該先透過 JUnit 確認元件的 semantics。
如果這個東西真的可行的話，第一個要擔心可能是老師們，因為抄襲的問題可能會越來越嚴重，學生可能越來越不寫程式。但從軟體工程的角度來看，這不失為是一種 code reuse 的發展趨勢。在防堵學生抄襲的同時，老師們也需要教導如何在有限的時間內套用正確、合適的元件來增加軟體開發的效率。
這是一篇有趣的文章，學生如有此本事，老師其實不必擔心，也許應該高興，我認為這是software reuse的一種，不過條件是，不能違反著作權，這一點才是要注意的地方，學生"copy"來的程式，是否適用於專案，至少他們必須看得懂這些程式，而且也必須了解專案需求是甚麼，不過"copy"來的程式如有幾十萬行，即使semantic check沒問題，要保養這些程式碼也不太容易，除非能將得來的程式碼反工程(reverse engineering)成為較高抽象層次的表示法，如model之類，我不知研究團隊有沒有在研究，例如MDA技術，要將程式碼反工程為PIM，只不過說說而已，一般說來並不可行(not feasible)，我不知其他技術是否有此本事？
就這篇文章的內容來看，作者提出的架構是在 open source 之上，所以應該不會有違反著作權。另外也著重在元件的重用，而非大程式的複製。Reverse engineering 個人認為很難的技術，主要是因為他必須要將複雜的東西拿掉，變成較為簡易的 model, 這一點如果沒有人介入實在太難。