===========正文开始

我们是由于效率和易用性的考虑才产生框架。框架能节省开发时间。框架强制使用公共的约定，因此它能有效地解决一些共有的问题，比如页面渲染，assert判断，安全或者应用配置等。这些共有的问题有个共通的特性是会在每个web应用上都用到。

框架是非常好的，它能让决定更连贯。框架能避免我们写一大堆自定义模块来实现这些性能，我们所需要做的就是将这些共用模块放在框架中实现。框架节省了我们不少的时间和精力，并且让扩展变得更容易。但是这也是问题的根本所在。

由于框架能在我们做代码决策的时候提供很多的帮助，因此我们就变得懒了起来。我们不去考虑如何使用抽象思维搭建一个干净清晰的系统，不去考虑最后的代码是否干净清晰，却依赖着框架来替我们实现这些需求。

对锤子来说，所有事物都是钉子

Abraham Kaplan说过的一句话能最好地控诉工具的缺点：把锤子给一个小孩，他会用锤子槌遇到的所有事物

当把这个道理用在框架上的时候，我们就是工具确定的牺牲者。当我们遇到需求不是很符合框架，我们就会犯懒。我们就会按照框架既定的方法来解决我们的问题。因为使用框架既定的方法来解决方法是最简单的，这时候我们已经忽略了如何设计对未来扩展等需求最好的代码了。

这就是衡量你是否更职业的时候了，交付对未来扩展最好的代码而不是交付最容易实现的代码。是为了以后的需求更好的设计你的代码还是让以后的人做需求的时候再考虑，这就是程序员的责任感问题了。作为一个更职业的开发者，我们必须不依赖框架独立思考。

这就是你的错

是不是经常听到某人在抱怨某个框架？我已经听见好多人抱怨过Rails了：“Rails应用总是糟糕的结构”或者“Rails测试总是这么慢”。最开始，我也曾经这么认为。但是现在，每当我听到这些抱怨的时候，我就会意识到其实抱怨者是懒惰的。Rails，或者其他框架，只是一个工具而已，你要做的是控制它。把坏代码归咎于无生命的框架只能说明你的不专业。

选择正确的工具，或者正确地使用工具

使用框架开发也是在写代码。作为一个开发者，你有权利选择如何实现需求。人们都希望能开发出干净整洁的代码，那样的话使用面向对象思想和合理的抽象就是非常重要的了。要开发出好的代码，我们必须仔细考虑我们的代码设计，特别是当使用框架的时候。

决定变得更专业

我们必须根据基本的需求来选择工具。框架确实能做很多事情，并且需求会决定整个代码结构。有的时候框架会很适合某个需求。但是当框架不适合某些需求的时候，你就有责任为了代码的清晰和干净修改框架或者封装框架。

作者

Myles Megyesi

==========正文结束

读后感

文章中提到框架只是一个工具，你不能用这个工具来满足你的所有需求，当框架无法清晰完整地满足你的需求的时候，你要做的不是写一大堆垃圾麻烦的代码来实现需求，更不是修改你的需求来满足更容易实现这件事。作为更专业的你，你需要修改框架，或者使用抽象等思维来使你的代码达到清晰干净。

这点在实际开发中会遇到非常多。当别人问你：这里的代码为什么这么写？如果你的回答是：没办法啊，因为框架是这么这么做的，我只能这么这么做。这就说明了你已经被框架束缚住了。不要认为框架是权威，框架也是别人写的，它写的时候不会考虑到你的需求。只要你的需求是团队的公共需求，需要修改，增加框架的时候，你就应该修改框架。

选择框架和使用框架是控制框架的基础。什么需求，什么规模使用什么框架，选择好框架后就要熟练使用熟悉框架。当框架无法满足需求的时候，要毫不犹豫抛弃或者修改框架。

代码是让人更清晰自然的阅读和开发的，如果被一个框架捆绑住，实际上就是本末倒置了。

从阿里云os和Google之争看开源协议

最近IT界比较大的事件就算是阿里云os和Google之争，里面的细节没有人知道，但是通过这个事情，我对目前常用的开源协议有了一些了解，也借此机会梳理和总结一下。

自从自由软件之父理查德·斯托曼（Richard Stallman）发起的GNU(GNU's not uinix:说实在的，我也不知道他想表达什么) 运动，开源运动如火如荼的发展起来，现在开源已经成为常态了。至少开发人员应该或多或少的知道一点，但是基本上所有的开发都应该使用过开源产品，例如我们最常用的apache。

由于理查德·斯托曼的认知，认为软件应该就是应该自由和开放的，开发人员应该很容易获得源代码以及进行改动，再把改动之后的源代码发布出来，就这么简单的一个想法，在加上Linus Torvalds 等牛逼黑客的加入，GNU影响力越来越大。GNU发布了GPL协议，这个协议和当初创世人的理念有关。

GPL(General Public License)协议主要特点：

所有的源代码都是公开的，可以自由使用。但是是有版权的
如果对GPL的开源代码进行修改，就必须把修改之后的代码进行开源
如果引用了GPL的代码库，就必须开源你引用部分的代码。相当于你的代码中如果有一行代码引入了GPL协议的库函数，就必须把整个代码开源。就是所说的传染性
如果使用的是GPL产品，没有上面的限制。这个说实在的，我觉得真不好界定。例如java中的openjdk，如果你只是使用他的编译器编译你的java程序，是没有必要开源你的java程序
GPL是free（自由的），但是是可以收费的。我们经常认为开源的就是免费的，这个是不对的。

从上面的限制来看，GPL开源协议还是有很大的传染性的。如果一个商业公司引用了开源代码或者库函数，就必须开源引用它的整个代码。有一些公司不愿意开源咋办，就不能用了。毕竟对于商业公司来说，代码是我的资产，我没有必要开源，所以这个协议对商业公司不是很友好

LGPL（GNU Lesser General Public License):是GPL的变种，这个是宽松的GPL，对于商业公司比较友好，如果使用了LGPL的库，可以不开源的你的代码。与GPL的最大不同是，可以私有使用LGPL授权的自由软件，开发出来的新软件可以是私有的而不需要是自由软件。所以任何公司在使用自由软件之前应该保证在LGPL或其它GPL变种的授权下。

BSD(FreeBSD Copyright Information)：这个算是宽松的协议了，你可以使用和修改它的源代码，注明使用了他就可以了，你自己的代码是可以私有的。只要别侵权就可以，比如直接copy了源代码，说是你自己写的，这样就不对了。

Apache Licene：这个和BSD差不多，但是要注意几点，如果修改了源代码，要注明修改了什么。开源代码的商标，专利，所有权都要保留的，不能说修改了开源apache 协议的开源代码，就直接把代码的作者写成你，这样是不对的。发布产品的时候，对于自己修改的apache 开源代码，不能够变成其他的开源协议。

MIT：这个说实在的，我个人见的比较少，这个算是最自由的协议了，和BSD一样，但是修改了MIT源码，可以加入自己的授权。

常用的也就上面几种

下面来看看 android的问题

由于android 使用linux的代码库，按照道理来说，android必须以GPL的协议进行开源，但是考虑到GPL对商业上非常不友好，一旦有公司想优化andorid，对android进行定制，也必须开源这一部分代码。但是google怎么做的了，这个是另外一个篇文章分析里面的一部分

“Linux kernel 的版权是 GPL。

这下问题来了：如果你是硬件厂商，希望你的硬件能在 Linux kernel 下运作，那么就必须要有驱动程序。如果驱动程序的程序代码公开，等于硬件规格也公开的差不多了。许多厂商不愿意这么做，所以就提供编好的驱动程序，但不提供原始码。

Android 的重点就是商业应用，Google采用了一些手法来绕过这问题。他们把驱动程序移到 "userspace"，也就是说，把驱动程序变成在 Linux kernel 上头跑，而不是一起跑的东西，这样就可以避过GPL。然后，在 kernel 这边开个小门，让本来不能直接控制到硬件的 "userspace" 程序也可以碰得到，这样只要把"开个小门"的程序代码公布就行啦。”

所以阿里云OS也应该避免不了，至少要公开这个后门部门的源代码，所以按照道理来说，阿里云要公开这一部分代码，貌似没有公开，好奇它是怎么绕开的。

下面是一些常用的开源产品的授权协议：

tomcat:Apache Licene

android:Apache Licene

spring:Apache Licene

openjdk:GPL

Mysql:GPL

Jquery:MIT（貌似是最近改的）

JBoss:LGPL

Nginx:BSD

发现通用的代码库和开发框架，大多是Apache Licene 授权的，开源的产品大多数是LGPL授权的,apache的产品多是apache license。

爱公司的程序员
博客园blog地址:http://www.cnblogs.com/aigongsi/
本人版权归作者和博客园所有，欢迎转载，转载请注明出处。