為自己寫一個Pattern

2015/7/18 14:16-15:01

固定每個星期六來想一篇網誌的今天，剛剛好是自己的生日，在生日的這天，來反省一下自己。

目前覺得自己對一件事情的看法太少，常常讓我想起<少年Pi>裡面，Pi的父親和Pi說過的一句台詞：「如果你什麼都信，就代表著你什麼都不信。」

對於生活上瑣碎的事情，每當和死黨聊天的時候，多多少少會聊到一些對於社會議題的看法，我發現自己通常對於發生的事情都抱持著淡定的態度，其實想發表一些什麼，但卻發現自己講不出個什麼。呈現一個「腦死」狀態。

來練習一下把自己的狀況寫成Pattern。


Context：
€  一個平常對於任何事情或突發狀況都很淡定的人

Problem：
€  如何培養對於週邊事物發表個人看法的能力？

Force：
€  平常沒有動腦的習慣
€  發表自己的看法後怕別人見笑
€  身旁的人難以溝通，自己懶得費工
€  腦袋空空好像怎麼講都不對

Solution：
€  揪一個朋友看每天花同樣的時間看一樣的書，每天看完的當下就討論所看到的內容


前進速度緩慢

Martin Fowler整理的重構名錄

2015/7/2 20:34-21:20

前幾天終於把<重構>這本書讀完一次了，這本書有一半算是工具書，介紹非常多的重構手法，每個重構手法都以一個例子介紹，每個重構手法通常都可以找到它的情侶XD，原本正方形的東西不好看，所以凹成的長方形，凹長方形之後看起來有覺得怪怪的，於是又凹回了正方形。

在寫程式的時候，重構通常是為了讓程式碼更乾淨，但有時候還是會被"設計"綁住，對於還沒碰到的問題，有了過多的設計，也許在這個當下，你認為將來系統會遇到某些的擴充，所以你為了預防這個很久很久才會到來新需求或是非常偶爾才會出現的Special Case，開始重構程式，把原本功能簡單的程式碼切成很多Class去實作，以便以後可以應付這種Special Case。過了一段期間，才發現之前太杞人憂天了，很多預想的狀況根本都沒有發生，於是開始反重構，把很多冗員類別刪除。

這本書厲害的地方就在於每一個重構手法都以很小的步驟慢慢前進，在實際的工作中，可以先培養聞壞味道的能力，然後遇到某種壞味道的時候，在把這本書拿出來翻到最後一頁，參考下面的兩張表格，找出能解決這個壞味道的重構手法。

擷自<重構>最後一頁

擷自<重構>最後一頁

---

最近感冒，一直覺得頭好暈阿，差點兒沒發網誌。

讀完中文版的第一次，再去借了一本英文版，即使看過一次中文版的，英文版的讀起來還是頗硬阿！

先把一本原文書重頭到尾讀三次→Teddy Chen教我的那些事

程式碼的壞味道(3)

2015/7/3 21:58-22:44


上兩篇節錄了16個在重構中所提到的壞味道，
<程式碼的壞味道(1)>
<程式碼的壞味道(2)>

剩下6個壞味道，今天終於要把它們全部抄完節錄了

---

17. Inappropriate Intimacy (狎暱關係)

有時你會看到兩個classes過於親密，花費太多時間去探究彼此的private成分。如果這發生在兩個「人」之間，我們不必作衛道之士；但對於classes，我們希望他們嚴守清規。

18. Alternative Classes with Different Interfaces (異曲同工的類別)

兩個函式做同一件事，卻有著不同的署名式(signature)。

19.Incomplete Library Class (不完美的程式庫類別)

復用(reuse)常被視為物件的終極目的。我們認為這實在是過度估計了(我們只是使用而已)。但無可否認，許多編程技術都建立在library classes的基礎之上，沒人敢說是不是我們都把排序演算法忘得一乾二淨了。Library classes構築者沒有未卜先知的能力，我們不能因此責怪他們。畢竟我們自己也幾乎總是在系統快要構築完成的時候才能弄清楚它的設計所以library構築者的任務真的很艱鉅。麻煩的是library的形式(form)往往不夠好，往往不可能讓我們修改其中的classes使它完成我們希望完成的工作。

20. Data Class (純稚的資料類別)

所謂Data Class是指：它們擁有一些欄位(fields)，以及用於存取(讀寫)這些欄位的函式，除此之外一無長處。這樣的classes只是一種「不會說話的資料容器」，它們幾乎一定被其他classes過分細瑣地操控著。

21.Refused Bequest (被拒絕的遺贈)

subclasses應該繼承superclass的函式和資料。但如果它們不想或不需要繼承，又該怎麼辦呢？它們得到所有的禮物，卻只從中挑選幾樣來玩！

22.Comments (過多的註釋)

從嗅覺上來說，Comments不是一種壞味道：事實上它們還是一種香味呢。我們之所以要在這裡提到Comments，因為人們常把它們當作除臭劑來使用。常常會有這樣的情況：你看到一段程式碼有著常常的註釋，然後發現，這些註釋之所以存在是因為程式碼很糟糕。這種情況的發生次數之多，實在令人吃驚。

Comments可以帶我們找到本章先前提到的各種壞味道。找到壞味道之後，我們首先應該以各種重構手法把壞味道去除。完成之後我們常常會發現：註釋已經變得多餘了，因為程式碼已經清楚說明了一切。

『當你感覺需要撰寫註釋，請先嘗試重構，試著讓所有註釋都變得多餘。』

如果你不知道該做什麼，這才是註釋的良好運用時機。除了用來記述將來的打算之外，註釋還可以用來你並無十足把握的區域。你可以在註釋裡寫下自己「為什麼做某某事」。這類資訊可以幫助將來的修改者，尤其是那些健忘的傢伙。

---

書中的這個章節，我覺得是全書最精華的地方，之前翻了一點<深入淺出程式設計>，雖然有認識到一些Pattern，但是一直無法找到應用某個Pattern的時機。

就在今天利用Extract Super Class重構的時候，突然發現重構完的地方可以套用Command Pattern，突然有一種串起來的感覺，頗有成就感XD。

每個軟體工程師都應該來讀一下重構這本書。

程式碼的壞味道(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這麼驚悚，我卻不知不覺跟它相處了這麼多年...

程式碼的壞味道(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頁。

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

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

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讓我知道原來還有這麼多的問題在等著我要去解決。只有更好，沒有最好

行為的藝術：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 -> 你永遠記得第一次見到你終生伴侶的那一刻，那有如照片般深印在腦海中，但你必須假設其中有一半得細節可能是錯誤的。

讀閒書進度緩慢前進中...