我剛開始接觸 Rails 是在 2007 年。Rails 在世界剛竄紅。當時遑論說要一個 Developer 寫出容易維護的程式碼，基本上，在那個時代能夠使用 Rails 「兜」*(註）出一個堪用的網站，你都算一個高手了。

經過了四年，這個框架一路發展到現在。能夠自在的使用 Rails 的 Developer 在台灣卻也都還不算多。其中有很多原因，除了本地語言的文件不夠多之外，文件和 API 更迭過速導致開發環境破碎，也對後進者造成很大程度的學習障礙。

這一行可以說大家都是邊做專案，邊熬夜翻網路文件，跌跌撞撞把網站「拼」出來的。

維護擴充性的重要性

有些人，幸運的只是接案維生的 Developer，在練功「拼」完專案之後，就不需要再維護這些急就章的程式碼。

但在這個世界上，絕大多數的人，還是屬於服務於企業中，需要持久維護一個專案的 Developer。

這兩種人，我都當過。

因為浸淫在 Rails 的開發世界夠長，本身培育過 Developer，也開發過不少專案。在經歷維護專案，並持續升級 Rails 版本後，我漸漸能體悟到寫出好維護的程式碼是多麼重要的一件事。

如果程式碼亂七八糟：

• 你根本無法進行網站下一次的改版擴充動作，即便是功能上的小改版
• 你根本無法進行 Rails 版本升級的動作，因為你會被過去造成的錯誤（不管是自己或者是夥伴）不斷懲罰，導致寸步難行。

接著業務拓展和工作進度就會開始被這些程式碼開始扯到後腿…

寫程式變成了一件不快樂的事。

沒有書教你怎麼寫出好的（ Rails ）程式碼

但話說回來，寫出這些亂七八糟的程式碼，也不是開發者本身故意的。

畢竟 Rails 是一個進化很快的 Framework，要能跟上這個 Framework API 與架構的最新進度，已經很吃力了。很難奢求一般的 Developer 去追求所謂的 Rails Best Practices。

而大多數的狀況是，坊間的書籍與網站往往只教你：

• 如何快速把開發環境建置起來，開發一個示範站台，利用 plugins 建構出簡單的 feature。 — 看完了這本書只學會 CRUD。

• 另外一個極端，將所有 API 全數羅列出來， — 翻的時候只想睡，翻完之後不知如何應用在自己 project 之內

其他時候，只能全憑自己經驗或碰運氣看網路上找來的文件。功能可以勉強在時程內湊出來就萬幸，更別提寫出「好」的程式碼了。

This book is for you

網路上不乏許多關於 Rails 的 Best Practices，Antipattern 的演講。比如 ihower 的 [Rails Best Practices] 就是一篇對於寫出高品質 Rails code 很棒的指南。

但在實戰和平日社群交流中，我發覺大家需要的卻不是 Best Practices。Best Practices 離大家的生活太遙遠。大家所需要的是 「Practices」：

• 如何寫出容易維護的程式碼
• 如何避免寫出的糟糕程式碼
• 如何遵循 Rails 架構，寫出標準好維護的程式碼
• 如何透過 Rails 內建機制整理，經過專案積累而日益肥大的 Code Base
• 如何搭配 RubyGems 讓自己的程式碼更乾淨、整潔，更易讀。

在開發功能，專案更迭中，自然持續的維持著專案的整潔。保持著可以繼續高速前進的心情與步調，愉快的工作。

這才是寫 Ruby / Rails 的初衷不是嗎？

本書架構

在接觸過無數的專案之後，我發現許多讓人無法繼續維護的 Rails code。除去開發者偷懶的因素，剩下的原因幾乎都是肇因對於 Ruby / Rails 基礎 API 以及架構不了解，所寫出的問題代碼。

所以這本書的順序將會是這樣的：

1. 介紹 Ruby 通用的的基本 Coding Style，包含程式碼的寫作慣例
2. 介紹 Rails 容易被誤用，但在開發中相當重要的基本工具。
3. Application 的 AntiPattern，什麼是絕對錯誤的架構設計
4. 利用 Rails 原生架構實現的程式碼整理術
5. 利用 3rd Party Gem 實現的程式整理術