常常聽到人說冷氣啟動很耗電，但是這個「很」到底有多「很」從來沒聽過有人算出來看，其實每個小資訊網路上都有，但是沒人把全部知識整合出來算給你看，於是本文簡單計算闢謠。

備份優質的文章，你可以把這裡作為一個書籤頁，原文請到原始網站查看。

• 閒聊 - 「好程式」跟你想的不一樣! 初讀「重構」有感
• 重構筆記 - 壞味道 (Bad Smell)
• 重構筆記 - .NET 壞味道補充包
• 重构-改善既有代码的设计
• 能抓耗子的就是好貓？閒談程式碼 Anti-Pattern

最近看到黑暗執行緒關於重構的文章很感興趣，存了一陣子終於有機會搬出來稍微整理一下，本文是個人紀錄和閱讀心得。程式新手上網查怎麼寫好程式就會看到如何撰寫乾淨的程式寫的那些原則，然而很多文章把「必要原則」和「建議原則」寫在一起導致很多誤會，以 DRY 為例：

Repeat Yourself

1. 工程師 A 觀察到程式碼中存在重複。
2. 工程師 A 將這些重複提取出來並賦予它一個名稱，形成新的抽象化，這可能是一個方法，也可能是一個類別。
3. 工程師 A 將重複的程式碼替換為新的抽象化，感覺程式碼變得完美無缺後心滿意足地離開。

時間過去……

4. 新的需求出現，現有的抽象化幾乎能滿足，但仍需進行少許改動。
5. 工程師 B 被指派來實現這項需求，他們希望能保留現有的抽象化，於是通過增加參數和條件邏輯來適應新的需求。

這樣一來，曾經的通用抽象化開始因應不同情況而表現出不同行為。

隨著更多需求的出現，這個過程持續重複：

6. 又來一個工程師 X。
7. 又增加一個參數。
8. 又新增一個條件判斷。

最終，程式碼變得難以理解且錯誤頻出。而此時，你正好加入了這個項目，並開始陷入混亂。