硕鼠的博客站

范路的博客主站,时而会发些东西。

Posts Tagged ‘框架’

程序员与框架之间的战斗

IPAD 015

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

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

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

这是在做神马

框架设计的目的,通常有这么几点:

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

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

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

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

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

 

Image(1) 

 

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

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

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

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

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

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

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

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

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

这是在做神马

有些应用还有可能会因为使用了过度的框架和不合适的框架,而变得面目全非。这是在做神马

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

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

2010-01-06大杂烩

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

这是在做神马

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

2010-01-04大杂烩

2010-01-04大杂烩

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

2010-01-06大杂烩

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

2010-01-06大杂烩

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

Image

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

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

Image(2)

Close Bitnami banner
Bitnami