前沿
我们是来自深圳阿里中心，ICBU体验技术部的前端艺术家团队（跨境供应链履约体验团队），至今已经成立将近6年，随着团队的不断壮大和技术产出，在集团内外已经有比较不错的影响力。【自夸一下：目前深圳阿里中心规模最大，最成熟的前端团队】那么我们这个团队是如何发展的呢？成长过程中遇到了哪些困难？如何一一破局？我将在这篇文章中通过回顾历史，横跨2015财年-2019财年的整个发展过程一一揭开面纱。
我们现在的办公环境
团队合影
开篇之前，我得先完成任务，嗯，你猜对了，我是来招人的，老板还要我做个海报 ，关键要快，要有创意！
想要加入我们的同学，记得联系我们： xuewei.lxw@alibaba-inc.com、chuanjie.mcj@alibaba-inc.com。
2015财年-徒手造飞机
现状
深圳一达通成立于2001年，起初主要为中小企业提供面向进出口流程的外包服务，核心业务内容包括通关、物流、外汇，退税、金融；2010.11 阿里开始控股，2014.4全资收购。
收购完成后，业务上的构想是阿里巴巴国际站(www.alibaba.com)与一达通(onetouch.alibaba.com)用户体系打通，上游阿里巴巴国际站提供企业间（B2B）国际贸易的平台，进行磋商营销、询盘问价、采购交易，下游一达通为中小企业提供一站式线下履约服务，包括通关、外汇、退税、物流、金融等外贸综合服务。从而实现阿里巴巴国际站与一达通的双赢，国际站沉淀了10多年的CGS客户，为一达通提供充足的客源，同时一达通完成线下服务流程，沉淀真实外贸交易数据，又可以反哺阿里巴巴国际站，构建卖买家信用体系。
团队
团队上也开始与阿里巴巴国际站做整合，早期由ICBU 杭州团队提供人力支持，外派三名P6同学驻扎在深圳办公，协助开发。也正是这时，开始慢慢组建深圳外综服前端团队，先后入职了4名同学支撑整个一达通的业务。
技术
技术上，当时老一达通的系统是由 ASP.NET 搭建的企业外贸ERP系统，日常宕机，需要一个人蹲在机房，重启服务器的状况都不是开玩笑的。因此我们便开启了阿里java为核心的webx MVC 架构的全站系统迁移之旅，前后端重构工作量都非常巨大，道路注定不会平凡。
不仅工作量巨大，整个技术团队的技术能力也参差不齐。除了几个内转和新社招的Java开发同学之外，大多数还是老一达通asp的技术团队。
由于团队构成复杂，在项目开展、团队文化等方面和阿里存在极大差异，老一达通系统的前端界面基本都是由后端同学套用模版开发出来的，根本不存在UI规范性，也不需要交互和视觉设计，大部分情况是能用即可。导致在重构过程中，很难让老同学重视前端的系统体验、架构合理性。当时前端技术栈选用的是基于 JQuery 的Atom组件和 Apollo体系的CSS布局方案，一起合称为Alpha组件体系。如下图所示：
外综服前端团队，从此便开启了血雨腥风、波澜壮阔的业务前端的徒手造飞机的探索之路。
办公条件
由于当时阿里在深圳还没有属于自己的园区，而是租了罗湖鸿昌广场的几层办公楼。老办公楼的条件比较落后，举个例子，每周整个产品技术团队都会过一两次全员的迭代review会议，大家只能在一个狭小、电话常无信号、排水不通的卫生间旁边，移动投屏，站立式快速的review，会议中时不时还能闻到卫生间的飘来“香味”。而且，当时很大部分新招进来的同学，都来自华为、腾讯等公司，主要住在宝安、南山等地区，每天上班路上来回3-4个小时，感觉人生很无望。
阿里人，最擅长的就是苦中作乐。在一个小小的休息区，摆上一个微型球桌，便开启了欢乐的第一届台球赛，后来这也变成了深圳团队每年少不了的节目。苦逼和激情诠释着阿里人认真生活，快乐工作的淡然。
2016财年-飞机开始起航
现状
2015财年主要做造机身的过程，初见轮廓。但业务发展非常迅速，4个人的前端团队，同时挂200个项目需求毫不夸张；再加上前面提到的，当时团队几位同学上班都比较遥远(路上来回3+小时)，天天不是在加班，就是在去加班的路上。
这个阶段，最直接的挑战是快速了解业务全貌、并在无数的项目需求中识别方向，进行重点突击；这样的场景下，常规策略是先接住踢过来的球，在紧急的项目面前，人力瓶颈问题，只能通过加班这种最直接最快速的方式去解决，下一步再逐步寻求突破，也即，通过工程效能和架构治理解决技术上面临的研发瓶颈的问题，其次才是逐步布局未来的事情，常规路径大概是下面这样的；
技术
技术上，适合当下的解决方案才是最可行的方案；当时开发模式就是传统一点的本地开发，通过teleport进行编译，workman进行资源构建，生成一个大包的独立静态资源文件供页面引用，由于组件重复依赖相同的内容，导致打包后的文件通常都非常大，一打开控制台浏览器就崩溃，于是有了老UI技术体系的一步一步的优化之路。自此这架飞机已经开始有一定规律地运转，并开始起航；
layout脱库，应用拆分
由于历史原因，当时经常需要做一些全系统、或者是所有页面都需要的更新和迭代，于是我们对系统页面抽象出了统一的layout包，可以很好地处理页面和站点的全局特性：
- 比如页面的性能、异常等质量监控，当时是全无的，项目上线后页面空白等异常问题，通常需要前线业务同学报过来才知道。通过独立layout的方案，可以很好地解决诸如此类的很多不确定情况下引发的问题；
- 再比如：希望对平台增加水印做安全防控，统一layout的代码之后，理论上只需要几分钟就可以完成了；
- 另外，前端可以更少关心通用的菜单、鉴权等问题，专注页面的快速开发；
由于前面提到的打包机制，要想layout分离，就必须在页面中再多引入一个layout的js、css文件，而每个前端资源都是单独构建的，如果含有相同依赖，便会重复打包相同内容到不同的目标文件，进而会导致样式覆盖等问题，因此我们采用layout脱库的方案进行解决。
同时为了快速响应业务，我们做了通用业务组件和页面逻辑代码的分离，并且按关务、税务、外汇、订单等不同业务域拆分成多个前端应用，减少开发过程的预发环境抢占、代码冲突等协作问题。
场景化策略
工程和架构上的问题一时解决不了，于是我们寻求了其他的研发效能的捷径。我们针对中后台系统，提出了标准化的场景设计方案：标准化每一个场景的研发代码，作为种子，上传到种子库，在进行新页面开发的时候，通过脚手架的一条命令，便可以从种子库中选取合适的场景代码种子，快速生成页面的骨干代码，前端同学只需要介入修改下业务逻辑代码即可进行联调，通过这种看起不是很高大上的方案，我们将一个需要3-5天开发工作量的页面缩短到了半天的时间。
我们的场景种子库如下图：
团队
以战养人，起初每天都坚持敏捷晨会，对事务进行快速review，努力先接住踢过来的球，有问题，几个同学一起讨论解决，通过每周周会的机制进行总结，过程中包括项目技术分享交流，业务结果复盘等。在顶住压力的同时，也可以看到大家的快速成长。团队也开始慢慢壮大。
2017财年-开着飞机换引擎
现状
在这一年，业务上期望实现规模double的目标，业务策略是释放顾问的服务工作量，引入拍档合作伙伴，撬动整个拍档周边的生态服务能力。采用拍档的形式，不仅可以很好的开展不同地区的本地化服务，还能利用生态的能力服务更多的客户，驱动更多的客户上行。
技术
webx mvc 分层架构的弊端
当时依旧采用的是Java体系下的MVC开发模式，为了解决View层的渲染问题，还可以引入velocity等支持模板页面渲染；
这里的问题主要暴漏在协同效率、项目质量方面：
- 协同效率方面：
- 开发环境重度依赖：前端开发需要依赖于后端环境的搭建，才能进行开发
- VM内容的开发效率低下：基本是前端先mock数据进行demo开发，最后再应用到VM
- 前端嵌套VM模板：前端同学不清楚Java提供的数据对象、变量等的具体信息。
- 后端嵌套VM模板：后端同学不熟悉前端模板层涉及到的UI实现，如事件绑定、css样式等内容
- 项目质量方面：
- 技术栈耦合引发质量问题：如静态资源版本管理、vm层中的dom结构调整等
- 技术规范难统一引发质量问题：如：接口数据结构（错误码、错误信息、grid通用查询）带来的异常体验、layout独立难复用导致菜单不统一。
同时也不利于前后端技术同学专业领域的发展，例如后端同学更期望通过提供底层微服务的形式，处理数据底层、业务逻辑方面的工作，而前端同学也期望能够收归前端技术栈的内容，合理架构页面路由、直出内容、用户交互等；在专业度、提效、性能、体验（比如：错误码、直出）、质量、安全等领域做得更好。
Node前后端分离
针对这一系列的问题，我们希望去掉VM层、实现前后端分离（在技术架构上完全解耦），前端技术上得出的终极解决方案是通过引入Node BFF层解决架构和协同的问题，同时，通过建立配套设施去解决对应的研发效能的问题；
于是开启了莫魔主导的Node前后端架构分层改造，又一场伤筋动骨的技术大战。
如果在新项目中，尝试用全新的技术方案去执行，其实是微不足道的；但对我们来说，最大的挑战是需要把各个系统的功能页面（总功能页面数大概5、600的样子）全部做迁移。更有挑战的是，这样的技术项目，从前端的弱势地位来看，是不能脱产业务项目，单独立项排期去做的，只能在团队同学支持业务项目之余，通过加班或者利用自己的业余时间去处理（一些同学甚至把春节在家的休息时间都安排进去了），整个过程无异于开着飞机换引擎。
2017财年底，我们顺利完成了拍档平台的架构升级，整个过程0故障，在服务性能、质量等指标上也取得了大幅度的提升，至此之后，杜绝了一达通过去老出现线上webx应用宕机或页面打不开的情况。
React中台DPL Fusion
UI这一层，当时还用的是最前面提到的基于jQuery的alpha组件体系，UI层受制于JQuery的传统实现方案，暴露了不少问题，而当时蚂蚁的antd在react圈子已经有了一些影响力，所以莫魔明确提出了react统一集团前端UI层的构想，也就是在这一年，ICBU 和 业务平台体验技术部 （原国际UED事业部） 开始共建中台DPL fusion；
团队
大概在财年结束的时候，一达通开始从深圳鸿昌广场搬迁到深圳阿里中心；心底里感到开心，终于不用乘坐摇摇欲坠的电梯，闻着“香味”的厕所开会，上下班来回折腾3个小时...
离开鸿昌广场之前，前后端同学留影
开心到飞起，提前来新园区骑行（那一年，共享单车刚火）
搬进新家，团队规模逐渐扩大
真正面朝大海编程
2018财年-飞向海外，EWTP
现状
这一年马云老师呼吁全世界建立一个e-WTP(电子世界贸易平台)平台，实现“全球买，全球卖”。而EWTP的第一站（马来西亚站），落地主体负责方正是一达通。在经过业务流程梳理和技术投入评估之后，第一轮评估下来整个项目要超过10000人日，想要实现最小链路也要3000人日左右，因为其中很大一部分工作量是需要推进整个java技术体系（很多java依赖的中台服务/中间件没有海外部署）的国际化部署。同时我们发现整个技术团队在国际化方面的经验不足，而且还受到阿里云和集团中间件在国际化场景的支持和推进节奏的影响，不确定因素很多，工作量极高，风险很大；
出差马来调研
技术
Node布局带来的突破
由于有了前期布局的node分层架构方案，技术经过多轮谈判，并经业务方认可之后，项目组达成一致，我们放弃了前后端全套设施都部署海外都方案，而是采用node接入层出海，通过专线的方式调用国内的java服务，来实现业务的快速响应，架构如下：
通过这套方案，java只需要像国内的普通应用一样开发即可，整体工作量控制到了1000人日以内，降低了10倍，前端只投入了一个全职两个兼职的同学在S1阶段就完成了项目上线；
这个方案，虽然专线性能延时属于业务完全可以接受范畴，但是跨国的场景必然增加了前端架构的复杂度，尤其是在问题排查上，因此，我们开始逐渐有了Node应用健康度，系统异常监控--扁鹊系统的原形（Node运行时日志可视化诊断平台）。
团队
这一年，我们逐渐开始尝试以开放的心态，将团队技术沉淀分享出去。推荐团队颜值的担当 米科 去开源中国分享《eWTP前端国际化技术架构》，收获了不错的评价。
第二年，我们在深圳阿里中心，筹办了第一届前端艺术家沙龙，打造团队的对外品牌--前端艺术家团队。
2019财年-飞向云霄，拥抱全云时代
现状
一达通升级跨境供应链
一达通全面转型跨境供应链，愿景是构筑外贸协同大平台。一达通业务 从3+N（关汇税）基础服务 升级到 报关saas、财税saas、物流saas等跨境供应链saas服务等形态。
技术
Node前后端分离的下一站
经过这几年的在node领域的摸爬滚打，我们也遇到Node前后端分离的技术瓶颈：
- Node端逻辑相比web端简单
- Node端开发由于需要占用前端开发资源，前端工作量有所上涨
- 前端开始需要关心更多领域问题:运维、服务端性能、水平鉴权
- 除了静态资源应⽤的构建、部署、发布，还多了一层node应用的部署、发布
针对第1、2两个问题，我们一开始尝试研发eggx脚手架的方式来解决，整个node层的开发基本实现了自动化或半自动化，工作量有所下降。
这一年，serverless的概念风生水起，我们开始探索Node BFF的下一站，希望通过serverless的动态扩缩容来抹掉前端的运维层。但纯faas的颗粒度太小，并不适合我们的业务场景，而且我们团队在node领域经过这两年的实践，应用数量规模也已经比较大了，需要探索一条更轻量的迁移方案，这时樵枫 提出了eaas(egg as a service) 方案。
同时，我们针对Node逻辑controller层无法实现自动化的部分，做了进一步探索，发现这部分代码基本套路就是参数预处理->服务调用->结果处理，于是我们推出陆游平台（Node层逻辑可视化编排&代码热更新平台），更多详细内容，请查看《Node接入层可视化逻辑编排，还可以这样做？》
这些年，我们除了在Node领域持续深挖，在B类中后台场景，也在一直探索更好用、更快速搭建列表、表单、详情等页面的解决方案，产出了Formily/Alist等开源方案。
质量保障方面，我们负责F2ETest（多浏览器兼容性测试方案）、UI-Recorder（UI录制自动化测试方案）等知名开源项目。
团队
团队逐渐扩大的同时，幸福感也越来越强烈，阿里18周年和20周年，深圳前端团队大部分同学都被抽中到现场参会，只有@峻爷 连续两次未抽中，手动抱抱表示安慰。
未来-冲出云霄，探索星辰
ICBU前端合影
伟大领袖樵枫曾经说过“阿里巴巴国际站是上半身，跨境供应链是下半身，只有上半身和下半身扭动起来，才能创造更大的价值。”
构筑外贸大协同平台，未来已来。欢迎有情有义的您加入我们深圳大家庭，拓展更多引领前端技术持续发展的疆土。
记得联系我们： xuewei.lxw@alibaba-inc.com、chuanjie.mcj@alibaba-inc.com
