正文开始
我们是由于效率和易用性的考虑才产生框架。框架能节省开发时间。框架强制使用公共的约定，因此它能有效地解决一些共有的问题，比如页面渲染，assert判断，安全或者应用配置等。这些共有的问题有个共通的特性是会在每个web应用上都用到。
框架是非常好的，它能让决定更连贯。框架能避免我们写一大堆自定义模块来实现这些性能，我们所需要做的就是将这些共用模块放在框架中实现。框架节省了我们不少的时间和精力，并且让扩展变得更容易。但是这也是问题的根本所在。
由于框架能在我们做代码决策的时候提供很多的帮助，因此我们就变得懒了起来。我们不去考虑如何使用抽象思维搭建一个干净清晰的系统，不去考虑最后的代码是否干净清晰，却依赖着框架来替我们实现这些需求。
对锤子来说，所有事物都是钉子
Abraham Kaplan说过的一句话能最好地控诉工具的缺点：把锤子给一个小孩，他会用锤子槌遇到的所有事物
当把这个道理用在框架上的时候，我们就是工具确定的牺牲者。当我们遇到需求不是很符合框架，我们就会犯懒。我们就会按照框架既定的方法来解决我们的问题。因为使用框架既定的方法来解决方法是最简单的，这时候我们已经忽略了如何设计对未来扩展等需求最好的代码了。
这就是衡量你是否更职业的时候了，交付对未来扩展最好的代码而不是交付最容易实现的代码。是为了以后的需求更好的设计你的代码还是让以后的人做需求的时候再考虑，这就是程序员的责任感问题了。作为一个更职业的开发者，我们必须不依赖框架独立思考。
这就是你的错
是不是经常听到某人在抱怨某个框架？我已经听见好多人抱怨过Rails了：“Rails应用总是糟糕的结构”或者“Rails测试总是这么慢”。最开始，我也曾经这么认为。但是现在，每当我听到这些抱怨的时候，我就会意识到其实抱怨者是懒惰的。Rails，或者其他框架，只是一个工具而已，你要做的是控制它。把坏代码归咎于无生命的框架只能说明你的不专业。
选择正确的工具，或者正确地使用工具
使用框架开发也是在写代码。作为一个开发者，你有权利选择如何实现需求。人们都希望能开发出干净整洁的代码，那样的话使用面向对象思想和合理的抽象就是非常重要的了。要开发出好的代码，我们必须仔细考虑我们的代码设计，特别是当使用框架的时候。
决定变得更专业
我们必须根据基本的需求来选择工具。框架确实能做很多事情，并且需求会决定整个代码结构。有的时候框架会很适合某个需求。但是当框架不适合某些需求的时候，你就有责任为了代码的清晰和干净修改框架或者封装框架。
作者
Myles Megyesi
正文结束
读后感
文章中提到框架只是一个工具，你不能用这个工具来满足你的所有需求，当框架无法清晰完整地满足你的需求的时候，你要做的不是写一大堆垃圾麻烦的代码来实现需求，更不是修改你的需求来满足更容易实现这件事。作为更专业的你，你需要修改框架，或者使用抽象等思维来使你的代码达到清晰干净。
这点在实际开发中会遇到非常多。当别人问你：这里的代码为什么这么写？ 如果你的回答是：没办法啊，因为框架是这么这么做的，我只能这么这么做。这就说明了你已经被框架束缚住了。不要认为框架是权威，框架也是别人写的，它写的时候不会考虑到你的需求。只要你的需求是团队的公共需求，需要修改，增加框架的时候，你就应该修改框架。
选择框架和使用框架是控制框架的基础。什么需求，什么规模使用什么框架，选择好框架后就要熟练使用熟悉框架。当框架无法满足需求的时候，要毫不犹豫抛弃或者修改框架。
代码是让人更清晰自然的阅读和开发的，如果被一个框架捆绑住，实际上就是本末倒置了。
我们是由于效率和易用性的考虑才产生框架。框架能节省开发时间。框架强制使用公共的约定，因此它能有效地解决一些共有的问题，比如页面渲染，assert判断，安全或者应用配置等。这些共有的问题有个共通的特性是会在每个web应用上都用到。
框架是非常好的，它能让决定更连贯。框架能避免我们写一大堆自定义模块来实现这些性能，我们所需要做的就是将这些共用模块放在框架中实现。框架节省了我们不少的时间和精力，并且让扩展变得更容易。但是这也是问题的根本所在。
由于框架能在我们做代码决策的时候提供很多的帮助，因此我们就变得懒了起来。我们不去考虑如何使用抽象思维搭建一个干净清晰的系统，不去考虑最后的代码是否干净清晰，却依赖着框架来替我们实现这些需求。
对锤子来说，所有事物都是钉子
Abraham Kaplan说过的一句话能最好地控诉工具的缺点：把锤子给一个小孩，他会用锤子槌遇到的所有事物
当把这个道理用在框架上的时候，我们就是工具确定的牺牲者。当我们遇到需求不是很符合框架，我们就会犯懒。我们就会按照框架既定的方法来解决我们的问题。因为使用框架既定的方法来解决方法是最简单的，这时候我们已经忽略了如何设计对未来扩展等需求最好的代码了。
这就是衡量你是否更职业的时候了，交付对未来扩展最好的代码而不是交付最容易实现的代码。是为了以后的需求更好的设计你的代码还是让以后的人做需求的时候再考虑，这就是程序员的责任感问题了。作为一个更职业的开发者，我们必须不依赖框架独立思考。
这就是你的错
是不是经常听到某人在抱怨某个框架？我已经听见好多人抱怨过Rails了：“Rails应用总是糟糕的结构”或者“Rails测试总是这么慢”。最开始，我也曾经这么认为。但是现在，每当我听到这些抱怨的时候，我就会意识到其实抱怨者是懒惰的。Rails，或者其他框架，只是一个工具而已，你要做的是控制它。把坏代码归咎于无生命的框架只能说明你的不专业。
选择正确的工具，或者正确地使用工具
使用框架开发也是在写代码。作为一个开发者，你有权利选择如何实现需求。人们都希望能开发出干净整洁的代码，那样的话使用面向对象思想和合理的抽象就是非常重要的了。要开发出好的代码，我们必须仔细考虑我们的代码设计，特别是当使用框架的时候。
决定变得更专业
我们必须根据基本的需求来选择工具。框架确实能做很多事情，并且需求会决定整个代码结构。有的时候框架会很适合某个需求。但是当框架不适合某些需求的时候，你就有责任为了代码的清晰和干净修改框架或者封装框架。
作者
Myles Megyesi
正文结束
读后感
文章中提到框架只是一个工具，你不能用这个工具来满足你的所有需求，当框架无法清晰完整地满足你的需求的时候，你要做的不是写一大堆垃圾麻烦的代码来实现需求，更不是修改你的需求来满足更容易实现这件事。作为更专业的你，你需要修改框架，或者使用抽象等思维来使你的代码达到清晰干净。
这点在实际开发中会遇到非常多。当别人问你：这里的代码为什么这么写？ 如果你的回答是：没办法啊，因为框架是这么这么做的，我只能这么这么做。这就说明了你已经被框架束缚住了。不要认为框架是权威，框架也是别人写的，它写的时候不会考虑到你的需求。只要你的需求是团队的公共需求，需要修改，增加框架的时候，你就应该修改框架。
选择框架和使用框架是控制框架的基础。什么需求，什么规模使用什么框架，选择好框架后就要熟练使用熟悉框架。当框架无法满足需求的时候，要毫不犹豫抛弃或者修改框架。
代码是让人更清晰自然的阅读和开发的，如果被一个框架捆绑住，实际上就是本末倒置了。