軟體設計思維應跳脫思考的桎梏

上上星期透過朋友介紹,至某知名教育訓練機構,討論軟體設計課程的合作方案。

在與一位老師閒聊閒聊當中,,談及他正在某資工所上課,他們老師正教授軟體開發製程,介紹到 “XP(Extreme Programming)” 的方法論。

一聽到 “XP”,我馬上精神抖擻起來~ 半年前我把 XP 的譯作約五本全在廁所看完,對於 XP 的哲理及其實務作法,非常地激賞。

哪位老師對 “XP” 的實務作法,一直很懷疑有可能可以在台灣的業界實施嗎?例如,他認為 “pair-programming”、”客戶駐點”,根本是脫離現實的。

聽到這...我的感觸很深,哪位老師直覺是認為 XP 的實務不容易也不一定適用在國內的軟體業界。
但,我認為 Kent Beck(XP 教祖) 的本意不是要你去模仿及學習那 “十二項” 的實務吧?
XP 的 “十二項實務” 只是 “How-to”,”How-to” 會因為現實的環境而修正的。況且,為什麼我們不懂得再找出第 13、14 ...的實務呢?哪應該才是 Kent Beck 的本意吧?

“XP” 是因為 Kent Beck 看到軟體開發流程中,有太多 “昧於現實面” 的現象,尤其是 “人” 的因素往往是影響整個專案成敗的主因。

Kent Beck 從 “本質” 去思考,發現到 “簡單”、”溝通”、”回饋”、”勇氣” 這四項要素是軟體專案開發的核心,從這四項基本元素,才去找出 “十二項實務” 的 “How-To” 來解決現實面專案開發的問題。

我想表示什麼呢?軟體設計人員不能只看到 “XP” 所提供的 “How-To”,就去模仿使用,然後應用在實務不成功時,就怪東怪西的、或心情沮喪、或覺得根本無法與現實結合...

能不能跳脫那所謂的 “十二項實務” 呢?那重不重要?當然重要!
但,更重要的是,是否你能真正用心去思考那四項基本要素呢?

什麼是簡單?為何要簡單?為何簡單是力量? —> 如何達成簡單呢?
為什麼溝通是重要的? —> 如何達成順暢、和諧地溝通?
什麼是回饋?為何回饋可以降低風險? —> 如何達成快速回饋呢?
為什麼要有勇氣? —> 如何提升自我及團隊的自信心呢?

What?-> Why?-> How-to
軟體設計人員可不能再只把焦點擺在 “How-to” 而已,哪未,整個思考就僅會落在 “How-to” 的框架桎梏之內~
跳出 “How-to”,勇於思考本質、勇於創新、勇於找出自己的 “How-to”、勇於嘗試、勇於被批判、勇於修正...

如此,軟體設計者才會有無限地想像與創新,並可以有屬於自己的 “XP” 了!!

解讀『XP軟體製程』的字面意涵

XP 的全名:Extreme Programming。
中譯本其中有三本翻譯為”極致軟體製程”;一本翻譯為”極端軟體製程”。

哪一個比較符合 XP 的原意?
個人到認為,這兩個解釋都很合理!

翻譯為 “極致“,代表如何把軟體製程做到 “最善”;
翻譯為 “極端“,則表示基於現實面的考量,可能會顛覆傳統的軟體製程觀念,如 “Pair Programming”、”客戶駐廠”...等,是一般傳統的軟體開發人員所無法想像的!

[CVS]版本控管的基本規範

內部團隊軟體專案協同開發基本規則:

一、開發期間所釋放(release)的版本一律為 1.0 以內。亦即,如 CEDT_WK_0.9 版。

二、在開發期間,針對每一次的 “MileStone”,也就是完成比較重要的功能後,則其版本在同一個小數點往前推進(如 0.6->0.7)。注意的是,必須是以標記(TAG)來手動制訂。

三、正式版本的推出,則以 1.0 開始。如 CEDT_WK_1.0 版。
  小幅度功能的增加或修正一些 Bugs,則以 1.1->1.2->1.3 ... 漸增。

四、大幅度的功能提升或修正,則推進至 2.0 版。
閱讀全文 »

[CVS]Update & Commit 的差異說明

Developer 從 CVS Repository “Checkout” 至 local 的硬碟內,在 local 內的副本(copy) 稱之為 “Sandbox”。

當 Developer 在 local 端新增(Add)或移除(Remove)後,並將之寫回 CVS Repository。寫回過程若成功則稱為 “Commit”

若 Commit 過程失敗,則表示有其他 Developer 已經修改過在 Repository 內同樣的檔案,此時,就必須使用 “Update”

但若兩位以上的 Developer 都對相同檔案內的原始碼的同一行列(line)做修改過,這種情形稱為 “Conflict”
這種情形雖然很少發生,但若發生後,CVS 並不自動處理,而是針對該檔案所產生衝突的原始碼置入標記(Mark),留待 Developer 手動處理。
其所放入的標記如下:

< <<<<<< filename your changes ======= code merged from repository >>>>>>> revision

當 Developer 手動更改衝突的內容,並移除 CVS 的標記後,Developer 使用 “Commit” 寫回 CVS Repsoitory。

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal