前端工程优化之路

本文首发于欧雷流前端工程优化之路前端

在我加入「买好车」后第一次把项目代码从远程仓库拉取到本地时——「这是什么玩意?!」——个人心里是震惊并诧异的。git

为何我会有如此反应?后端

买好车」是一家具备阿里基因的公司,创始人和员工不少来自阿里。众所周知,阿里的技术是很不错的,基本每一年都会主办一些技术会议,有些技术书籍也是阿里人著做或翻译的。所以,心理上会对他们在技术方面有较高的预期。然而,呈如今眼前的现实将我从幻想中拉了出来……服务器

代码维护

不像大部分团队那样先后端代码放在一块儿维护,咱们的项目代码是分开管理、维护的,即先后端代码不在同一个 Git 仓库当中。前端代码只有一个仓库,存放了公用资源、活动页、主站等不一样业务线的代码,每一个项目是一个目录;后端代码以项目为单位分为几个不一样的仓库存放。部署上线也是分开进行。session

这种作法美其名曰「先后端分离」,实际究竟是不是,值得思考。前端工程师

Git 的使用

团队在使用 Git 时主要存在两方面问题:分支管理策略和代码提交准则。less

分支管理策略

每次打开 SourceTree,首先映入眼帘的就是五光十色的「彩虹线」——前后端分离

提交记录图表

和好些过时的分支——运维

.
└─┬─ origin
  ├─── dev_frontend
  ├─── dev_general
  ├─── dev_inquiry
  ├─── dev_maiche
  ├─── pub_20160111
  ├─── pub_20160112
  ├─── pub_20160113
  ├─── pub_20160114
  ├─── pub_20160128
  ├─── pub_20160202
  └─── ...

看得我简直是头晕目眩,不知从何「编」起啊!frontend

形成这种状况的最直接的缘由就是,没有一个好的分支管理策略。这里的分支管理策略是这样的:

每周有两个固定的发布日,在每一个发布日以前某个管理发布的测试工程师(是的,咱们没有运维工程师)会基于 master 分支建立前缀为 pub_ 的发布分支,在发布以前会将要发布的内容都汇总在这个分支上进行测试,经过后再合并到 master 分支上进行发布。然而,发布完不会马上将那个分支删掉,而是要保留几个星期以免出问题。这样就会像上图中那样有好多过时的分支留在那里。

有些不是马上发布的内容,后端工程师们就会本身基于 master 分支建立出 dev_ 为前缀的分支来开发新内容。

虽然他们在建立分支时都是有必定的规则,但这种作法产生了一些「垃圾」分支,以及使 master 分支看起来不那么稳定,像定时炸弹同样随时会「嘭」!

我以为团队中应该采用 Git Flow 来管理分支,这是一个不知通过多少团队验证的分支模型,我有信心它可以应对咱们团队所遇到的各类场景。

代码提交准则

咱们团队的 Git 提交记录很「简单」,要么写着几个简单的字母或词语,要么就是合并分支时生成的节点,一眼望去根本不知道那些人到底作了什么。这若是是想查找某个功能点的更改记录,得逐个节点去分析。

在使用 Git 时应该遵照一个基本原则——使提交记录尽量简洁详细,看它就像读一本书。要达到这种效果,只需牢记几点:

  • 控制提交粒度;

  • 填好提交信息;

  • 调节推送频率;

  • 多衍合少合并。

要使每一个提交都具备意义,粒度最好控制为一个小 feature 或者一个 bug fix,这样进行恢复等操做时可以将「误伤」减到最低。

一个好的提交信息是,用一句简练的话写在第一行,而后空一行略微详细地阐述该提交所增长或修改的地方:

Redirect user to the requested page after login

https://trello.com/path/to/relevant/card

Users were being redirected to the home page after login, which is less
useful than redirecting to the page they had originally requested before
being redirected to the login form.

* Store requested path in a session variable
* Redirect to the stored location after successfully logging in the user

不要每提交一次就推送一次,多积攒几个提交后一次性推送,这样能够避免前一个提交后发现代码中还有小错误,这时能够经过衍合进行提交的合并或者信息修改。

为了保持图表清晰和代码完整性,要掌握好提交和推送操做的时机——

尚未推送到远程仓库时,如无必要则只提交不要推送,只在须要与他人配合开发时再推送。当所在分支已经完成职责时,需将父级分支的代码衍合到当前分支(得先保证父级分支在本地是最新的),而后合并至父级分支并删除当前分支。理想状况是,这个分支的整个生命周期没有进行过一次推送操做

当已经推送到远程仓库时,先积累几个提交的内容而不去作提交操做,等到要推送时先拉取代码到本地,而后按照上述粒度作几回提交,再推送到远程服务器。这种操做流程可以有效避免因代码冲突而形成的提交丢失等意想不到的问题,以及减小因合并产生的提交节点。

合并分支产生的节点

扩展阅读

前端工程

与整个技术团队相比,前端团队中所存在的问题更多更为严重!基本能够归纳为如下几点:

  • Git 仓库混杂了不少不一样的业务;

  • 源代码复用性低;

  • 没有合理使用构建工具;

  • 静态资源文件的发布流程繁琐;

  • 活动页面的编写方式麻烦,而且对搜索引擎不友好。

我做为一名前端工程师,虽然暂时没法去对整个技术团队作些什么,可是做为前端团队的一员,却能够在前端团队中作些力所能及的事情。在我看来,「有问题」就表明着「机遇」,该是我大展拳脚的时候了!想起来都以为肾上腺素大量分泌,热血沸腾!

那么,我该作些什么呢?

我所想到的可以提升前端团队工做效率和生产力的手段有:

  1. 制定编码及文件存放等的规范和约定;

  2. 选择高效的语言编写源码;

  3. 选择合适的自动化工具;

  4. 保证以上几条顺利执行的措施。

为了提升前端团队的总体素质和实力,须要作的事情还有不少。想要完成这些不是一朝一夕的事情,前端工程优化之路任重而道远啊……

想在已有的项目上进行改造会存在着很大的阻力,幸亏这时公司业务拓展要开发新项目。决定从这新的项目着手,小试牛刀,总结出一套方案后推行整改到其余项目。

以本文为引,日后会写几篇关于咱们前端团队建设的文章,敬请期待!

相关文章
相关标签/搜索