Taobao FED

关注前端开发流程

关注前端开发流程

流程,通俗来讲,就是许多人,在做一系列的事情时,怎样相互协调,安排好这一系列事情的先后顺序,有什么事先的约定,需要达到怎样的预期目标。

在 UED 里,前端同学需要处理的需求比较多,早些时候,前端这里的开发流程还是比较模糊的,UED 以外的同学也不清楚这边的工作具体是怎样进行的,所以难免会有需求插队的情况发生,打乱了大家的计划,因此今年 Q3 的时候,在与 SCM 团队同学的共同努力下,形成了一个前端的 assets 发布流程。

这个流程主要针对 assets 发布的需求做了一些约定,制定了相关的几个时间点,包括审核需求、提交代码、daily 测试、预发测试、正式发布到线上确认的时间。

assets 流程简述

需求审核

在提需求之前,需求方一般都会先找 PM 或者相应产品线的前端咨询一下,如果可行的话就会在周四之前将需求提到平台上,到了周四的时候,前端会结合自身的工作情况,将平台上的需求接收并纳入自己的日程中,预估完成时间、发布时间以及相关的发布简述。

编码开发

周四需求评估完以后,就会按计划开始处理需求,将涉及 assets 发布的需求优先处理,不涉及 assets 的放在靠后的时间处理,一般这段时间是从周四到下一周的周二。SCM 会在每周四开一个新的 assets 分枝供前端在下一周开发使用。

提交代码,合并到 daily 测试以及预发测试

如果有涉及到与后台开发相关的需求,前端的同学会在周一就把代码提交,这一天会有一次合并代码,方便后台开发来测试。其他的同学一般最晚会在周二下班之前把代码提交,在周二,会有多次合并代码到 daily 的操作,每次操作完后,SCM 的同学会在前端的群里通知到大家,方便大家测试。

周三早上,SCM 的同学会将代码发布到预发环境,此时就可以在 HOST 中绑定 IP,换用线上的地址来测试。

正式发布

周四上午,SCM 的同学确认后,将没有问题的代码发布上线。

流程的作用

在团队不断成长的过程中,处理的需求数量也在增长,需要考虑到开发的效率、产品的质量以及团队协作间的配合等因素,这个流程能为我们解决很多相关的问题:

督促需求方做好相关的规划

有些时候,一些需求的细节还没完全确定,但需求方总希望能将他想到的各种细节都实现出来,然后再挑选其中一种做为他的方案,所以需求的变更会有些频繁,然而这样的成本有些高,一切应该在计划后再去实现,而非反其道而行。现在需求方会在提需求之前,会花时间地去考虑他们的需求,将尽可能多的情况都想清楚,做好必要的沟通工作,权衡各种利弊之后,再给出一个比较成形的方案。

保证需求安排的有序性

在一个大的团队中,不同部门的同学在一起合作,因为沟通及一些特殊情况,效率或多或少会受到一些影响,良好的规划能有助于提高开发的效率。

通过每周的需求审核,安排好下一周的日程,由于需求的优先级和先后顺序都已排定,工作的条理性会更加清晰,需求插队的现象也有明显减少。当然我们也有紧急流程,但是它仅限于处理线上 bug 以及一些经过多方确认的紧急需求,有其自己的适用范围。

统一测试,归避风险

之前的日常处理中,可能会遇到这样的情况:甲、乙两个同学分别需要处理两个日常需求,他们的需要改动到的代码会有重合的部分,如果他们并不知道这个情况,那么在他们本地的单独测试中,一切都是 ok 的,然而当发布到线上去时,发现出了 bug 或者一方的改动没有同步到线上,查原因后发现是提交的代码相互覆盖了。

现在要处理的需求数量越来越多,为了避免上述情况,新流程实行以后,大家会统一来做多次测试,这样就更容易发现 bug,可以大大降低协作开发而产生的风险。

流程本身就是一把双刃剑,有利有弊。一方面,它使我们的需求变得有序,使前端能够在处理一个需求时,不会频繁被其他插队的需求打断。并且因为发布有时间点的设定,所以测试工作会更加严谨,这有助于提升代码的质量。因此对于我们来讲,流程带来的好处是显而易见的;但另一方面,它额外地增加了做事的成本,涉及 assets 发布的需求,就像赶某班火车一样,错过了就只能等下一班,所以也给需求方带来了许多不便,有待改进,不过这可以通过长期的合作而慢慢被弱化,双方达成了一种默契以后,情况会好很多,现在这样的情况已经比较少了。

尽管在流程使用之初,会带来诸多不便,但是从长远来看,流程有助于使一个团队形成统一的工作方式和态度,将繁杂的事情化整为零,有条理地去处理它们。因为流程,每一个人的责任感都会增强,对风险考虑得会更多一些,这一切都会使产品有质的提升。而我们所有与这个流程有关的人,都会不断地去推动流程改进的工作,这其中还有很多需要思考的:

  • 如何将我们的流程推广到整个公司,让大家都能了解我们的流程,这样在未来需要合作时,需求方需要注意些什么,相关的时间点以及开周时间的预估等,他们就会心中有数。
  • assets 的发布还不够灵活,如果把和应用相关的 assets 独立划分出去与应用一起发布,这样剩下的需要发布的东西就会少很多。或者是按产品线来设计发布流程,根据实际情况来发布。
  • 如何来简化流程上的一些细节,在保持效率的同时,降低实际操作中的成本。
  • 每周二是一个特别的时间点,为了赶在这最后时间提交代码,之前的开发会有些紧张,这种情况也有待改善,比如未来可以一周有两次发布。

流程不是生来就完美,但从现在它带给我们的好处来看,遵循并使用它,对我们的开发会起到很大的帮助作用。我们对待它的态度,决定了它对我们会有怎样的反馈,如果觉得它不合适了,就发出自己的声音,想办法去改进它,不要只是被动地等待。

部分名词解释:

daily 环境:UED 的一个日常测试环境
预发环境:外网 IP,需绑定访问,供内部使用测试
assets:脚本和样式存放的目录
SCM:软件管理配置
PM:项目经理

题图:https://unsplash.com/photos/jUq2Zt-3R2g By @Ben Cliff