欢迎来到深圳市来科信科技有限公司网站!
您当前的位置:深圳APP开发 > 新闻资讯 > APP开发资讯 >

已阅读

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

来源:lexintech.com       发布时间:2017-08-24
在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 的成本还不如直接实现……熟悉业务后,这样的场景总是容易发现的。
 
网站开发 APP开发 产品设计 微信公众号 用户体验 APP开发公司 APP运营 微信小程序 产品经理 网站设计