Ruby 讀書心得整理 - lustan3216/BlogArticle GitHub Wiki

###Practical Object-Oriented Design in Ruby 全部讀完

1. 程式與程式之間要越鬆散越好，如果耦合過多的話會造成程式碼上維護的困難與不方便。
2. 了解到為什麼要區分公有介面和私有介面，如何在物件與物件之間互相彼此信賴達到鬆散的程式碼。
3. 吸收了識別鴨子類型的技巧，分辨出來之後再修改，讓程式更提升了物件互相的信賴程度。
4. 擁有鬆散的程式碼之後，可以把共同的區塊抽象層抽出製作Class類別，以及分辨什麼時候適合製作模組Module擴充方法。

###Rebuilding Rails 讀到第六章

此書是參加週三Ruby讀書會時所閱讀的，每人會分別實作書本的其中一個章節。

感觸較深的是第五章的File-Based Models。rails最常做的就是對Model做CRUD，此章目的是用制式化且最簡易的方式create file，將每筆資料寫入Table時的行為模擬一個個的file，並模擬當rails對資料庫做CRUD時是怎麼與資料庫溝通和處理，其中才了解到rails幫我們處理了很多細節，但平常使用時因過於便利而沒有發現的細節所在。

###Unfuck A Monorail For Great Justice 全部讀完

此書主要著墨於「接手或維護一個遺留許多legacy code的大型專案」時較佳的對策：

1. 不要嘗試去了解每一個function的行為，更不要去讀每一個function裡面是怎麼運作，因你不了解寫此function的撰寫人的程度，常因function裡的表面字義所欺騙，所以應該直接對此function寫最簡易的unit test，了解妳即將所面對的function「需要什麼」和「會產生什麼」即可。
2. 嘗試將你所要維護修改的所有function寫下最簡易的unit test，這份測試文件可以讓需要維護此code的人對該專案的理解有個「大致的輪廓」。如需改寫的情況下，可以不用透過完整了解以前的專案內容，便能輕易地了解要撰寫什麼樣的function．
3. 建議使用DCI (Data, context and interaction ) 等design pattern，將各種不同的"服務"搬進service裡，進而淨化model肥大的code，讓MVC架構不再臃腫。

其中了解DCI架構之後，深深覺得目前自己撰寫的MVC架構是需要被改善的，因為真的像本書中有"臃腫"的感覺，正在研究如何配合OOP的方式實作在專案中。

###Effective Ruby: 48 Specific Ways to Write Better Ruby 讀到第五章

介紹很多Ruby語法上的特性，近似的語法下該用什麼語法和技巧解決才能達到最佳的效果極效能。其中以Hash預設值章節最印象深刻，因為對專案的實用性很高，其中Hash的預設值使用上也暗藏了陷阱，了解這些陷阱的由來與解決方式，已能實際運用於開發中的專案。