返回 登录
0

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


(二)解题篇

只是个开始

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

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

看看你中枪了么

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

事不关己?

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

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

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

一起聊聊这个“问题堆”


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

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

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

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

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

      我喜欢后者 。 做到这些要求你觉得自己真的很有必要“懂业务”
      而你的这个选择使你成为了团队今天的骨干力量
  2. 需求改动频繁,排期总是被压缩。

    需求改动错了么?

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

      我想对A说: 大家需要的不是你的抱怨,而是你的“补位”。
  3. 总是缺人手,加班不断,且代码质量差。

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

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

    对于1, 暴露的问题在于内和外

    • 内: 对业务的增量没有充分预估,做好人力储备,或技术架构对人力内调不支持。
    • 外: 缺乏跨团队借调人力的能力。

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

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

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

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

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

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

              广告:我所在的团队把2,3的前后端分离解决方案,整合到了我们的工作流里面并做了开源,旨在为初创团队持续提供完整高效的前端工作流。它是一个gulp插件,名为 turbo
  5. UI过于纠结界面细节,导致交付时间不可控。

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

    1. 精益求精永远是没错的,但还是要从项目的紧急程度来看问题。好的FE需要一定的沟通能力。
    2. FE需要协同UI,UE 制定组件化视觉规范。
  6. 移动端,设备多,兼容问题多,导致自测时间不可控。

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

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

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

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

    其实架构也有很多当时的受限条件

    1. 业务规模
    2. 团队阶段
    3. 时代技术背景
    4. 架构师技术能力和视野

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

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

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

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

  • 结语


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

    TODO:(年后再见)


    打磨移动时代的前端团队(三)工程效率篇

    可以在 简书 关注我

    评论