開發一些自動編寫代碼的工具能夠增長效率嗎？

　　我所在的公司這段時間計劃着開發一套或者幾套代碼自動生成的工具，其中包括 Actionscript、JAVA web的後臺邏輯、也許還包括一些前端HTML或JS的邏輯等等。

　　我被挑選成爲 Actionscript 這一塊的負責人，哎呀真是與有榮焉，但實質上內心感受這真是要了個人命。

　　公司主營是ERP項目的開發，在個人Boss看來，咱們作的事情全都是在重複勞做，當咱們用FLEX開發一個前端模塊的時候，咱們無非就是在：開發界面；向服務器請求數據；將數據綁定到界面元素上；控制權限（其實只是將某些按鈕隱藏或者沒法交互）；添加事件監聽，編寫業務功能邏輯（包括實現前端的CURD邏輯）；將最終數據提交到服務器保存等等。咱們甚至將每個開發過程當中的技術點比喻成了「工藝」，將開發整個模塊所須要用到的技術點的合集稱之爲「工藝路線」，這樣的命名已經寫在了公司的WIKI上，成爲了咱們交流中統一律唸的名詞。

　　而我，則負責將這個「工藝路線」，編寫出一套能按照配置文檔自動生成全部「工藝」並最後編譯成能部署運行的SWF的工具。到時，咱們所謂的「軟件開發」，就只須要按照項目需求去維護那一份強大的配置文件，不寫任何代碼或者只需寫極少代碼（個人Boss認爲超過3行就是多了），就能夠產出到達交付預期的產品。這時候，咱們所須要的「開發員」門檻將極大的下降，對計算機專業知識以及學歷經驗都將沒有任何要求，他們就只是一個個流水線上面的裝配工人，通過以小時爲單位的簡單培訓立刻就能夠上崗。「這將是IT行業的一個革命」，個人boss深情的說。

　　按照我Boss的尿性，他甚至會但願我作出來的東西能適應目前還沒出現的需求，一次成型，永無後憂。以前就曾試過由於我某個模塊沒有適應到某個新遇到的需求而稱之爲「bug」，是的，他並不認爲這是程序功能上的某種提高或拓展，這只是對漏洞的修復，是亡羊補牢。

　　目前的我，既認爲這是個不可能的任務，也認爲作這個沒有多大的意義。

　　說不可能，實際上是對於未知的一種尊重。抽象，能將複雜的事物變得簡單，但過分抽象的最終結果，則是虛無。畫畫有什麼難的？無非就是沾上顏色在畫布上塗塗抹抹；音樂有什麼難的？無非是各類音符的排列組合。咱們確實能夠將某些業務、某些功能抽象成簡短的幾句話，但並不意味着咱們真能將這些話語轉變成代碼實現。程序的抽象是有極限的，不論是面向對象，仍是面向切面，都試圖釐清程序開發的邊界，咱們不該該（實際上也沒法）開發萬能的類或者模塊。同時，囿於人類頭腦的侷限性，即使是同一個功能下，咱們也終將不能把全部方面都考慮周全。

　　說無心義，則是從代碼的角度來講的。在軟件設計中，有一個DRY原則，do not repeat yourself，不要重複你本身。講的就是相同邏輯的代碼不該該不斷重複出如今你的代碼裏，它應該被重構。但自動生成代碼的工具將反其道而行之，無他，工具生成出來的代碼必然是每次都一致的，它自己並不具備創造性，甚至連錯誤也都一併複製。在這樣的狀況下，不斷重複的代碼將散落在系統的各處，除了對性能的極大影響以外，對於系統的健壯性也是嚴重的考驗。

　　實際上，這款工具的編寫過程，就是不斷將本來寫在代碼裏面的各類條件判斷語句或者方法參數，放到了配置文件當中，也是將某部分的邏輯，在配置文件中編寫。最終的配置文件的編寫過程，也就是換了語法的代碼編寫的過程，這個所謂的生成工具就是將配置文件翻譯成Actionscript語言的工具，這個過程，甚至能夠創造出一門語言（爲了達到已知與未知功能的覆蓋，是否是甚至須要圖靈完備呢？）。這就是我認爲無心義的所在。

　　其實我也並非真是以爲開發一些粗略提供部分代碼的工具一點用處沒有，主要是如今要求真是過高了。。。

　　那麼，提升編程效率的真正途徑是什麼？

　　我認爲是用軟件工程的思想去開發、維護咱們的代碼。計算機誕生已經好多年了，在這門學科上，咱們已經有不少前人的經驗能夠借鑑，不論是oop、aop、函數式編程、軟件設計模式等等各類經驗總結都是爲了提升效率，爲何不去使用它呢？

　　咱們是一家技術公司，可是我以爲它太不尊重技術了。

　　是的，如今不少程序員在網上會自稱「碼農」、或者「程序猿」來自嘲，但我歷來沒想過，在本身的公司裏，程序員的定位居然跟傳統勞動密集型工業裏的工人定位如此接近。