APP开发公司的前端团队如何技术积累？

在APP开发公司中，前端是必不可缺的岗位。有的深圳APP开发公司比较重视前端设计，前端团队实力还是比较强的。乐信科技lexintech就是一家注重产品设计的深圳APP开发公司。下面乐信小编跟大家聊一聊前端团队如何进行技术积累。

前端是个挺特别的岗位，一方面它的技术栈更新几乎是软件开发领域中最快的，但另一方面它的不可替代性相对而言却并不算高。并且，虽然多数APP开发公司都有相对独立的前端团队，但团队多半都有不少业务负担，加上前端较高的迭代速度，一线业务同学的成长多少容易遇到些瓶颈：需求都做不完了，还有时间读源码解析吗？

 

其实我们都知道，个人成长和团队成长是分不开的。一方面在技术氛围较好的团队中个人的进步会更快，另一方面团队的技术积累也是由一个个成员们贡献出来的。这就引出了我们的问题：在业务团队中，有什么方法能让个人和团队在迭代中都得到更好的成长呢？

 

能想到最简单的答案应该就是「定期技术分享」和「不加班，给大家更多的学习时间」这样的吧。不只是前端，相信这肯定也是广大开发同学们喜闻乐见的。可惜业务压力摆在那里，如果个人学习影响了短期内的团队产出，那么老板们的脸色也许会有些微妙……从另一个角度上来说，前端同学提升技能水平所需学习的各种模式、框架、类库、工具，在开源社区都有非常详尽的文档和教程，如何提升个人能力的话题也更不是本文所能覆盖的。不过，如果一个前端团队能够通过一些技术层面上的方式，培养出由团队成员共建的良好技术基础的话，相信老板们和开发同学们都可以接受吧。这其实也正是本文所关注的。

 

在介绍「怎么做」之前，我们不妨考虑下「做什么」，即在什么方向上去培养技术积累呢？

 

我们知道 Full Stack Developer 的概念一直很火，那么按照 Full Stack 的概念，前端团队的所需的技术积累是怎样的呢？这意味着前端团队需要横向地扩展自己的能力，拉通 DB 到 HTML 的流程。技术栈覆盖面广自然是好事，可是为什么还是经常能够听见对全栈的争议呢？

 

在很多需要快速迭代实现原型的场合，这样的能力模型是很合适的。问题在于在一个系统的开发中，多数情况下团队成员负责开发的是独立的模块。而按照信息隐藏的理念，而只有在代码模块采用定义良好的接口来封装，模块的内部结构对外部不可见，复杂度被屏蔽而非暴露在他人模块内部结构前的时候，开发的效率才是最高的，也并不是团队中所有成员都需要了解系统整体的技术细节。并且，前端本身也是对开发职能分工的细化，在后端有成熟稳定团队的前提下，前端在团队层面按照 Full Stack 的方向积累技术，在投入和产出上未必是最优的。当然，这和许多大厂「只招全栈」的理念并不矛盾，毕竟在个人开发者层面的全栈所真正要求的并不是杂而全，而是高效地解决各类问题的学习能力，以及对技术更加全面的深入。

 

这种模式下，前端的职责并不仅仅局限在传统的客户端 HTML + CSS + JS 中，而是一系列与用户交互相关的技术合集。这个背景下，可以把前端团队理解为一个垂直的功能性的团队，技术积累上也是更多地围绕着我们所面对的业务问题去做沉淀。套用《人月神话》里外科手术式团队的概念，如果说全栈的角色更接近于全能的「外科医生」的话，那么 Full Life Cycle Engineer 则更接近于纵向深入的「代码专家」。

 

围绕着这个理念展开，不难发现许多技术点是在团队层面上可以去做积累的。那么是否有必要去积累团队内部的轮子，又在什么方向去做呢？

 

这其实视团队情况不同，是非常业务驱动的。比如，维护 C 端产品的团队，可能更需要性能优化、监测告警方向的轮子，而开发 B 端中后台产品的团队，对状态管理、统一组件库一类的轮子需求度则会更高。在深入业务的过程中，几乎总能找到特定的场景能够抽取出特定的复用模块，或找到适合针对性优化的地方，这其实就相当于技术积累的起点了：在业务驱动下开始造（甚至发明）团队内部的轮子。其实造轮子对技术积累的促进，并不仅仅体现在实现轮子这件事本身。比如，即便是一个非常简单的 UI 按钮，在将它实现为可复用的代码时，所需要做出的工程化努力都可以是很深度的。比如，即便一开始只在团队内部使用，API 设计得简单没有关系，但作为一个可复用的模块，怎么样让使用者不需要读源码就能用呢？这时候我们需要最基本的文档；怎么样保证升级后 API 稳定呢？这时候单元测试就体现出了意义；发布为模块的话，样式怎样和组件一起提供呢？这时候需要的是构建流程……这些和基本业务逻辑并不直接相关的工程化内容，即便只是开发出一个简单的内部轮子时都可以渐进地去考虑和实现。并且，这些工程化的特性也正是做技术积累的良好切入点。

 

如果编写的代码都是不需要复用的「一次性」代码，那么文档就是多余的；如果实现 UI 逻辑只是为了满足基本的业务需要，那么实际上是没有什么机会和必要去将单元测试落地的；如果最终打出的包始终只是面向用户而非面向开发者，那么甚至也不需要考虑 dependency 和 devDependency 的区别…工作内容限制在一个狭窄的子集内的时候，成长显然是会受限的。

 

当然，以上引入的工程化特性客观上都需要时间投入，也不免会有重复造轮子浪费人力之嫌。这时如何去做权衡和取舍呢？

 

我们不妨评估一下引入新轮子的投入和产出。比如，分析一个没有积累公共组件或依赖第三方组件库的团队，是否有开源项目中未能提供的 UI 组件，这些组件是否有复用的可能性和条件呢？如果有的话，引入工程化的发布流程会带来多少时间成本，是否能够方便其他同学在后续的使用中节约回来呢？再比如，是否存在业务场景是现有的开源轮子不能完全符合需求的？如果自己动手，能够收获多少易用性或性能上的提升呢？毕竟造轮子也是工程，而工程问题总是可以评估、分析和 Tradeoff 的。

 

实际上，前端领域中，由于业务场景的多样性，开源轮子不能完全匹配实际需求的情况是很常见的。比如，Redux 是个用来支持复杂应用的状态管理库，在增查改删的后台应用中使用起来十分沉重；实现不需考虑兼容的简单页面时，自己封装出的简单 DOM 操作库肯定比 jQuery 或 Zepto 更加轻量；封装登录认证库时如果全部交互都通过 JSONP，那么依赖 fetch polyfill 或 axios 的成本还不如直接实现……熟悉业务后，这样的场景总是容易发现的。