1. 云栖社区>
  2. PHP教程>
  3. 正文

基于yui的前端“团队开发”模式

作者:用户 来源:互联网 时间:2017-12-01 10:53:26

前端开发团队模式YUI基于

基于yui的前端“团队开发”模式 - 摘要: 本文讲的是基于yui的前端“团队开发”模式, 原文来自:http://www.uedmagazine.com/ued/comments.php?y=09&m=06&entry=entry090612-094816#   如今web项目也越来越大,单人开发一个网站已经不


原文来自:http://www.uedmagazine.com/ued/comments.php?y=09&m=06&entry=entry090612-094816#


 


如今web项目也越来越大,单人开发一个网站已经不是什么新鲜事了,这种web项目规模扩大的速度似乎超过我们的想象,对代码的管理,对项目的控制,对分
工的把握,对进度的高效推进……一系列的问题开始在web开发中显现出来,其实团队开发不是什么新东西,就像当年炒作ajax的概念一样,只是新瓶装旧酒
罢了,只因互联网的丰富应用给了web工程师很多“创意”的空间,包括功能上、也包括技术上:比如google
wave将10年前的聊天室技术做了包装,将长联接大胆应用于ajax中,再比如yui用面向团队面向对象的开发方法对web站点重新包装,使得web项
目也具备类似erp的项目特点,在java风靡的年代大概还有些新意,再比如web开发中的迭代和极限编程则是10年前软件工程教科书上的东西……,因此
web行业本身没有太多新元素值得推崇,我们所做的,仅仅是在web高速发展的时候,将很多古老的方法应用其中而已。
刚才提到,web开发越来越依赖于团队,web项目也越来越具有完整、典型的生命周期:需求,设计,开发,测试,上线。这个过程会周而复始,并且会有多个周期的重叠或迭代。这使得我们越来越依赖传统软件工程学的方法,使用它来规范web项目的开发。

大型web项目开发中,比较常用的是迭代模型。迭代是在一个主题项目中作类似增量开发的开发模式,它建立在主干代码相对稳定的基础上,适合项目革命性的版
本升级不频繁的情况下使用。通常稳定的线上版本作为主干代码,如果在a时刻有新需求提出,则从此时从主干打出分支,在分支上针对a时刻的需求进行开发,开
发完成并测试通过后将代码合并至主干。图中分支b在合并代码的时候和其母主干已经有区别,红色的部分就是新的“区别”,分支b在d时刻合并代码的时候,用
svn merge很方便,有冲突解决冲突,无冲突合并代码。
基于yui的前端“团队开发”模式

有一种常用的开发模式:极限编程。极限编程是对团队成员要求很高的一种开发模式,每个成员负责的是一个方面而不是单独某个模块,比如一名php程序员负责
项目中所有的后端程序,一名wd负责页面展示,一名项目经理,如果前端工作量很大的话顶多外加一名前端脚本工程师。整个项目的开发由这四人完成,而且完成
既定需求的同时保持代码良好的结构、性能和可扩展。这种开发模式很精简也很快速,但这种项目往往不是孤立的,经常是一个大项目的子项目,或者仅仅是从主干
拉出来的分支而已,每次快速开发后都会多少产生冗余,比如css、js或img文件不能被并行开发的其他分支共享,自然也无法重用,因此这种开发模式也仅
仅适合工期短的项目开发。比如下图中的b分支。
基于yui的前端“团队开发”模式

而在这两种典型的开发模式中,前端的开发一直处于一种尴尬境地,前端文件是一种资源文件,除了html页面之外,js、css和img文件是作为资源被
php文件使用的,因此js、css或img不像php文件那样,新功能开发完后可以直接覆盖掉原有文件,除了在svn中作备份以便回滚之外,并无版本的
概念。而css、js和img在增加新功能后则不能覆盖原有文件,必须在文件名后缀上一个新的版本号另存一份,供新的php文件访问,而老版本的
css、js和img仍然被其他不确定的php文件引用着。
基于yui的前端“团队开发”模式

么如果并发的多个分支项目中同时修改相同的js或css,问题就出现了,php代码可以合并到主干中,同一份js或css代码如何合并两个同时开发的版本
呢。svn能解决部分问题,但解决不了根本问题,因此我们只有期望两个并发项目不会同时升级同一份js文件,也只有将js或css的粒度做到很细很细,即
每个js或css文件都很小,只有一丁点的功能,这样小的功能被同时两个项目修改的概率自然会很低。可将js文件瓜分成众多小文件而且管理方便是何等不
易。
yui很好的解决了这个问题,yui给出了一个高效拆分并管理js和css的思路:模块化。从yui2到yui3的过渡可以看到这种
趋势,未来的
web项目但凡有点规模都需要模块化,在yui中,模块是分层次的,每个模块都有其依赖的子模块,子模块也有其依赖的孙模块,最后发现复杂的模块是由简单
的模块拼装而成的。而每个模块都可以单独做成一个文件,这样就可以在项目开始之初,在前端架构阶段就规定好模块的粒度,这个粒度是取决于项目变化的程度
的,变化越频繁,粒度就应当更高,以免并行项目对同一份js或css文件作更新。
这样的话,一个功能性的页面需要引用的只是一个页面逻辑
的js文件,这个js文件去load其需要的模块,模块再去load各自需要的子模块以及孙模块,模块文件的递归load和去重由yui完成,我们只需要
关注页面的js文件即可,每个模块都会自动去引用所需的css,不用我们操心。
如此高粒度的js文件和css文件在页面装载的时候是个大麻烦,下图是现在雅虎关系load的js文件,这还是在没有瓜分js模块的情况下,每个js文件占用一个请求,会大大降低页面的装载速度。
基于yui的前端“团队开发”模式
yui
给我们提供了combo的方法,但也仅仅针对yui的模块提供,对于项目中的js和css文件则没有combo的支持,yui3虽然是
beta版,至今也没有要支持的迹象,只要硬生生的去改yui源代码了。combo后的结果就是这样,yui2的资源和基于yui2的js文件以及
yui3的资源和基于yui3的js文件各一个请求,外加一个yuiloader.js和yui.js各一,这样yui2和yui3并存的情况下的js请
求顶多也只有这4个了。
基于yui的前端“团队开发”模式

yui的代码也不费劲,在yui2中combo的处理是在的yuiloader.js中的_combine函数中,在yui3中则是yui.js
中的_combine中,可以根据自己的项目资源存储情况修改。这样,修改后的yui可以更广泛的支持combo,项目js文件就会和yui文件一并
combo输出,页面展示也会一下子从D上升到B或者A,哈哈。
在yui的框架下的前端开发变的如此高效率也更加轻松,这样的话,高粒度的js模块代替了功能性的js开发,更加有利于代码的抽象和重用,也大大降低了并行开发中升级同一个js文件的苦恼。项目迭代前进的效率也会越来越高,而前端页面的性能却丝毫不受影响。
你看看自己是否还在辛苦的压缩合并js呢。是否在苦恼的频繁累赘的升级js文件版本。如果是,那么很遗憾,你已经落伍了。

以上是云栖社区小编为您精心准备的的内容,在云栖社区的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索前端 , 开发 , 团队 , 模式 , YUI 基于 ,以便于您获取更多的相关知识。