本章的主要講的是重構，但是僅僅給出了乙個重構的例子以及簡略說明了一些重構的方法。重構的知識我認為對於開發人員還是很有必要去單獨去找一本書仔細去學習的。這裡只大略講一下本章中提到的一些知識點。
本章站在第一視角，對乙個素數產生的程式進行了重構。看到書中最原始的程式版本，我不禁冒出了一句：「什麼鬼？！」。程式中竟然還有變數的名字為s,f這種完全沒有意義的東西，甚至是乙個函式寫到了底。接下來的篇幅，作者描述了整個程式重構的乙個過程，文中推薦了intellj idea的重構工具。主要的重構操作包括：將一些具有一定功能的**提取出為新的函式，並注釋該函式的功能，重新命名變數以及函式的名字，更改了部分程式的結構。其中令我印象比較深刻的乙個細節是：作者甚至把if(iscrossed[i] == false)提取成乙個notcrossed()函式，因為這樣閱讀性更好。我認為這個細節還是很值得學習的，要盡量站在閱讀者的角度去寫你的主要邏輯（雖然我覺得上述這個改動有點過頭了，畢竟誰都知道括號裡就是notcrossed的意思）。
在本章的結尾，作者也解答了我看完本章心中的乙個疑問，過多的把這些小的細節提取出函式難道不會對系統的效能產生影響嗎？作者如此說：增加的可讀性值得這些額外的花銷，如果說會造成巨大的效能損失，可以等待日後證明了再說，我們先假設可以忽略這種效能損失。。
也許有人認為程式能跑就行，重構的會過多的浪費時間，但是這是建立在程式不出錯的基礎上。畢竟現實中有很多bug，離職，需求變更。我們吃飯可以不刷碗，但是下次吃飯你就會後悔，因為你要花更多的時間清潔那些已經硬了的汙垢。
敏捷軟體開發（原則，模式與實踐）
教堂尖頂上的風標，即使由鋼鐵製成，如果不懂得順應風勢的藝術，一樣會被風暴立即摧毀。海因里希.海涅 一 敏捷軟體開發宣言 1 個體和互動勝過過程和工具 人是獲得成功的最為重要的因素。合作 溝通以及互動能力要比單純的程式設計能力更為重要。乙個由平均水平程式設計師組成的團隊，如果具有良好的溝通能力，將比那...
敏捷軟體開發 原則 模式與實踐 之敏捷實踐
參與公司的敏捷開發也有一段時間了，還沒有系統的學習過敏捷開發。比如早上的站會，每個月的迭代會，還有自己領取任務去開發故事，這些都是敏捷開發的流程之一。敏捷開發需要不斷的學習，不斷的實踐。現在開始寫一些關於敏捷開發的部落格。一 敏捷聯盟 1 個體和互動勝過過程和工具 乙個優秀的團隊成員未必是乙個一流的...
敏捷軟體開發 原則 模式與實踐 （一）
為了達到敏捷開發，我們需要使用一些實踐提供必要的準則和反饋，需要使用一些設計原則使我們的軟體保持靈活且可維護，還需要理解一些已經被證明在特定問題中可以權衡這些原則的設計模式。敏捷軟體開發宣言 人和互動 重於 過程和工具 可以工作的軟體 重於 面面俱到的文件 客戶合作 重於 合同談判 隨時應對變化 重...