2015年6月27日 星期六

程式碼的壞味道(2)

2015/06/27 22:29-23:37

今天延續上一篇的壞味道繼續節錄XD


9. Primitive Obsession (基本型別偏執)


大多數的編程環境都有兩種資料:結構型別(record types)允許你將資料組織成有意義的形式;基本型態(primitive types)則是構成結構型別的積木塊。結構總是會帶來一定的額外開銷。一般程式語言中物件技術的新手通常不願意在小任務上運用小物件。


10. Switch Statements (switch驚悚現身)

物件導向程式的一個最明顯特徵就是:少用switch(case)述句。從本質上說,switch述句的問題在於重複(duplication)。你常會發現同樣的switch述句散佈於不同地點。如果要為它添加一個新的case子句,你必須找到所有switch述句並修改它們。


11. Parallel Inheritance Hierarchies (平行繼承體系)

在這種情況下,每當你為一個class新增一個subclass,必須也為另一個class相應增加一個subclass。如果你發現某個繼承體系的class名稱字首和另一個繼承體系的class名稱字首完全相同,便是聞到了這種壞味道。


12. Lazy Class (冗員類別)

你所創建的每一個class,都得有人去理解它、維護它,這些工作都要花錢的。如果一個class的所得不值其身價,它就應該消失。


13. Speculative Generality (夸夸其談未來性)

當有人說『噢,我想我們總有一天需要做這種事』並因而企圖以各式各樣的掛勾(hooks)和特殊情況來處理一些非必要的事情,這種壞味道就出現了。那麼做的結果往往造成系統更難理解和維護。如果所有裝置都會被用到,那就值得這麼做;如果用不到,就不值得。用不上的裝置只會擋你的路,所以,把它移開吧。


14. Temporary Field (令人迷惑的暫存欄位)

有時你會看到這樣的物件:其內某個instance變數僅為某種特定情勢而定。這樣的程式碼讓人不易理解,因為你通常認為物件在所有時候都需要它的所有變數。在變數未被使用的情況下猜測當初其設置的目的,會讓你發瘋。


15. Message Chains (過度耦合的訊息鏈)

如果你看到用戶向一個物件索求(request)另一個物件,然後再向後者索求另一個物件,然後再索求另一個物件這就是Message Chain。程式碼中你看到的可能是一長串的getThis()或一長串暫存變數。採取這種方式,意味客戶將與搜尋過程中的航行結構(structure of navigation)緊密耦合。一旦物件間的關係發生變化,客戶端就不得不作出相應修改。


16. Middle Man (中間轉手人)


物件的基本特徵之一就是封裝(encapsulation)-對外部世界隱藏其內部細節。封裝往往伴隨著委託(delegation)。比如說你問主管是否有時間參加一個會議,他就把這個訊息委託給他的記事簿,然後才回答你。很好,你沒必要知道這位主管到底使用傳統記事簿抑或秘書來記錄自己的約會。但是人們可能過度運用delegation。你也許會看到某個class介面有一半的函式都委託給其他class,這樣就是過度運用。這時應該直接和實責物件打交道。


原來switch這麼驚悚,我卻不知不覺跟它相處了這麼多年...

2015年6月20日 星期六

程式碼的壞味道(1)

2015/06/20 21:07-22:38

今天來節錄<<重構-改善既有程式的設計>>書中提到的程式碼壞味道。


  1. Duplicated Code (重複的程式碼)
  2. Long Method (過長函式)
  3. Large Class (過大類別)
  4. Long Parameters List (過長參數列)
  5. Divergent Change (發散式變化)
  6. Shotgun Surgery (霰彈式修改)
  7. Feature Envy (依戀情節)
  8. Data Clumps (資料泥團)
  9. Primitive Obsession (基本型別偏執)
  10. Switch Statements (switch驚悚現身)
  11. Parallel Inheritance Hierarchies (平行繼承體系)
  12. Lazy Class (冗員類別)
  13. Speculative Generality (夸夸其談未來性)
  14. Temporary Field (令人迷惑的暫存欄位)
  15. Message Chains (過度耦合的訊息鏈)
  16. Middle Man (中間轉手人)
  17. Inappropriate Intimacy (狎暱關係)
  18. Alternative Classes with Different Interfaces (異曲同工的類別)
  19. Incomplete Library Class (不完美的程式庫類別)
  20. Data Class (純稚的資料類別)
  21. Refused Bequest (被拒絕的遺贈)
  22. Comments (過多的註釋)

首先簡單節錄前八個壞味道:

1.     Duplicated Code (重複的程式碼)
最單純的情況就是同一個類別(Class)內的兩個函式函有相同的實作內容

2.     Long Method (過長函式)
不熟悉物件導向的人,常常覺得物件程式中只有無窮無盡的委託(delegation),根本沒有進行任何計算。和此類程式共同生活數年之後,你才會發現這些小小函式有多大的價值。解釋能力、共享能力、選擇能力都是由小型函式支援的。

3.     Large Class (過大類別)
想利用單一類別(Class)做太多事情,其內往往就會出現太多instance變數。一旦如此,Duplicated Code也就解踵而至了。

4.     Long Parameters List (過長參數列)
以前學C語言,老師教我們:把函式所需的所有東西都以參數傳遞進去。這可以理解,因為除此之外就只能選擇全域資料,而全域資料是邪惡的東西。有了物件,你只需傳給它足夠的東西,讓函式從中獲得自己所需要的所有東西就行了。

5.     Divergent Change (發散式變化)
一旦需要修改,我們希望能夠跳到系統的某一點,只在該處作修改。如果不能做到這點,你就嗅出兩種緊密相關的刺鼻味道中的一種了。
如果某個class經常因為不同的原因在不同的方向上發生變化,Divergent Change這個壞味道就出現了。例如:當你看著一個class說:『呃,如果加入一個資料庫,我必須修改這三個函式;如果新出現一種金融工具,我必須修改這四個函式』。

6.     Shotgun Surgery (霰彈式修改)
類似Divergent Chane,但恰恰相反。Divergent Change是指「一個class受多種變化的影響」,Shotgun Surgery則是指「一種變化引發多個classes相應修改」。

7.     Feature Envy (依戀情節)
我們看到某個函式為了計算某個值,從另一個物件那兒呼叫幾呼半打的取值函式(getting method)

8.     Data Clumps (資料泥團)

兩個classes內的相同欄位(field)、許多函式署名式(signature)中的相同參數。


---


本來要去圖書館拿有關UML的書,看到這本書在書架上發光就索性帶回家。
借回來五天,利用交通和空閒時間看,已經讀了140頁。

如果已經碰過程式有幾年經驗,這本書應該能講到你的心坎裡。但是如果你是學程式初學者應該會看得"霧颯颯"。


先聞出壞味道會比較清楚重構的時機

2015年6月13日 星期六

Scrum的意義

2015/06/13 19:16-19:57



圖片來源在此


Scrum是軟體敏捷開發法中的其中一個方法,這個字在橄欖球之中,是爭球的意思,翻成中文有個更貼切的名詞「鬥牛」。

在美式足球的活動裡,同一個隊伍裡面的人目標都必須一致 ---「爭球」,橄欖球彈跳的方向通常很難預測,隱喻在軟體開發的活動中,顧客的需求通常也很難在專案初期就規畫得很完整,需求改變就如同橄欖球的彈跳班難以預測。

在Scrum裡的所有活動,都有規範一個固定長短的時間,時間到活動就應該立即結束,猶如橄欖球比賽,假設比賽結束的那一瞬間,隊伍A 53分,隊伍B 55分,那就是隊伍B獲勝,

隊伍A總不可能說:「再給我五分鐘我就可以把球放進得分區!」←開發軟體的時候,每當死線逼近,我好像都會這樣說XDD

這星期的軟體生命週期,Teddy把Scrum重新拿起來介紹了一番,

Teddy:「Scrum有哪些地方還沒講過的?」

班上同學們:「這學期到現在還沒有介紹過Scrum是什麼,只有看過一個15分鐘的短片」

Teddy:「蝦米!?這學期都沒有講過Scrum。所以你們也不知道整個學期在做什麼,這就代表不用懂Scrum也可以玩得很好。」

Scrum有股神奇的魔力,只要按照它的遊戲規則走,就能暴露出問題所在,所以它又有「照妖鏡」的美名。


情境模擬:

你是Scrum Master,正在一家公司導入Scrum,團隊的開發人員們每天都加班到半夜12點,他們開始抱怨Scrum害他們加班,因此認為Scrum是個爛東西,你是Scrum Master,遇到這種情況,你會怎麼辦?

霸氣回應:「你們加班,就是在隱藏問題!!!」

謎之聲:「其實加班.....是為了解決問題」




Scrum讓我知道原來還有這麼多的問題在等著我要去解決。只有更好,沒有最好

2015年6月6日 星期六

行為的藝術:52個非受迫性行為偏誤

2015/06/06 11:23-12:18



最近上Teddy的課時,他常常在課堂上幫<思考的藝術>和<行為的藝術>打廣告,雖然Teddy每次都講不出書的全名XD,但有定期收看搞笑談軟功部落格的鄉民們一定可以對上頻率。

這兩本書是圖書館的暢借書,兩本書都需要排隊,從三月底開始排隊排到四月底終於拿到了行為的藝術,從5月11日開始看,目前看到第134頁。

這本書共有52個主題,每個主題占4頁的篇幅,很好讀,作者在每個主題的一開始先呈現出一、兩個生活實例與主題互相呼應,然後在每個主題的結尾做結論,結論不一定有標準答案,有時候會以反問的方式,例如「你現在知道該怎麼做了吧?」。

今天來分享一下我認為很棒的幾個主題:


  1. p.22 -> 「因為」是不可或缺的。這個詞語是人際關係的潤滑劑,所以,讓我們盡情使用它吧!
  2. p.26 -> 人的意志力像電池一樣,可透過休息、放鬆補充意志力。假設今天有一個很重要的報告,最好選擇剛充電完的時段報告。
  3. p.42 -> 胡說八道可以掩蓋無知。世界是複雜的,人們必須花費許多心思才能理解一個觀點,在你有這樣的體悟之前,最好奉行馬克‧吐溫的話:「如果無話可說,就閉上嘴巴。」簡潔是漫漫長路的終點,而不是起點。
  4. p.50 -> 試著與最少的資訊共存,才能做出更好的決定。不需要知道的事即便知道了,還是沒有價值。
  5. p.98 -> 不要接受任何不請自來的的建議、盡可能遠離不良的廣告來源、盡量回憶你熟悉的每一個觀點來源。這個工程十分浩大,也會使你的思維變慢,但會讓你更加清晰。
  6. p.114 -> 如果事實與理論相違背,請立即丟棄你的理論。更重要的是,不要試著去等待一個「更好」的理論,這可能需要兩千年。
  7. p.134 -> 你永遠記得第一次見到你終生伴侶的那一刻,那有如照片般深印在腦海中,但你必須假設其中有一半得細節可能是錯誤的
讀閒書進度緩慢前進中...