正文開始

我們是由于效率和易用性的考慮才產(chǎn)生框架。框架能節(jié)省開發(fā)時間?？蚣軓娭剖褂霉驳募s定，因此它能有效地解決一些共有的問題，比如頁面渲染，assert判斷，安全或者應用配置等。這些共有的問題有個共通的特性是會在每個web應用上都用到。

框架是非常好的，它能讓決定更連貫?？蚣苣鼙苊馕覀儗懸淮蠖炎远x模塊來實現(xiàn)這些性能，我們所需要做的就是將這些共用模塊放在框架中實現(xiàn)。框架節(jié)省了我們不少的時間和精力，并且讓擴展變得更容易。但是這也是問題的根本所在。

由于框架能在我們做代碼決策的時候提供很多的幫助，因此我們就變得懶了起來。我們不去考慮如何使用抽象思維搭建一個干凈清晰的系統(tǒng)，不去考慮最后的代碼是否干凈清晰，卻依賴著框架來替我們實現(xiàn)這些需求。

對錘子來說，所有事物都是釘子

Abraham Kaplan說過的一句話能最好地控訴工具的缺點：把錘子給一個小孩，他會用錘子槌遇到的所有事物

當把這個道理用在框架上的時候，我們就是工具確定的犧牲者。當我們遇到需求不是很符合框架，我們就會犯懶。我們就會按照框架既定的方法來解決我們的問題。因為使用框架既定的方法來解決方法是最簡單的，這時候我們已經(jīng)忽略了如何設(shè)計對未來擴展等需求最好的代碼了。

這就是衡量你是否更職業(yè)的時候了，交付對未來擴展最好的代碼而不是交付最容易實現(xiàn)的代碼。是為了以后的需求更好的設(shè)計你的代碼還是讓以后的人做需求的時候再考慮，這就是程序員的責任感問題了。作為一個更職業(yè)的開發(fā)者，我們必須不依賴框架獨立思考。

這就是你的錯

是不是經(jīng)常聽到某人在抱怨某個框架？我已經(jīng)聽見好多人抱怨過Rails了：“Rails應用總是糟糕的結(jié)構(gòu)”或者“Rails測試總是這么慢”。最開始，我也曾經(jīng)這么認為。但是現(xiàn)在，每當我聽到這些抱怨的時候，我就會意識到其實抱怨者是懶惰的。Rails，或者其他框架，只是一個工具而已，你要做的是控制它。把壞代碼歸咎于無生命的框架只能說明你的不專業(yè)。

選擇正確的工具，或者正確地使用工具

使用框架開發(fā)也是在寫代碼。作為一個開發(fā)者，你有權(quán)利選擇如何實現(xiàn)需求。人們都希望能開發(fā)出干凈整潔的代碼，那樣的話使用面向?qū)ο笏枷牒秃侠淼某橄缶褪欠浅Ｖ匾牧恕Ｒ_發(fā)出好的代碼，我們必須仔細考慮我們的代碼設(shè)計，特別是當使用框架的時候。

決定變得更專業(yè)

我們必須根據(jù)基本的需求來選擇工具?？蚣艽_實能做很多事情，并且需求會決定整個代碼結(jié)構(gòu)。有的時候框架會很適合某個需求。但是當框架不適合某些需求的時候，你就有責任為了代碼的清晰和干凈修改框架或者封裝框架。

作者

Myles Megyesi

正文結(jié)束

讀后感
文章中提到框架只是一個工具，你不能用這個工具來滿足你的所有需求，當框架無法清晰完整地滿足你的需求的時候，你要做的不是寫一大堆垃圾麻煩的代碼來實現(xiàn)需求，更不是修改你的需求來滿足更容易實現(xiàn)這件事。作為更專業(yè)的你，你需要修改框架，或者使用抽象等思維來使你的代碼達到清晰干凈。

這點在實際開發(fā)中會遇到非常多。當別人問你：這里的代碼為什么這么寫？ 如果你的回答是：沒辦法啊，因為框架是這么這么做的，我只能這么這么做。這就說明了你已經(jīng)被框架束縛住了。不要認為框架是權(quán)威，框架也是別人寫的，它寫的時候不會考慮到你的需求。只要你的需求是團隊的公共需求，需要修改，增加框架的時候，你就應該修改框架。

選擇框架和使用框架是控制框架的基礎(chǔ)。什么需求，什么規(guī)模使用什么框架，選擇好框架后就要熟練使用熟悉框架。當框架無法滿足需求的時候，要毫不猶豫拋棄或者修改框架。

代碼是讓人更清晰自然的閱讀和開發(fā)的，如果被一個框架捆綁住，實際上就是本末倒置了。

最新評論