有關軟件架構設計 的思考

 最近在重構設計。這一回自己吸取了之前的教訓，在想清楚整個設計的架構之前，一直沒有動手寫太多實

際的code，更多的時候是用僞碼來描述驗證自己的設計思想。

花了三天的時間，在一條設計道路上不斷地思考，嘗試，最終發現並不太可行，於是改換另一個思路繼

續進行設計，經過一天時間的設計，發現這個思路也存在一定的缺陷，及至今天，纔算是基本確定下來整

體設計的框架。

如果自己這一次還是在設計階段淺嘗之後就開始實際動手coding，恐怕就未必能夠及時地意識到設計中

存在的不足了。很多時候，雖然在實際編碼的過程中我們能夠體會到設計中存在一些缺陷，但是身陷於

細節實現其中，大腦往往被“快點搞定它”的想法所充斥，已經無暇再回到比較高的角度來思考整

個架構的合理性了，這種情況下，往往要待到編碼到一個原有的設計缺陷已經無法忍受的狀態下，才

會明確清晰地意識到有必要重新考慮設計層面的變化了。

但是到了這種時候，也往往意味着前面大量的實現工作要被推翻重來，不啻爲一種浪費。

而在設計階段，作得細緻一些，儘量不要讓自己陷入實現的細節中糾纏，即使在僅憑思考和抽象已經不易

把握系統複雜度的時候，也不要輕易訴諸實現，而是藉助於流程圖，僞碼這樣的抽象層次較高的手段來協

助自己建立起對系統的具體理解，則有助於以一種有序的方式把握整體的設計了。

設計工作往往是抽象的，不易把握的，甚至是有些痛苦的，因爲你往往要從一個空白的起點開始通過抽

象，組合，等等手段構建出一個假想的符合要求的目標架構，這種不夠厚實，欠乏實物支撐的感覺經常會

讓一個設計經驗不是很豐富的開發人員在設計階段萌生出逃避設計，儘早切入具體coding的想法。

而相比之下，實現工作則具體得多，也易把握得多，也更容易帶來快速成就感，所以開發人員可能更容

易傾心於一個具體模塊的實現。 這也是誘使我在前面的開發過程中在設計還未足夠明晰的情況下就過早

介入具體實現的主要原因。