打磨移动时代的前端团队（二）—— 解题篇
（二）解题篇
只是个开始
此篇名为“解题”，如果您真希望通过看一篇帖子就能解决团队所有问题，那么我要让您失望了， 因为此篇并非问题的终结，而是开始。
前端团队究竟遇到了什么问题？
看看你中枪了么
- 项目之初，需求不明，死线（dead line）已定。
- 需求改动频繁，排期总是被压缩。
- 总是缺人手，加班不断，且代码质量差。
- 前后端联调环境搭建耗时，且定位问题麻烦，导致联调时间不可控。
- UI过于纠结界面细节，导致交付时间不可控。
- 移动端，设备多，兼容问题多，导致自测时间不可控。
- 领导说，PM说，UI说，UE说。信息不对等，到底听谁说？
- 基于历史原因，总是无法采用更恰当的技术方案，导致团队技术脱节。
- 一边加班，一边吐槽，一边被吐槽。
- 走人了，换了个团队，问题依旧。
事不关己？
无论你是否关心以上的问题，我想说的是，我们的技术水平来源于自己的精力分配，而我们的精力分配又受限于团队任务分配，所以，每个看似是Leader的问题，其实你我都需要对自己负责。
当我说“提高前端生产力”时，我在说些什么？
从上面的“问题堆”看到，阻碍我们项目交付的，不只是技术，这些非技术的问题更要命。
** 一起聊聊这个“问题堆” **
为了方便举例，我假设存在A ，B两类开发者
- 项目之初，需求不明，死线（dead line）已定
但凡有过一些工作经验的开发者，都能接受这个“残酷的事实”。
因为他们懂得站在更高层次看待这个问题。
开发的目的有时候是为了抢占市场，所以时间点往往至关重要。
- 接手此类项目的开发者有两种心态:
A. "压力山大"，立刻开始设计、编码。
B. "压力山大，谋定而后动", 基于业务，权衡利弊，发现风险，积极沟通，设计方案而后动。
我喜欢后者 。 做到这些要求你觉得自己真的很有必要“懂业务”。
而你的这个选择使你成为了团队今天的骨干力量。
- 需求改动频繁，排期总是被压缩。
需求改动错了么？
- 需求变更通常有三种原因：
- 源于竞争态势的变化，战略的快速调整。
- 敏捷的产品开发实践，小步快跑，渐进明细。
- 产品设计人员没有想清楚。
- 情况1,2 无可厚非，拥抱变化不变的真理。敏捷开发的核心，就是拥抱变化。
- 情况3，我想替产品开发人员（PM）说句话。
每一个产品的成败不只是取决于PM，团队中的所有人都是参与者，都要对结果负责。 - 当面对一个经常变更需求的PM
- A.只会抱怨"这个PM不给力"
- B.眼光放在项目目标，思考自己能做些什么。
我想对A说: 大家需要的不是你的抱怨，而是你的“补位”。
- 总是缺人手，加班不断，且代码质量差。
缺人手其实是个相对概念。
- 项目确实过于紧急，基于目前的人数，无论什么样的开发者都会吃不消。
- 业务频率正常，团队生产力低下
对于1, 暴露的问题在于内和外
* 内： 对业务的增量没有充分预估，做好人力储备，或技术架构对人力内调不支持。
* 外： 缺乏跨团队借调人力的能力。
对于2，需要定位原因，是前端团队自身工作流问题，还是与其它团队配合问题。分而治之。此时最好不要再抱怨“缺人手”，以免更加被人“不看好”。
** 代码质量问题 ** ：我不觉得代码质量总是第一位的。代码的价值应该体现在每一次项目的成功交付。在遵守模块化开发的前提下，烂代码是可以在后续以模块的规模整体替换的。我能接受以低质量代码换取每一次迭代的快速响应。成熟团队会对重点项目进行codeReview或结对编程或推行TDD，逐步优化代码质量。
- 前后端联调环境搭建耗时，且定位问题麻烦，导致联调时间不可控。
解决之道是“前后端分离” ，目前主流有三种做法，这取决于团队背景、前端的技术力量以及团队技术总负责人的技术选型。
** 前后端分离的技术方案：**
- 前端团队掌控线上Http Server，负责View层的拼装，以及少量展现逻辑。数据在http Server端与传统后端在同一机房的网络环境下通过接口交换数据。
* 好处：
1. 后端不关心view层只做数据接口。
1. 对SEO支持交给更加了解SEO的前端负责。
1. 可以做诸如react服务端同构的技术方案(阿里已经有了最佳实践)。
* 弊端：
1. 前端通常缺乏运维经验，线上服务崩溃风险高。
1. 上线变得更加复杂。
- 前端团队不触碰服务端事务。通过给后端提供初始化数据+demo html页的形式进行分离。
* 好处:
1. 后端只需要copy前端demo源码构建view层
1. 后端只做数据接口（同步接口，异步接口）
* 弊端：
1. 后端还是需要随时根据HTML demo的变化，重新构建view
1. 后端需要管理静态资源版本
- 把html放在CDN上，静态资源版本完全由前端控制，后端只做接口。
- 好处：
- 前后端完全分离
- 弊端：
- 后端很难做session，所有的cookies都需要前端判定，并不适合所有页面。
- 好处：
广告：我所在的团队把2，3的前后端分离解决方案，整合到了我们的工作流里面并做了开源，旨在为初创团队持续提供完整高效的前端工作流。它是一个gulp插件，名为 turbo
- UI过于纠结界面细节，导致交付时间不可控。
一个FE,没被UI的“像素眼”盯过,那么他的FE生涯将是不完整的。
-
精益求精永远是没错的，但还是要从项目的紧急程度来看问题。好的FE需要一定的沟通能力。
-
FE需要协同UI，UE 制定组件化视觉规范。
-
移动端，设备多，兼容问题多，导致自测时间不可控。
移动时代虽然让FE脱离了恼人的各种IE，却又带来了更多的平台的兼容问题。我们希望通过一个个可复用，经过测试的组件来减少日常开发的跨终端的测试。
试想，如果每次开发，80%以上的模块都是复用可靠且兼容的组件开发，那么这些兼容性问题，将会随着组件库的丰富，越来越少。
- 领导说，PM说，UI说，UE说。信息不对等，到底听谁说？
毫无疑问，无论“是谁说”，最后都得听领导的，别问我为什么！
（但又不能事事都问领导，轻重请自行把握）
-
唯一项目负责人原则：
- 由于FE对接的层面很多，包括 PM，UE, UI，RD ,如果收到每个角色的反馈，就立即动手，后果可想而知，一个FE会不会工作，由此可鉴。
- 我推荐“唯一项目负责人”原则，FE依赖的资源都需要这个负责人审核并给出，包括MRD，UI，UE，接口文档（接口文档与RD的后续沟通可以脱离项目负责人）,可有效避免信息不对等。 如果有项目经理最好，没有项目经理 默认是 产品经理（PM）
-
基于历史原因，总是无法采用更恰当的技术方案，导致团队技术脱节。
其实架构也有很多当时的受限条件
1. 业务规模
1. 团队阶段
1. 时代技术背景
1. 架构师技术能力和视野
- 要解决这个问题，首先我们必须承认，根本不存在完美的技术方案和架构。我们需要拥抱变化，为向未来的技术和架构过渡做好准备。
-
渐进式架构与技术债务
- 基于团队的不同形态设计适合不同阶段的架构与技术堆栈。同时，需要以开放的心态看待 "技术债务"，就像我们通常不喜欢欠债，但有时候贷款也是为了创造更大的利润。关键在于管控和权衡。
-
何时可以启用新技术与架构？
- 对于不重要不紧急的产品
- 如果没有，就在组内做技术驱动的技术产品，比如团队网站，以此来打磨新技术或架构。然后选择一个恰当的时机在新项目里推行。
- 一边加班，一边吐槽，一边被吐槽。
满满的负能量，自以为嘴上爽了，你可知被你吐槽的人是怎样看待你？你又何曾把他看做是你团队里面的"自己人"?
- 走人了，换了个团队，问题依旧。
是的，当你带着抱怨离开这个团队，你可能会发现又跳进了另一个坑。
其实，也许你原本可以改变，但你选择了放弃。
当你能为团队做更多事，更多补位，那你的价值也就提升了。
而"走"往往只是一种无奈的回避。
结语
团队问题当然还有很多，发现和解决每一个团队问题是每一个人的责任。
希望坚持看完以上文字的你，能与我互动。
TODO：（年后再见）
打磨移动时代的前端团队（三）工程效率篇
