S25 理想元件結構的自動化產出

我最終的理想是將所有產出的程式碼視為一種Model，用方法論約束以形成為固定類型的結構，再撰寫（或找到適合的）應用工具導出到各種方向的結果。這裡記錄的是自己現在認為“應該且可以”具有與可以實現的同步轉出功能。

分析的最小單位應該是Method。每個Method在以規定的方法撰寫並註記合格的註解時，就可以將所有Method視為能用同樣方式存取的Model，依其特性與原則必定可以設計出工具程式自動取得以下的資訊：

◎所有的傳入參數
◎所有的傳回可能值
◎所有的使用資料、參數（常數）與例外
◎所有的方法呼叫（包括同一個Class與其他的）
◎所有使用常數與呼叫方法所屬的Class（使用關聯）
◎使用XML定義流程處理、依設定檔deploy出攤平的程式碼（執行速度變慢才會做）
◎程式的完整流程（搭配輸出工具可以產出流程圖）
◎所有判斷指令內依賴的條件清單（每個條件都附上所有可能的傳回值）
◎所有的變更歷史清單（包含日期）與改變的程式
◎Commit時產生所有需要填寫的變更註解

Method是最基本的單位，往上推展依序是Class、Component Package、Package……到最後就會達到Use Case Package。從最底層精確地產出每一個單位的完整記錄，往上產出時就能拿到百分之百正確的資訊，到最後產生一個關聯與影響的龐大結構，我們可以選取任一個方法作為起點，就可以拿到自己使用到哪些方法（與所屬Class）與哪些方法使用自己完整追溯結果。其實還不只如此，我們甚至可以在任何一個指定層次取得之下的所有資訊匯整出文件。

一直以來額外花時間製作程式文件與修改後同步文件的工作都是程式開發者頭痛的問題，多花一倍時間把原來設計程式時的想法再寫一次，文件或程式修改後還得要同步另一份的資訊。文件與程式相互依賴的關係是如此之多，只要有任何一個沒有更新為對的資訊就會造成兩者各做各的，完全失去原有的意義。

“完整規定程式設計產出的結構、要求在該寫註解的地方填上必要資料“，這是我想做出來的程式設計方法論！