之前已經參加過一次公司內部的重構培訓，當時講的冰山模型的概念，即內部質量和外部質量的比例，這一次的講師又強調了一下這一點，這個模型看起來是不錯的。但是真正在實際開發中，這個又是顯得比較理想化了，生產環境下面為了需求而開發功能，不會考慮什麼之後改的時候好不好改，比較好的就是我這種新人，在一年之內參加了兩次這樣的培訓。從頭做起，所以這一次的培訓中的案例重構過程中，我們小組頻頻得獎的原因。

本次收穫的主要有幾句大師的話，總結成自己的話就是:

1. 開車穩點，別太著急，別開快車，不需要飆車炫技。車開的太快我們知道容易發生事故，寫程式碼也是同理，複雜的程式和語句就像是我們開快車一樣。一個包含77個if-else語句的程式，讓誰看誰都不願意看，一個for裡面包含while在包含for的程式，也是誰的不願意維護的，還記得剛進公司的時候，有位同事說維護一個3K的儲存過程，根本不敢改，閱讀，理解需要花費很長很長的時間。

2. 簡單、簡單、就是簡單。程式碼是給人看的，如果不是給人看的話，可以像一些高手直接去寫java位元組碼去，這些都是可以的。但是大部分程式都是業務程式，需求多，任務重。大多數時間都是重複的程式碼，或者邏輯，或者增刪改查。但是如果我們把這些簡單的任務加以抽象，提取共同點，那麼是不是改起來更加簡單呢。如果閱讀程式碼像閱讀優秀的文章一樣有條有理的，我們每個人是不是不會再去看程式碼的時候罵那位寫程式碼的人了麼

3. 價值觀決定行為。 這句話在入職的時候經理專門開了個會，給部門所有人講了這個概念，並且每個人桌子上面也有了對應的標語。但是真正做的有誰呢？幾乎是沒人，程式碼還是一樣的爛，每次看了很氣，但是煩死一下自己的程式碼有時候也是那麼爛，心情不好了寫的就爛，五十步笑百步。

4 好程式碼不是壞程式碼。 給我的感觸最新的就是這句話，說的就是壞程式碼是可以量化的，我們可以找出那些是壞程式碼的指標。 

本次我也就我自己找出十個可量化的指標，不是對每個人都是適合的，因為有一些規範我已經不會再去寫了，比如魔法樹，if的{}號。
1. 函式：不超過50行
2. 函式：一行程式碼只做一件事
3. 函式：不返回null，不傳遞null
4. 函式：不過度追尋單一出口原則
5. 函式：public方法寫成一個目錄
6. 分支：if儘量用肯定句
7. 變數：命名不用not、no，作用域儘量小
8. 測試：多寫些臨界條件的測試（至少三處）（勤修車）
9. 效能：不測試情況下不判斷程式效能( 不開早車 )
10. 心態：專注並懷有謙卑的心態（不開快車）