打磨移动时代的前端团队(二)—— 解题篇


(二)解题篇

只是个开始

此篇名为“解题”,如果您真希望通过看一篇帖子就能解决团队所有问题,那么我要让您失望了, 因为此篇并非问题的终结,而是开始。

前端团队究竟遇到了什么问题?

看看你中枪了么

  1. 项目之初,需求不明,死线(dead line)已定。
  2. 需求改动频繁,排期总是被压缩。
  3. 总是缺人手,加班不断,且代码质量差。
  4. 前后端联调环境搭建耗时,且定位问题麻烦,导致联调时间不可控。
  5. UI过于纠结界面细节,导致交付时间不可控。
  6. 移动端,设备多,兼容问题多,导致自测时间不可控。
  7. 领导说,PM说,UI说,UE说。信息不对等,到底听谁说?
  8. 基于历史原因,总是无法采用更恰当的技术方案,导致团队技术脱节。
  9. 一边加班,一边吐槽,一边被吐槽。
  10. 走人了,换了个团队,问题依旧。

事不关己?

无论你是否关心以上的问题,我想说的是,我们的技术水平来源于自己的精力分配,而我们的精力分配又受限于团队任务分配,所以,每个看似是Leader的问题,其实你我都需要对自己负责。

当我说“提高前端生产力”时,我在说些什么?

从上面的“问题堆”看到,阻碍我们项目交付的,不只是技术,这些非技术的问题更要命。

** 一起聊聊这个“问题堆” **


为了方便举例,我假设存在A ,B两类开发者

  1. 项目之初,需求不明,死线(dead line)已定

但凡有过一些工作经验的开发者,都能接受这个“残酷的事实”。
因为他们懂得站在更高层次看待这个问题。

开发的目的有时候是为了抢占市场,所以时间点往往至关重要。

  • 接手此类项目的开发者有两种心态:
    A. "压力山大",立刻开始设计、编码。
    B. "压力山大,谋定而后动", 基于业务,权衡利弊,发现风险,积极沟通,设计方案而后动。

我喜欢后者 。 做到这些要求你觉得自己真的很有必要“懂业务”
而你的这个选择使你成为了团队今天的骨干力量

  1. 需求改动频繁,排期总是被压缩。

需求改动错了么?

  • 需求变更通常有三种原因:
    1. 源于竞争态势的变化,战略的快速调整。
    2. 敏捷的产品开发实践,小步快跑,渐进明细。
    3. 产品设计人员没有想清楚。
  • 情况1,2 无可厚非,拥抱变化不变的真理。敏捷开发的核心,就是拥抱变化。
  • 情况3,我想替产品开发人员(PM)说句话。
    每一个产品的成败不只是取决于PM,团队中的所有人都是参与者,都要对结果负责。
  • 当面对一个经常变更需求的PM
    • A.只会抱怨"这个PM不给力"
    • B.眼光放在项目目标,思考自己能做些什么。

我想对A说: 大家需要的不是你的抱怨,而是你的“补位”。

  1. 总是缺人手,加班不断,且代码质量差。

缺人手其实是个相对概念。

  1. 项目确实过于紧急,基于目前的人数,无论什么样的开发者都会吃不消。
  2. 业务频率正常,团队生产力低下

对于1, 暴露的问题在于内和外
* 内: 对业务的增量没有充分预估,做好人力储备,或技术架构对人力内调不支持。
* 外: 缺乏跨团队借调人力的能力。

对于2,需要定位原因,是前端团队自身工作流问题,还是与其它团队配合问题。分而治之。此时最好不要再抱怨“缺人手”,以免更加被人“不看好”

** 代码质量问题 ** :我不觉得代码质量总是第一位的。代码的价值应该体现在每一次项目的成功交付。在遵守模块化开发的前提下,烂代码是可以在后续以模块的规模整体替换的。我能接受以低质量代码换取每一次迭代的快速响应。成熟团队会对重点项目进行codeReview结对编程或推行TDD,逐步优化代码质量。

  1. 前后端联调环境搭建耗时,且定位问题麻烦,导致联调时间不可控。

解决之道是“前后端分离” ,目前主流有三种做法,这取决于团队背景、前端的技术力量以及团队技术总负责人的技术选型。

** 前后端分离的技术方案:**

  1. 前端团队掌控线上Http Server,负责View层的拼装,以及少量展现逻辑。数据在http Server端与传统后端在同一机房的网络环境下通过接口交换数据。
* 好处:
    1. 后端不关心view层只做数据接口。
    1. 对SEO支持交给更加了解SEO的前端负责。
    1. 可以做诸如react服务端同构的技术方案(阿里已经有了最佳实践)。
* 弊端:
    1. 前端通常缺乏运维经验,线上服务崩溃风险高。
    1. 上线变得更加复杂。
  1. 前端团队不触碰服务端事务。通过给后端提供初始化数据+demo html页的形式进行分离。
* 好处:
    1. 后端只需要copy前端demo源码构建view层
    1. 后端只做数据接口(同步接口,异步接口)
* 弊端:
    1. 后端还是需要随时根据HTML demo的变化,重新构建view
    1. 后端需要管理静态资源版本
  1. 把html放在CDN上,静态资源版本完全由前端控制,后端只做接口。
    • 好处:
      1. 前后端完全分离
    • 弊端:
      1. 后端很难做session,所有的cookies都需要前端判定,并不适合所有页面。

广告:我所在的团队把2,3的前后端分离解决方案,整合到了我们的工作流里面并做了开源,旨在为初创团队持续提供完整高效的前端工作流。它是一个gulp插件,名为 turbo

  1. UI过于纠结界面细节,导致交付时间不可控。

一个FE,没被UI的“像素眼”盯过,那么他的FE生涯将是不完整的。

  1. 精益求精永远是没错的,但还是要从项目的紧急程度来看问题。好的FE需要一定的沟通能力。

  2. FE需要协同UI,UE 制定组件化视觉规范。

  3. 移动端,设备多,兼容问题多,导致自测时间不可控。

移动时代虽然让FE脱离了恼人的各种IE,却又带来了更多的平台的兼容问题。我们希望通过一个个可复用,经过测试的组件来减少日常开发的跨终端的测试。
试想,如果每次开发,80%以上的模块都是复用可靠且兼容的组件开发,那么这些兼容性问题,将会随着组件库的丰富,越来越少。

  1. 领导说,PM说,UI说,UE说。信息不对等,到底听谁说?

毫无疑问,无论“是谁说”,最后都得听领导的,别问我为什么!
(但又不能事事都问领导,轻重请自行把握)

  1. 唯一项目负责人原则:

    1. 由于FE对接的层面很多,包括 PM,UE, UI,RD ,如果收到每个角色的反馈,就立即动手,后果可想而知,一个FE会不会工作,由此可鉴。
    2. 我推荐“唯一项目负责人”原则,FE依赖的资源都需要这个负责人审核并给出,包括MRD,UI,UE,接口文档(接口文档与RD的后续沟通可以脱离项目负责人),可有效避免信息不对等。 如果有项目经理最好,没有项目经理 默认是 产品经理(PM)
  2. 基于历史原因,总是无法采用更恰当的技术方案,导致团队技术脱节。

其实架构也有很多当时的受限条件
1. 业务规模
1. 团队阶段
1. 时代技术背景
1. 架构师技术能力和视野

  • 要解决这个问题,首先我们必须承认,根本不存在完美的技术方案和架构。我们需要拥抱变化,为向未来的技术和架构过渡做好准备。
  • 渐进式架构与技术债务
    1. 基于团队的不同形态设计适合不同阶段的架构与技术堆栈。同时,需要以开放的心态看待 "技术债务",就像我们通常不喜欢欠债,但有时候贷款也是为了创造更大的利润。关键在于管控权衡
    2. 何时可以启用新技术与架构?
      1. 对于不重要不紧急的产品
      2. 如果没有,就在组内做技术驱动的技术产品,比如团队网站,以此来打磨新技术或架构。然后选择一个恰当的时机在新项目里推行。
  1. 一边加班,一边吐槽,一边被吐槽。

满满的负能量,自以为嘴上爽了,你可知被你吐槽的人是怎样看待你?你又何曾把他看做是你团队里面的"自己人"?

  1. 走人了,换了个团队,问题依旧。

是的,当你带着抱怨离开这个团队,你可能会发现又跳进了另一个坑。
其实,也许你原本可以改变,但你选择了放弃。
当你能为团队做更多事,更多补位,那你的价值也就提升了。
"走"往往只是一种无奈的回避。

结语


团队问题当然还有很多,发现和解决每一个团队问题是每一个人的责任。
希望坚持看完以上文字的你,能与我互动。

推荐拓展阅读


打磨移动时代的前端团队(一)—— 迷局篇

推荐阅读更多精彩内容