硕鼠的博客站

随着社会的进步，高楼大厦林立于市区，社会分工也越来越详细了。不论是游船还是后面的大厦，都不是一个人、一个团队、一个公司，甚至是一个行业可以完成的。越来越多的标准件被应用到了这些东西的建造和运维之中。

同样，随着软件应用的规模不断的扩大，一个人或一个团队从头开始编写完整的程序已经变得越来越难了，而且这样做也非常的不经济。于是有一种东西就进入了程序员们的世界，那就是框架，各种各样的框架。

框架通常是一个很庞大的代码库，由一个公司或一些团队完成。使用特定的语言编写，可以在特定的领域中解决一定的问题。其他程序员使用这些框架，在框架相应的领域中，可以更简单的，更直观的解决和处理该框架所涵盖的问题。

框架设计的目的，通常有这么几点：

对复杂的底层进行封装，使得这一部分可以完全对程序员透明，程序员可以通过这些框架，直接使用底层的功能，而不需要了解底层的细节。

对复杂的业务逻辑进行封装，使得程序员可以使用更加接近自然语言的方式，来构建全新的业务逻辑，满足复杂的企业需求。

对一些容易出错的内容进行封装，让程序员能够按照特定的规范来调用其他的模块、或使不同程序员或团队写出来的代码可以更好的协同工作。

对于不同工种与工序进行划分，便于不同的工种和工序之间进行并行工作和协作。尽可能的对参与同一项目的不同工种和工序进行分割和隔离。使得这些工种和工序，可以独立的进行修改和调整，尽量少的影响到其他的相关环节。对于现在的应用来说，美工和程序员之间的这种协调就是非常常见的，而且这也让很多团队感到非常的头疼。很多框架就是解决类似问题的，可以让美工修改资源的时候，尽量不影响代码。让程序员修改的代码的时候也可以尽可能少的影响美工的工作。另外一个经常和程序员打交道的就是策划了，如果让程序去适应复杂多变的策划，也是很多程序框架试图解决的问题。

对同一类型或有相同使用背景的应用进行规范化，并利于这些应用进行统一的展示、安装、卸载以及信息通讯的框架，很多portal框架都是这么做的，这种框架应用的成功体现就是AppStore了。

 

 

 

既然框架这么好，能够解决这么多的问题。那么为什么本文的标题不是“框架之美”，而是“程序员与框架之间的战斗”呢？

通常一个程序员接触框架的过程是这样的：

接到一个困难的工作，使用原来的手段无法完成或很难在可以接受的时间内，提交满足需要的成果。于是必须使用一个框架了。为了框架而框架的情况是存在的，但是这里不推荐那么做。这个时候，程序员会去网上搜索，去搜寻各种信息，并在浩如烟海的框架中选择一个他认为最适合的框架来使用。悲剧的是，有时候这种选择并不是由技术人员，在清醒的状态下做出的，J2EE就是这么一个看上去很美的错误。

选择了框架之后，并不是马上就能够开始干活儿的，框架虽然对很多东西进行了封装，使其尽可能的变得简单。但不可否认，通常的框架本身也还是很复杂的。要想熟练的使用框架来完成所需要的工作，还是需要有一定的学习过程的。

在学习之后，就是使用框架来解决问题。这个时候，可能就会发现，当初选择的框架并不那么好用，并不是那么贴近自己的应用需要。这种情况通常是由四方面的原因造成的：

第一：对于框架的学习不够彻底和深入，那些适合本次应用的功能没有被发现，以现在框架的复杂程度、同类框架的数量和文档的粗糙程度来看，这很正常；

第二：设计框架的人和当前的程序员在编程习惯方面不是非常相符，使用框架的程序员又非常的固执，众所周知，程序员通常都是很固执的，甚至有些还很偏执；

第三：框架设计的时候，所考虑的覆盖范围，和现在所需要实现的应用有些偏差，或者是框架已经跟不上时代的进步，不能适应当前的情况了；

第四：程序员过于的完美主义，这也是程序员，特别是成功程序员比较典型的一种性格特征。

有些应用还有可能会因为使用了过度的框架和不合适的框架，而变得面目全非。

于是下一个阶段就是对框架进行改造。对于商业框架就提意见，希望能够得到修改。对于开源框架，那就简单了，直接可以进行修改。

然后，程序员会继续使用这些用起来越来越得心应手的框架，去做各种合适或者不合适的事情。经过了不断的修改和调整之后，一个个历史悠久的、有生命力的框架也都向着越来越全面化的方向发展。这个时候，他们就忘记了，框架其实是为了实现某些特定功能而设计的。

即使再全能的框架，也总有一些不适合去实现的功能。不过程序员们是执着的，当他们对一个框架的喜好程度发展到热爱甚至是痴迷的时候，他们是不理智的，甚至是不可理喻的。爱情使人变成白痴，这句话用在这里也是合适的。毕竟一个框架，日夜陪伴着程序员，程序员们学习和了解框架；使用框架攻克难关，完成任务；这些框架还会为程序员做出各种各样的改变，以实用程序员的习惯。这种过程其实和恋爱中的男女相处的过程很像的，那么程序员对于框架产生出一些超出友谊的感情也是很正常的。于是就会出现这样一种情况，一些程序员会使用他们所钟爱的框架，去完成一些该框架本身完全不适合的工作。

即使这看起来很不协调，但是程序员们也会坚持去这样做的。

最终，很多程序员会选择抛弃框架，或者不得不抛弃以前那些笨重的框架，重新去选择一些轻量级的东西，甚至干脆自己开发框架来使用。但是这些框架最终也逃脱不了上面那些框架的命运，会变得越来越庞大的，最终再被抛弃。毕竟维护一个框架的成本也是很高的。有些公司由于一个框架而得到了成功，最终也由于那个框架，走向了消亡。框架是很难与时俱进的，通常情况下，框架是只能做加法，很难做减法的。毕竟框架的升级是需要考虑向下兼容性问题的，如果从框架中做了减法，那么就意味着以前的应用，在升级使用新框架的时候，有一部分无法正常工作。

现在还有很多高级程序员，更喜欢裸奔。

这就是战斗了，裸奔和框架之间的战斗。框架和框架之间的战斗。那么程序员们到底应该如何面对框架呢？特别是在自己也开发了框架，或者至少是自己对现已有框架非常熟悉，并且熟悉到分不清自我的情况下，应该如何面对其他框架呢？

建议大家，在需要的时候，选择需要的框架。框架的使用也是有成本的，请选择成本最优的方式，来判断是否需要使用框架，以及应该使用什么样的框架。如果是一个周期很长，即使使用了框架也需要进行大量工作的任务，那么就千万不要去选择那些不了解、不熟悉或学习成本很高的框架。因为，所有框架都有一个特性，那就是易学难精。如果有些框架不需要很深入的了解，就能够很好的完成当前的应用，那么请毫不犹豫的选择使用这些框架。毕竟这样可以使应用的开发周期极大的缩短。尽量不要去选择那些包打天下、包治百病的框架，这种东西通常是很臃肿的，而且这种东西一旦遇到了不擅长的领域，会让大家非常难以取舍。不要去选择那些很难进行调整和修改的框架，这种东西很可能会因为一点点的不契合，就让你不得不放弃它，但这个时候随着框架一起被放弃掉的，很可能是整个团队在该框架上付出的巨大努力和海量代码。在选择框架的时候，首先要确定这个框架还有人维护，还有很多人在用，网上有足够多的资源，能够帮助你和你的团队度过开始的学习期，也能够在遇到困难的时候，很容易的找到网上的先辈们来帮忙。如果团队中的大部分人都熟悉一个框架，那么即使现在的框架并不是完全适合当前的需要，最好也是直接在现有框架的基础上进行小的调整，而不是去找个新的来。实际上完全符合需要的情况基本上是不存在的。当然，如果实在是相差太远的话，那也就不要太坚持，有时候换一个会更好一些的。

程序员与框架之间的战斗，归根结底还是一个度的把握问题。到底能不能将这个度把握好，做出正确的判断和取舍，决定了程序员是不是能够战胜框架，征服框架，并和框架一起再去战胜应用。希望以后大家能够在和框架的战斗中得到美妙的享受。就像男人和女人的战斗一样。