团队痛点以及方案

2014年7月1日 分类: 随笔
1)项目文件“接口”唯一化
       前端很多一部分工作都是在写静态页(包括业务js),每次写完都是直接通过qq邮箱或qq把静态页打包发给上下游检查或嵌套代码。但下面的场景大家应该都会经常遇到:
     上游看完静态页后发现一些问题跟他设计的或交互不一致,需要你修改,前端修改完再次把压缩包发给上游,来来回回导致上游那会出现v1,v2多版本的情况。或者如果当时接收完没及时后,后续都不知道还有这事。
      对下游来说我们只有提供该项目的svn地址,他们直接checkout下来就可以了,这样获取的都是最新项目的代码,还可以存在版本记录。
      这种重复易出现的问题,就是在项目配合中的一个痛点。
      现在的解决方案是:
      对外:各位童鞋把写好的静态页都放在ued svn上同步到内网直接提交一分可预览的页面给上游,如果有问题沟通完可以直接刷新查看,减少了文件的传输以及避免错误的误解。
      对内:对前端团队来说,团队内部的任何童鞋都可以开发、修改任何一个静态页,以达到项目交叉配合。一定程度上提高开发效率。
     基于前端这种模式都可以推到ued内部的其他部门,特别是对ui部门的psd管理。
    ps:对每个项目组来说,只关注结果,前端内部的如何协作,是几个人来做还是一个团队来做,对他们来说是不透明的。
2)维护性项目或已上线的项目维护
     这种类型的项目往往是要去修改后端嵌套完的页面,如果本地没开发环境,你就很难做到修改就及时预览的效果。所以一般的做法都会是安装个虚拟机来做本地的开发环境。
     针对这种类型的项目特点,有几个问题:
      a:本地环境比较难搞(主要是模版数据的问题),如果要多人合作一个项目的化,每个人都要在本地配置一个,这样维护的成本太高了,每加入一个新人就要配置一个。
      b:利用虚拟机的话,在项目中试用过半年,有时候突然奔溃了,项目就玩不动了,或者一会儿nginx没启动,一会儿apache没启动或者虚拟机时间不对导致本地页面没数据,等等这种类似的问题,这种情况一次两次之后,心都操碎了。这种也是会有上面那个同样的问题,每一个新人加都进来都要搞一次环境。
经过多方面考虑权衡后,把这种类型的项目部署到内网去,前端就不用去管那个里面的配置,他们只要checkout项目代码到本地然后修改完通过ftp直接上传到内网上,(这部分可以利用ide来自动上传)这样就可以做到及时修改及时更新的效果。这样也就解决了环境的配置问题,数据也解决了,不用开虚拟机了,解脱了前端上多种的困然。
后期有新人加入项目的话,只要提供一个ftp的账号就可以了。如果调试都ok了,把本地的代码直接提交到项目svn上。
但是采用这种的有个弊端是毕竟是用ftp所以不能多个人对同一份文件进行修改保存,不然会导致覆盖的项目。但相比之前造成的困然,我觉得整个弊端可以通过人为的约定下就可以解决。
ps:上面记录的都是在项目配合过程中遇到的痛点,把一些重复的或容易出问题的点给解决了,你在其中所收获的远远不止这些。这可以涉及到是否有心发现问题,以及之后的解决问题的方式。
可能上面所提到的都是很简单,很粗暴的办法,但可以解决现在团队内遇到的问题,也算是一个到现阶段比较好的解决办法。优化问题的解决方案可以持续进行。
标签:
目前还没有任何评论.

Leave a Comment