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

---

（二）解题篇

只是个开始

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

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

看看你中枪了么

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. 走人了，换了个团队，问题依旧。

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

结语

---

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

TODO：（年后再见）

---

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

推荐拓展阅读

---

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