Facilicator專注在：程序流、心流、語言流。不重視：內容流

Facilicator須具備：聆聽、觀察能力；扮演：協助流程進行、催化劑的角色

程序流：先不討論怎麼設計產品，先討論設計產品需要怎樣的流程
ex1: 怎麼幫女友解決工作上的抱怨？(當垃圾桶 or 顧問？)
ex2: 今天客戶要來，老闆行程很趕，要你提供一份向客戶介紹的簡報 (問會議是5分鐘 or 還是下午2-5點)
ex3: 大老闆決議，要在高雄成立雲端中心，最後問大家有甚麼意見？李經理提出心中的疑慮，才講完就被老闆要求閉嘴 (><：老闆已經收斂，最後應該問大家有沒有不清楚的地方？)
ex4: 小蘋快要從大學畢業，正在猶豫該升學還是就業，去澳洲打工好像也不錯。這時有澳洲打工經驗的你開始淘淘不絕… (<>：小蘋還在發散，你已經收斂)

心流：優先解除心中疑慮、陌生感，引導提問者正向思考
ex1: 大學生來做參訪，一開始就直接帶到公司會議室做簡報
ex2: 大咖來參加會議，一開始沒提供車馬費或中午用餐資訊
ex3: 雙方沒有自我介紹就直接開始開會
ex4: 如果另一半要離你而去，你只能問一個問題：當初是甚麼原因讓我們在一起

語言流：引導活動要循序漸"境"
1.問白癡問題 (團體舉手)
2.問是非題 (要想一下)
3.問選擇題 (要想兩下)
4.問開放性問題 (請台下聽眾闡述)
5.問創造性問題 (請台下聽眾發問)
ex1: 引導對方你希望的答案 (選擇題，不要開放式)。餐廳：你最喜歡哪一道菜；遊戲：你最喜歡哪一些關卡
ex2: 問題題目要考慮Ownership (你有多大的主導權)。X: 如何讓"消費者"購買廣達產品 O: “廣達產品"要如何吸引消費者

OMI原則：
O: Ownership 主導權、擁有權
M: Motivation 有動機去解決
I: Imagination 有想像空間

腦力激盪原則：(發散時期) => 與會者知識的重新排列組合
1.一次一個人發言
2.聚焦於主題
3.暫時不評斷
4.追求大量點子
5.尋求狂野點子
*6.由他人點子想新點子

支持性語句：
(A) Facilicator萬用語句：
1.可不可以多說一點？
2.可不可以舉個例子？
(B) 組員支援性語句：
1.謝謝XX的這個點子，讓我聯想到…
2.我呼應XX的點子…
3.我再補充XX的點子…
4.我在XX的點子加點東西…

Q & A：
Q1: Facilicator可以讚美人嗎？
A: Facilicator可以讚美發言者的"流程"，不可以讚美發言者的"內容"

Q2: 有些人一直保持沉默
A: 繼續觀察 & 等待，用支持性語句

Chap2.命名
1. 匈牙利命名法: 在有 IDE 的環境下不需要
2. 型別不應出現在名稱中。ex: AccountList、EmptyString
3. 介面名稱不須編碼，要就在實作編碼。ex: ObjectImp
4. 類別以名詞命名；方法以小寫動詞命名
5. 一個好名字通常表達的是「甚麼」(what)，而不是「如何」(how)
6. 用靜態工廠方法取代多載建構子。ex: Complex com = Complex.FromRealNumber(23.0); //取代new
7. 不要在名稱加前綴 (否則 IDE 的提示會帶出所有此前綴的名稱)

Chap3.函式
1. 函式內容要簡短 (不要超過五行)
2. 函式名稱要明確、只做一件事情、以動詞開頭 (函數名稱長沒關係，不要縮寫；變數名稱長度10~16字元為佳)
3. 每個函式只有一層概念、相同層級的函式應置放在同一區塊 (上抽象下細節，由上而下閱讀程式碼)
4. switch 應搭配多型 (開放封閉原則)
5. 函式的參數不超過3個，以 this 取代輸出型參數 (輸出型參數:傳入一個類別並且有副作用的參數)
6. 指令和查詢分離 ( checkAndSet() 改為 check(){set();} )
7. try/catch 的 try 應該在一個函式的開頭，有多層的 try/catch 應該將內層 try/catch 抽取出來

Chap4.註解
1. 不要替糟糕的程式碼寫註解─重寫它
2. 在重要的步驟寫註解提醒
3. 不要把程式碼註解掉，直接刪掉，改以 source control 找回舊程式碼

Chap5.編排
1. 遵循團隊一致的 coding style

Chap6.物件及資料結構
1. 善用多型 (物件導向) 取代程序式的程式結構
2. The Law of Demeter: 每一行程式只能呼叫一次方法。這個方法來自:1.該物件本身、2.傳入該函式的參數、3.在該函式中所產生的物件、4.該物件的資料成員
3. 以 DTO/POJO/JavaBean 傳遞資料

Chap7.錯誤處理
1. 不要用 enum ERROR_CODE，改用 try/catch
2. finally {} 後面就不要再寫程式碼了
3. 不要在應用程式寫 Unchecked Exception 的捕捉，只能寫在重要函式庫
4. 用一個類別包裹 (Wrap) 第三方API，隔離應用程式直接依賴 API
5. 程式不要傳遞 null 參數，因為一般人都不會對 null 參數寫錯誤處理

Chap8.邊界
1. 把 log4j 包裹成自己的 LogTest class，作者是用來 TDD。可以針對不同用途發展其他 Log class

Chap9.單元測試
1. 一個測試只測一個概念 (DRY法則)
2. 寫測試的法則是 F.I.R.S.T (快速、獨立、可重複性、自我驗證、及時)

Chap10.類別
1. 保持凝聚性(單一職責)會得到許多小類別 (有利發展開放封閉原則)

Chap11.系統
1. 此章節探討AOP、Proxy、工廠模式，模組化關注點

Chap12.羽化
1. 四個原則: 執行完所有的測試，沒有重複的部分，表達程式員的本意，最小化類別和方法的數量(?)
2. 此章以 Kent Beck 程式示範上述原則，與相依注入 (DI) 重構技巧

自己補充:
1.繼承與包含 ─from 軟體建構之道(第二版)
如果多個類別共享資料而非行為，應該建立這些類別可以包含的共用物件。
如果多個類別共享行為而非資料，應該讓它們從共同的抽象類別繼承而來，並在抽象類別裡定義共用的方法。 (對介面寫程式)
如果多個類別既共享資料也共享行為，應該讓它們從共同的抽象類別繼承而來，並在抽象類別裡定義共用的物件和方法。
當你想由抽象類別控制方法時，使用繼承；當你想自己控制方法時，使用包含。

其他人的補充:
http://ihower.tw/blog/archives/1960