星期四, 2月 11, 2010

到底甚麼是架構?甚麼又是SD該做的事情?

今天跟同事討論到這個問題,是因為他問了我一個問題:『可不可以把現在我在專案中做的機制,列出來,當作後續專案的遵循依據』

老實說,我覺得這個問題很難回答

  1. 所有的機制,要留下程式碼,不是不行,但是因為事過境遷,很容易因為技術的進步而讓這些機制原本留下的程式碼,在因為時間以及技術的變遷,導致之前所撰寫出來的東西,開始逐漸出現一些不合適的情況
  2. 留下來的程式碼,如果原作者,沒有適當的再重複的修改以及利用,其實對於交接的人來說,是很難去理解當初的想法是甚麼。如果再經過歲月的累積以及層層的程式碼堆疊以及繼承,很容易就失去當初的目標以及重心了
  3. 因為每次在實作的時候,通常都是根據當時專案所要達成的目標,而去量身訂做的一些作法,除非下一次專案可以完全一模一樣,否則通常很難達到說完全移植的情況出現。更何況,下一個實作的人可能不是你,誤差會更大。
  4. 如果不是非常了解所採用的 framework 本身的機制,很容易在遇到問題的時候,變成無解的狀況出現。而在之後的實作當中,你的好意就被忽略了....
其實說了這樣多,講穿了一點,就是溝通以及思考方向問題
因為其實做專案這樣幾年下來,其實專案裏面,應該要做到的事情以及目標,其實大多明確
只是,往往目標明確,卻死在實作的細節上
因為可能大家都知道要做到甚麼東西,卻不知道要怎樣才能做到那樣的效果
以至於不是評估的過於難做,就是樂觀的以為很容易就可以做到,卻發現實際上在做的人,達不到你想要的效果

或許是我有點悲觀,但現實面來說,發生的可能性往往超出自己的預料之外

或許我們把『架構』這件事情搞得太大了
因為架構應該是一個最基本的框框,去定義你該做甚麼事情、不該做甚麼事情
只要遵循這樣的處理方式,就可以達到基本的要求

而SD要做到的,就是在這樣的方向底下,根據實際狀況來量身訂作專案所應該要做到的事情
或許該做的事情還是很多,但至少不會被架構給綁死

不過,往往『架構』這件事情,搞到最後,因為程式碼的累積
以及被 ReUse 觀念理解錯誤,導致很多程式碼都會被綁到架構的程式碼裏面去
若沒有經過重整以及介面的釐清,到最後就是跟窩窩頭一樣,一層一層的感覺~~~

你說那是錯的嗎?我只能說那是時間以及環境所造成的......
而真的懂這種事情以及做的出來的人又有多少???

沒有留言:

張貼留言

Powered By Blogger