我可以理解一個人出外，在異地機場的那種心情

一張小抄，一個阿嬤的勇敢故事



在電視上面看到這個廣告，老實說，我相當能理解這個阿嬤在機場的心情
真的有一個人，到了異地的機場
語言又不通的情況下，真的心情是很忐忑不安的

不管這個故事，是否被人家理解為女兒不孝還是怎樣
但我相信，每個人有每個人的難處，如果不是當事人，是沒有資格批評人家的

所以，我對這篇廣告阿嬤的處境
我相當可以理解，因為我也遇過類似的情況
不過還好我還可以用一點彆腳的英文
只是，在機場的十分鐘，真的可以說是相當於一個鐘頭.....
真的，勇氣是一個很重要的事情.....

希望這個阿嬤未來一切平安順利！！！

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

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

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

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

其實說了這樣多，講穿了一點，就是溝通以及思考方向問題

因為其實做專案這樣幾年下來，其實專案裏面，應該要做到的事情以及目標，其實大多明確

只是，往往目標明確，卻死在實作的細節上

因為可能大家都知道要做到甚麼東西，卻不知道要怎樣才能做到那樣的效果

以至於不是評估的過於難做，就是樂觀的以為很容易就可以做到，卻發現實際上在做的人，達不到你想要的效果

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

或許我們把『架構』這件事情搞得太大了

因為架構應該是一個最基本的框框，去定義你該做甚麼事情、不該做甚麼事情

只要遵循這樣的處理方式，就可以達到基本的要求

而SD要做到的，就是在這樣的方向底下，根據實際狀況來量身訂作專案所應該要做到的事情

或許該做的事情還是很多，但至少不會被架構給綁死

不過，往往『架構』這件事情，搞到最後，因為程式碼的累積

以及被 ReUse 觀念理解錯誤，導致很多程式碼都會被綁到架構的程式碼裏面去

若沒有經過重整以及介面的釐清，到最後就是跟窩窩頭一樣，一層一層的感覺~~~

你說那是錯的嗎？我只能說那是時間以及環境所造成的......

而真的懂這種事情以及做的出來的人又有多少？？？

spring mvc 處理 form:input 無法顯示正常的日期格式

http://forum.springsource.org/showthread.php?t=78113

先紀錄，待續