打磨移动时代的前端团队（二）—

本文链接：https://blog.csdn.net/qq_32245163/article/details/80121682

（二）解题篇

只是个开始

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

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

看看你中枪了么

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

事不关己？

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

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

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

一起聊聊这个“问题堆”

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

项目之初，需求不明，死线（dead line）已定
但凡有过一些工作经验的开发者，都能接受这个“残酷的事实”。
因为他们懂得站在更高层次看待这个问题。

开发的目的有时候是为了抢占市场，所以时间点往往至关重要。
- 接手此类项目的开发者有两种心态:
  A. “压力山大”，立刻开始设计、编码。
  B. “压力山大，谋定而后动”, 基于业务，权衡利弊，发现风险，积极沟通，设计方案而后动。
  
  我喜欢后者。做到这些要求你觉得自己真的很有必要“懂业务”。
  而你的这个选择使你成为了团队今天的骨干力量。
需求改动频繁，排期总是被压缩。
需求改动错了么？
- 需求变更通常有三种原因：
  1. 源于竞争态势的变化，战略的快速调整。
  2. 敏捷的产品开发实践，小步快跑，渐进明细。
  3. 产品设计人员没有想清楚。
- 情况1,2 无可厚非，拥抱变化不变的真理。敏捷开发的核心，就是拥抱变化。
- 情况3，我想替产品开发人员（PM）说句话。
  每一个产品的成败不只是取决于PM，团队中的所有人都是参与者，都要对结果负责。
- 当面对一个经常变更需求的PM
- A.只会抱怨”这个PM不给力”
- B.眼光放在项目目标，思考自己能做些什么。
  
  我想对A说: 大家需要的不是你的抱怨，而是你的“补位”。
总是缺人手，加班不断，且代码质量差。
缺人手其实是个相对概念。
1. 项目确实过于紧急，基于目前的人数，无论什么样的开发者都会吃不消。
2. 业务频率正常，团队生产力低下
对于1, 暴露的问题在于内和外
- 内：对业务的增量没有充分预估，做好人力储备，或技术架构对人力内调不支持。
- 外：缺乏跨团队借调人力的能力。
  
  对于2，需要定位原因，是前端团队自身工作流问题，还是与其它团队配合问题。分而治之。此时最好不要再抱怨“缺人手”，以免更加被人“不看好”。
* 代码质量问题 * ：我不觉得代码质量总是第一位的。代码的价值应该体现在每一次项目的成功交付。在遵守模块化开发的前提下，烂代码是可以在后续以模块的规模整体替换的。我能接受以低质量代码换取每一次迭代的快速响应。成熟团队会对重点项目进行codeReview或结对编程或推行TDD，逐步优化代码质量。
前后端联调环境搭建耗时，且定位问题麻烦，导致联调时间不可控。
解决之道是“前后端分离” ，目前主流有三种做法，这取决于团队背景、前端的技术力量以及团队技术总负责人的技术选型。

* 前后端分离的技术方案：*
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上，静态资源版本完全由前端控制，后端只做接口。
      
      好处：
      
      前后端完全分离
      弊端：
      
      后端很难做session，所有的cookies都需要前端判定，并不适合所有页面。
      
      广告：我所在的团队把2，3的前后端分离解决方案，整合到了我们的工作流里面并做了开源，旨在为初创团队持续提供完整高效的前端工作流。它是一个gulp插件，名为 turbo
UI过于纠结界面细节，导致交付时间不可控。

一个FE,没被UI的“像素眼”盯过,那么他的FE生涯将是不完整的。
1. 精益求精永远是没错的，但还是要从项目的紧急程度来看问题。好的FE需要一定的沟通能力。
2. FE需要协同UI，UE 制定组件化视觉规范。
移动端，设备多，兼容问题多，导致自测时间不可控。

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

毫无疑问，无论“是谁说”，最后都得听领导的，别问我为什么！
（但又不能事事都问领导，轻重请自行把握）
1. 唯一项目负责人原则：
  1. 由于FE对接的层面很多，包括 PM，UE, UI，RD ,如果收到每个角色的反馈，就立即动手，后果可想而知，一个FE会不会工作，由此可鉴。
  2. 我推荐“唯一项目负责人”原则，FE依赖的资源都需要这个负责人审核并给出，包括MRD，UI，UE，接口文档（接口文档与RD的后续沟通可以脱离项目负责人）,可有效避免信息不对等。如果有项目经理最好，没有项目经理默认是产品经理（PM）
基于历史原因，总是无法采用更恰当的技术方案，导致团队技术脱节。
其实架构也有很多当时的受限条件
1. 业务规模
2. 团队阶段
3. 时代技术背景
4. 架构师技术能力和视野
- 要解决这个问题，首先我们必须承认，根本不存在完美的技术方案和架构。我们需要拥抱变化，为向未来的技术和架构过渡做好准备。
- 渐进式架构与技术债务
  1. 基于团队的不同形态设计适合不同阶段的架构与技术堆栈。同时，需要以开放的心态看待 “技术债务”，就像我们通常不喜欢欠债，但有时候贷款也是为了创造更大的利润。关键在于管控和权衡。
  2. 何时可以启用新技术与架构？
  3. 对于不重要不紧急的产品
  4. 如果没有，就在组内做技术驱动的技术产品，比如团队网站，以此来打磨新技术或架构。然后选择一个恰当的时机在新项目里推行。