記錄乙個想法，不是今天才想。
這只是我的自動化程式設計，如果有讀者不小心看到這篇文章，請不要把它想得很高大上。
因為我已經實現了在thinkphp3.1.2下半自動生成標準的curd**，可以給檢視帶上既定樣式，給控制器方法帶上相應的rbac許可權驗證，自動生成rbac節點的sql，最後將生成的**自動儲存為相關程式檔案。
我對此並不滿意，雖然我對它進行了幾次優化和改進，它從一開始就被我設計的有5個**編輯框可以在乙個web頁面上不用切換檔案就能立即修改指定**塊，現在還能夠將儲存過的**專案再次在這個編輯器中開啟（是的我把它當作乙個編輯器了），為它甚至還考慮了一些安全因素和操作體驗以便我的同事也能夠使用。
在開發一些功能模組的時候，它已經被我自己用過好幾次了，我相信它的準確性和穩定性，也知道他的缺點因為他是我調教出來的學生，至於我的同事們用過多少次，我沒有問過，不過我知道他們用過。
然而它只是基於我們公司內部常用框架的乙個輔助工具，它不能夠被外部使用，只能在我與同事之間的小環境內，為了在特定任務下提高效率才使用一下。雖然它自動生成的**有時不需要通過修改可以直接上線，但因為業務的邏輯往往需要將他生成的**進行一些修改才能達到目的，而它生成的**是基於我預先設定的**模板，是不包含任何業務邏輯的。當然了正是基於它自動的生成了標準的curd**，才使得我可以專注於新增和修改少量的業務**即可完成目標。
我還是要重複一遍我對它並不滿意。
不是不算滿意，是不滿意。
雖然我的同事對於這個東西表現了一丁點興趣，以及友好或客套性的向我表達了些許稱讚，並同意了這個東西可以一定程度的提高效率的觀點。
也許是因為它是我的第乙個學生，它誕生於乙個初級的需求，雖然它誕生之時我對他的未來也有很高的期望，但現在將他回爐改造不合時宜，而我的腦子裡已經孕育了乙個未來會比它更好的第二個學生。
它們是連形狀都不具備的物品，它們不會對我有感情，只有我在為它們付出，那麼我必然為更有前途的那個想法付出更多，並立停止向老版本的想法繼續付出，我現在停止為老版本付出不會帶來任何後果。
對，就是版本的概念。我的第二個學生將是乙個全新的版本，它將基於乙個全新的架構和最新的理念，因為它的師兄，我的第乙個學生，讓我明確了在一定場景下的全自動程式設計的想法完全可行，基於它（我的第二個學生）的可行，我可能未來還會去調教第三個、第四個或者第五個學生，去實現全自動的程式設計，以及自動程式設計場景的自定義化，**模板的自定義化，當自定義的場景足夠多，最終將實現「不同場景下的全自動程式設計」。
我的第二個學生，我可能不會急於將自定義場景自動程式設計的重任交給它，因為我抓住了自動程式設計的重點：需求與資料結構。
需求是軟體價值的表達，資料結構是結合軟體需求與軟體構架後所產生的軟體的「形狀」。
根據軟體需求自動形成架構方案和資料結構並不是我現在的目標，它是自動程式設計的高階階段，不過我相信我最終將實現它。
我認為自動程式設計的最終階段是根據完整的需求（當需求不完整時協助你完善你的需求）自動建立方案，並為選用的方案自動編寫**，自動編譯或部署，當然還是以場景為概念，當你需要在哪種場景下讓它自動程式設計，那麼你需要為它去建立它應對這個場景時的需求分析、方案構建、元件選用、**編寫等各種處理過程，只需要建立一次便可讓它永遠學會這種場景下的自動程式設計，你還可以為你構建的這個場景進行公升級，那麼它也隨著你對這個場景的公升級而提高應對這個場景自動程式設計時的「段位」。
這個最終階段是我的目標，然而我知道一定要以乙個開放的態度才能實現這個偉大構想，我說這是個偉大的構想你贊成嗎？
可能有人會想象，會不會有一天，軟體的需求都不需要人類去定義，直接由人工智慧來根據已知或挖掘的社會問題來自動生成需求並最終生成程式？
我相信未來可能會有人提出類似的概念並作出嘗試，但是，我也不知道怎麼描述，只能說人類科技的快速發展並不意味著未來人類的大腦只需要有乙個桌球那麼大就夠了，人類在解決了自身社會問題後接下來所要面對的可能是更艱難的任務。如果人類為了免去一些思考而讓機器產生了自主思維，這是乙個很未來，很科幻的概念，而在現在的概念裡，我只認為：程式幫助人類完善需求並最終將需求所需要的程式功能自動實現，已經是自動程式設計的終極階段。
下面是對我第二個學生的調教的打算：
mysql 表注釋最大長度為2048字元數，字段注釋最大長度為1024字元數
實現乙個網頁建模工具，在其中可以建立資料庫、資料表、欄位及索引
在這個建模工具中對錶與字段的注釋進行擴充套件管理，如下：
1、利用資料表的注釋儲存json形式配置該錶的功能性資訊（控制器、功能名稱、模型、檢視列表）
2、利用字段注釋儲存json形式字段功能性配置（字段中文名、顯示順序、是否必填、驗證規則、dom型別、聯表或資料序列）
以上注釋內容，可以特定邊界作為協議，由擴充套件程式進行設定和獲取。
它的好處在於每個表和字段的配置資訊在其自有注釋裡面然，可以隨著資料表結構的匯出而帶走，而這樣的方式需要為mysql允許的注釋長度能否滿足所有場景的配置內容而擔憂。
不過，如果我們把配置資訊會隨著資料表結構的匯出而帶走視為安全性問題，那麼，應該選用以下方案：
建立專用表：zhwj_autodb_，直接將以上配置類資訊儲存到表中，該錶的字段結構可以更加的多樣性，不用擔心長度不夠，使用擴充套件外掛程式對該錶進行處理更加清晰。
無論哪種方案（當然我已經選定了後者），配置的資訊將用來為程式的自動化程式設計提供指示，比如每個表所對應的功能模組名稱、每個欄位所對應的中文名稱、欄位的資料序列或外來鍵資訊等等。當基於這個資料庫建模工具完整的建立了資料庫之後，便可以讓程式掃瞄遍歷並根據每個表的配置資訊執行自動程式設計，那麼乙個專案（web管理後台）中的標準curd**就全部完成了，程式設計師只需要將寶貴的時間專注在業務處理上。
雖然我真正動手去實現自動程式設計之初只是為了解決標準curd，以現有的條件也只能解決標準curd，但我對它的寄望遠不止於止，正如以上所說，它最終可能讓很多人感到驚訝，甚至驚慌。
記錄乙個想法，不是今天才想
我的自動化測試框架
參考 自動化測試框架基於page object模式，unittest框架設計，目錄結構如下 test project config 存放配置檔案 data 存放頁面元素 drivers 存放瀏覽器驅動目錄 log 存放日誌目錄 report 存放執行報告目錄，使用htmltestrunner tes...
我的自動化測試之路
因為我一直在分享自動化測試技術，所以，時常被問到 功能測試想 動化，請問應該怎麼入手？或者有哪些書推薦？那麼，接下來我就結合我的經歷聊一聊我是如何在工作中做自動化測試的。我的軟體測試職業開始和大多數最普通的測試人員一樣，一開始在一家幼兒教育平台的公司做軟體測試，公司最開始只我人一位軟體測試人員，沒有...
我的自動化測試理解
前國內，一提到自動化測試，就是指用工具進行測試。我認為這認識很片面。再好的 只有在選進的作戰思想 作戰體系指揮下，才能發揮其 效能。好比，現代戰爭，不是有幾架先進戰爭機，就能打贏的，而是兩個作戰系統的對抗，再具體體點，是海陸空及作戰平台的四位一體的全面對抗。從測試工具的角度來說，某個工具的單純使用，...