U27 繞一大圈後再返回原點的收獲

之前看自己寫的或是別人寫的程式碼時，總感覺有一大堆不同意義的程式混雜在一起，但是又無法說清楚那些是什麼。隨著經驗的增長且接觸較多的理論後，才能夠明確地指出程式的佈置應有六種意義，同時在2007/10開始在合作的專案裡嘗試實作。然而又在2009/04發現最重要的Flow與Action實際上是可以放在一起的，只需要運用額外的註解。

為了印證自己的想法，最近特地去查看重構的方法（為了Class、Method的佈置）與敏捷開發的原則（為了快速的開發），並在心裡作了一些比較。

重構部分，我比較在意的是靜態佈置與資料、動作定位的問題。儘可能最大化的可能佈置Class結構可以避免Extract（Interface、Subclass、Superclass）；設計方法時依照所處層級的動作意義對應放置可以不用Move、Extract（Method、Field）；同時能夠減少Pull Up、Pull Down（Method、Field）有時必須連帶Extract Class的影響。另外貫徹絕對重用的想法就能根絕Duplicated Code與Shortgun Surgery。

至於敏捷開發，同步開發團隊思維與換人接手程式的原則，在定義固定的元件結構下甚至不需要pair programming就能夠直接換另一個成員；註解與文件是為了讓別人更瞭解自己的程式的原則，應用註解來產生全部Flow與Action的流程圖可以滿足；快速地不斷產生成果的原則，在軟體元件化後就能夠快速組裝流程甚至運用SA Tool來作勾選與拖拉式的開發；設計是為了駕馭客戶需求的改變，可以用任意tier、layer的切割、快速的Flow調整與更換不同的軟體元件來滿足。

敏捷開發加上重構，看起來是用敏捷的寫作方式做出可執行的成果，再重構程式碼調整Class、Method與Data的佈置作最佳化。既然如此，為什麼不用敏捷開發直接作出重構後應該有的佈置呢？目前看過的方法論裡文件都與程式脫節必須另外製作，融合各家所長以理想的程式結構為根本，直接使用程式來設計，再應用註解自動化產生絕大部分的設計文件，是不是可以節省製作文件的時間同時又保證其正確性？

目前只是一個連理論都不甚清楚的程式寫作員，但是相較於其他工程領域都有固定的模組化方式來堆砌出客戶想要的成果，軟體工程卻獨缺能夠被大部分人同意的決定性作法。不知道未來的程式設計是否有機會往我現在努力的方向演進？