R06 支援專案所見(3)──流程與動作的綑綁

專案裡看到的程式幾乎都是這種類型居多，在撰寫局部功能的時候在一個方法裡放置了所有要做的動作；當然包括了分析上的行為與細微的API全集中在一起。這是程式寫作時直覺的思考方式，把功能要做的事依其順序寫下來。

這樣設計對於實作一個功能是正確的，反正到最後跑出來的過程與結果是正確的，但是對於變動來說卻是很困難的。首先得先定位出分析意義上的動作步驟範圍，思考上的一個步驟可能由多行程式碼所達成，而那些程式碼是緊密而不可分的；其次，順序變動時還要去思考其他同樣呼叫此方法的功能，是否會因此而造成錯誤的狀況；再者，在其它方法裡若發現同樣目的的程式碼時，是否要抽取出來也難抉擇，因為是否抽得乾淨與是否涵蓋所有使用的功能都不易確認。

進一步的設計是把依序寫下的動作分門別類地佈置與封裝以形成方便重用的元件，可惜的是現在經手的程式有很多從底層就已經開始混淆，這在專案上想覆寫時也會遇到明明只要改一點小地方，卻非得整個方法內容剪貼出來修改而完全棄置原來的程式。長久下來就造成專案產出程式裡的盤根錯節與過多的重覆程式碼，無論是誰都難以再度釐清。

直覺的設計寫法在極小型的專案裡還可以應付，因為需要記憶的部分不多；但是在中大型的專案裡思考內容很多而且由多人開發，那光憑少數人的記憶是完全無法應付管理與追溯的要求的。