極端分子之歌--讀XProgrammer筆記

Imagine

Imagine there's no requirements. It's easy if you try
Just a bunch of coders, reachin for the sky
Imagine all the people, coding for today

Imagine there's no schedules. It isn't hard to do
No silly project deadlines, no one supervising you
Imagine all the people, coding hand in hand

You may say I'm an extremer but I'm not the only one
I hope someday you'll join us and make coding lots more fun.

Imagine oral documentation. I wonder if you can
No need for UML diagrams. Just words passed, man to man
Imagine just refactoring, playing in the sand

You may say I'm an extremer, but I'm not the only one
I hope someday you'll join us and make coding lots more fun.

想象
想象如果沒有需求。你的嘗試就會覺得容易。
只要幾行程式碼，你就能到達天空
想象所有的人們，為今天而編寫程式碼
想象沒有時間進度，做起來也不會太難
沒有該死的專案截止日期，也沒有人監督你
想象所有的人們，手牽手一起編寫程式碼
你也許會說我是個極端分子，但我並不是唯一的一個
我希望有一天你能加入我們，充滿樂趣編寫許許多多的程式碼
想象一下口頭文件，我懷疑你是否能做到
不需要UML 檢視，只需要從一個人到另一個人的語言傳遞
想象只需要重構，如同在沙灘上玩耍
你也要說我是個極端分子，但我不是唯一的一個
我希望有一天你能加入我們，充滿樂趣編寫許許多多的程式碼

這是非程式設計師第49期的文章愛麗絲漫遊用例奇境裡引用的一段歌詞，出處在Songs of the Extremos ,很有意思的軟體之歌，如果知道原曲旋律，唱起來一定很爽口....比如> The Long and Winding Thread...

回到xProgrammer上，今天看了若干期，在差不多開始厭倦於那些枯燥，抽象，充斥各種莫名術語，行文乾巴巴或糾纏不清的文案時，突然看到愛麗絲漫遊用例奇境這一篇，妙趣橫生，感覺蠻不錯的。

愛麗絲說：“我無法斷定哪種情況更加糟糕：陷於‘分析癱瘓’當中，還是在理解需求之前直接跳到編碼部分。我多希望有一種介乎兩者之間的簡單方法啊。”

也許愛麗絲的問題並沒有一個徹底的解決方法(沒有銀彈:P），或者沒有人能將解決方法描述的盡善盡美，至少，在CMM/RUP...等貌似重型方法論大行其道，XP/“程式碼即設計”的極端回應之後，終於有人開始如何思考有效的縮短“做什麼”和“怎麼做”之間的間隙了。

PS:RUP是否重型方法論，其實也是有爭議的。在xProgrammer的37期，有一篇七步搞死RUP,嘟嘟囔囔的痛斥瀑布，宣揚迭代，給RUP申冤，認為在RUP中引入瀑布思想，過度和不適當的設計，誤解RUP，才使RUP冒出BAD SMELL。以下為搞死RUP七步簡單筆記：

第一步:加入瀑布思想
有些東西應該象建造房屋那樣去構建設,但軟體不是
初始化階段探索少量但重要的需求(10%)獲得範圍,風險尺度,
大部分需求是在細化階段探索,此階段迭代的構建體系結構和解決技術風險
迭代週期長度是2~6周.迭代方法允許我們邊學邊走.固定成本問題

 第二步:將RUP作為重型的，預見性的過程去應用
重型過程的特徵是刻板,繁瑣,形式化而缺乏人性化
RUP並非重型和預見性的,其本意是使用輕量,敏捷和適應性的過程精神
適當建立RUP活動和工作
不存在所有迭代的詳細計劃

第三步 避開物件技術能力
對於技術領域來說,熟練的物件技術開發人員和採用RUP或者任何過程,後者是相對次要的因素
藍領工人理論並非所有專案都通用

第四步:低估適應性迭代開發
應該在組織和專案層次上擁抱變化,
迭代開發的思想是要在只完成了部分需求和設計的時候,快速開始程式設計,這樣做是為了得到實際的反饋
迭代開發的核心是基於反饋進行調整
開發者和客戶是合作伙伴關係

開發人員不理解系統要做什麼->加強需求管理
複雜的控制流或難以理解的行為->加強用例管理
技術方案是否新穎或複雜-> 進行體系結構優化設計

第五步避開深諳迭代開發的顧問（如果專案有顧問的話）

第六步:轟轟烈烈的採用RUP
形式主義，填鴨式的推行RUP

第七步採納（以RUP名義的）錯誤的建議

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-578371/，如需轉載，請註明出處，否則將追究法律責任。