老實說，我覺得這個問題很難回答
- 所有的機制，要留下程式碼，不是不行，但是因為事過境遷，很容易因為技術的進步而讓這些機制原本留下的程式碼，在因為時間以及技術的變遷，導致之前所撰寫出來的東西，開始逐漸出現一些不合適的情況
- 留下來的程式碼，如果原作者，沒有適當的再重複的修改以及利用，其實對於交接的人來說，是很難去理解當初的想法是甚麼。如果再經過歲月的累積以及層層的程式碼堆疊以及繼承，很容易就失去當初的目標以及重心了
- 因為每次在實作的時候，通常都是根據當時專案所要達成的目標，而去量身訂做的一些作法，除非下一次專案可以完全一模一樣，否則通常很難達到說完全移植的情況出現。更何況，下一個實作的人可能不是你，誤差會更大。
- 如果不是非常了解所採用的 framework 本身的機制，很容易在遇到問題的時候，變成無解的狀況出現。而在之後的實作當中，你的好意就被忽略了....
其實說了這樣多，講穿了一點，就是溝通以及思考方向問題
因為其實做專案這樣幾年下來，其實專案裏面，應該要做到的事情以及目標，其實大多明確
只是，往往目標明確，卻死在實作的細節上
因為可能大家都知道要做到甚麼東西，卻不知道要怎樣才能做到那樣的效果
以至於不是評估的過於難做，就是樂觀的以為很容易就可以做到，卻發現實際上在做的人，達不到你想要的效果
或許是我有點悲觀，但現實面來說，發生的可能性往往超出自己的預料之外
或許我們把『架構』這件事情搞得太大了
因為架構應該是一個最基本的框框，去定義你該做甚麼事情、不該做甚麼事情
只要遵循這樣的處理方式，就可以達到基本的要求
而SD要做到的，就是在這樣的方向底下，根據實際狀況來量身訂作專案所應該要做到的事情
或許該做的事情還是很多，但至少不會被架構給綁死
不過，往往『架構』這件事情，搞到最後，因為程式碼的累積
以及被 ReUse 觀念理解錯誤，導致很多程式碼都會被綁到架構的程式碼裏面去
若沒有經過重整以及介面的釐清，到最後就是跟窩窩頭一樣，一層一層的感覺~~~
你說那是錯的嗎？我只能說那是時間以及環境所造成的......
而真的懂這種事情以及做的出來的人又有多少？？？
沒有留言:
張貼留言