Rails 代碼重構
這份教程將說明如何寫出好的 Rails 代碼。
Part 0
1. 什麽是重構？
進行重構教程前，請先完成程式語言系列。
重構(Refactoring)是指對軟體代碼進行更動以增加可讀性或者簡化結構，但是不影響功能和輸出結果。
真正營運的軟體都是演進來的，而不是一步到位的作品，需要藉由頻繁與用戶互動得到的回饋來修改設計。與其把軟體開發比喻成蓋房子，實際上更像是園藝，需要長時間的呵護。我們甚至可以說，所有得軟體開發其實都是一種維護，因為絕大部分的時間都在改code，寫一點改一點。即使是新專案，也很快需要回頭作修改。
因此面對日漸複雜的代碼、以及 團隊協同開發的需求，維護好代碼是一件重要的事情。
不好的代碼，會有以下症狀：
- 僵硬 (Rigidity)：難以修改，每改一處牽一發動全身
- 脆弱 (Fragility)：一旦修改，別的無關地方也炸到
- 固定 (Immobility)：難以分解，讓程式再重用
- 黏滯 (Viscosity)：彈性不夠，把事情做對比做錯還難
- 不需要的複雜度 (Needless Complexity)：過度設計沒直接好處的基礎設施
- 不需要的重復 (Needless Repetition)：相同概念的代碼被複製貼上重復使用
- 晦澀 (Opacity)：難以閱讀，無法瞭解意圖
好的代碼，會有以下特徵：
- Readability 易讀，容易瞭解
- Flexibility 彈性，容易擴充
- Effective 效率，撰碼快速
- Maintainability 維護性，容易找到問題
- Consistency 一致性，循慣例無需死背
- Testability 可測性，元件獨立容易測試
很多時候，為了專案時程，我們會在專案初期只專註於盡快完成專案，而妥協於寫出不好的代碼，這些不好的代碼又被叫做技術負債。因為就像債務一樣，雖然短期可以得到好處，但必須仍在未來償還，不然之後軟體會變成越來越難維護，要新增功能的開發成本也會越來越高。工程師需要付出時間成本才能修復之前的妥協所造成的問題。
透過重構行為，我們希望讓不好的代碼，變成好的代碼，減少技術負債。這份教程，會用實際的範例，說明重構前和重構後的差異。這篇教程沒有提及自動化測試，不過一個好的重構，建議搭配自動化的測試，這樣才可以確保重構前後的軟體行為是一樣的，而沒有帶來新的 bugs。
重構不等於重寫。重構更像是小地方小地方的不斷持續改善，而不是花幾個月把代碼砍掉重寫。
重構教程著重在思考為什麽這樣寫比較好，而不是實現功能。照著做是沒有意義的，因此這份教程並沒有完整的功能實現，而是代碼片段(code snippet)。