技术人生就是在不断地修行，每个人都有每个人的功课，每个人也有每个人的精彩。你也许刚上路，又或许踽踽独行了很久，听听别人的故事没准也能帮助自己的成长。在阿里修行的9年，他学会了这些。

少年励志，初入技术圈

我生在一个文化气息浓厚的家庭，这让我从小就对艺术有了一种懵懂的向往。第一次接触到计算机时，我就明白自己会在这个领域玩下去；第一次接触到互联网时，我就坚定了将其作为事业，把自己的黄金年龄投入其中的信念。文化气息的熏陶和坚定的信念，使得我踏上了寻找将美好的设计感和互联网技术相结合的长路上。

2004年，我在上海毕业后，加入了COSCO。当时的环境有很好的应用场景和很牛的前辈，我在这个时期接触到了一种可以被叫做前端的职业，接触到了这个把「人的情感设计」和「技术的实现」连接在一起的令人兴奋的事情，而这恰恰就是我当初最希望做的事情，于是毫不犹豫的将其作为自己立足的根本。除了找到自己的定位，我在这里收益最大的是快速学习并建立了自己的职场价值观。

后来，我赶上了第二波互联网浪潮。我不是那种希望很早就进入退休状态的人，所以在2007年，我毅然决然地投身到 Web 2.0 的创业过程中。半年的时间，我们创业的产品就在当时的社区中具备了一定的知名度。这短短的半年时间，让我在技术、设计、产品、用户等方面都有了不错的知识积累。

2008年，我们三个技术人的创业进入到了瓶颈期，我也明白了自己需要进一步学习的有哪些。此时，机缘巧合，我以一个普通的前端工程师的身份加入了阿里巴巴。

阿里九年，我所到达的四个站点

时光如梭，一晃眼，我加入阿里巴巴已快9年，这9年中，我经历了4个重要的阶段。

第一站：UED团队前端工程师

开始2年，我在UED团队。作为一线的前端工程师，我参与了UED深度进入产品，强烈追求业务结果的发展时期。这为我深深地打下了用数据从用户行为路径的角度优化产品的思路。这使得我从进入前端正规军的第一站开始，就有了一个需要站在比前端职责更大的角度去考虑如何工作的环境。这是我职业顺利发展最为关键的因素。这个阶段，我专注的领域在性能和体验优化上。

第二站：UED团队前端团队Leader

2010年，由于所在UED团队的调整，我成为了前端团队的Leader。在此阶段，我参加了AliExpress的初创团队建设，又回归到国际事业部。在负责了整个UED团队管理一年后，我又回归到前端团队，同时也把前端团队带进了技术团队。这个阶段，让我明白了前端这个角色的本心和这个阶段所需要的环境，使得我心中的前端开始与技术团队形成连线。

第三站：阿里巴巴企业事业群(B2B)的前端团队Leader

2014年，随着团队的规模进一步扩大，我开始负责阿里巴巴企业事业群(B2B)的前端团队，主要的职责是事业群下的前端团队的整合和技术的收拢。这使得我必须在更大、更复杂的环境下，来看待前端团队的定位。这个阶段，让我有机会思考企业架构下前端的价值和定位。

第四站：B类电商体验技术中台团队Leader

2016年，在承接集团中台建设的战略后，我思考清楚并开始实践研发中台的建设，并略有成效。在中台急切的落地的期待下，我加入到B类电商中台团队，进入到了当前的第四站，负责体验技术中台团队。现在，我更多关注的课题是：如何在成熟的系统中去做收敛和统一，并为将来留下灵活性。当然，我依旧是从前端的角度切入。

我所经历的B类电商平台前端架构演进

我不敢妄言整个互联网电商平台的前端架构，因为没有全部经历过。但我在阿里巴巴B2B电商平台的这段经历，使得我有立场说一说B类电商平台的前端架构演进。架构和业务的发展有密不可分的关系，下面我将结合业务发展阶段对应的谈前端架构在当下环境的特点和时间线上的演进。

「信息透出，促成双方会面」阶段

在电商平台还在「信息透出，促成双方会面」阶段的时候，业务的主要特征是以 搜索 / 导购 作为主线，用户链路以在线沟通意向为终点。业务模式很简单，抽象起来就是用户提供信息，电商平台展示信息，协助买卖方在线沟通。在这个阶段，前端的架构视角的关键词是： 继承式代码复用，加载期性能治理。

继承式代码复用一般遵循着： 基础框架 / 运行时; 组件基类; 基础组件父类; 业务组件实例这样的一个技术架构模型上。而在工程架构上的特点是： 覆盖式发布 (含中美同步); 基本依赖管理; 性能治理 (压缩，去重合并，监控)。

大家会发现，这个阶段考虑的都是通用性问题。抛去电商的业务因素，可以发现这是个放之哪里都能用的架构，解决前端自身在研发过程中的问题占了绝对比重。

「在线交易达成」的阶段

在电商平台进入到「在线交易达成」的阶段时，业务的主要特征就是：开始期望用户把围绕着交易的所有事务工作在线化；业务场景在之前的基础上新纳入各种复杂的用户端信息管理(交易流程、纠纷流程、生意关系管理等)；用户在平台上需要完成的操作开始变得更多，使得人机交互场景变得更频繁且有更高体验要求。另外，多人协同研发的局势也越来越明显。在这个阶段，前端的架构视角的关键词是： 模块化管理，前后端分层，执行期性能治理。

这个阶段，应用场景出现了频繁的数据交换需求，从而开始注重前后端的通信管理以及工作解耦，从而探索前后端的分层架构; 模块化管理的进入引入了模块管理器(离线/在线); 发布前构建，从而引入工程链的体系。因为开发环节的进一步复杂，对于质量治理，线上线下监控告警等都开始有意识的进一步完善。

大家还是会发现，该阶段考虑的虽然还是属于通用性问题，而解决的问题已经逐渐进入到大型复杂协同模式下需要面对的问题了，慢慢从框架之争进入到了如何更好的组织代码以及探索前端职责边界。

电商平台进入真正的平台化阶段

在电商平台进入真正的平台化，需要在目前的基础上快速接入第三方服务(海关，税务，银行)，快速建设垂直市场(垂直行业市场，封闭市场，大企业采购市场等)，需要考虑的是如何解决大量不可预知的差异化的承接问题，这个问题已经需要站在整体企业架构中才能去尝试解决的了。在这个阶段，前端的架构视角的关键词是：设计解构、逻辑调度、应用模型、分层标准化。

随着业务的多样性发展，整体架构的服务治理工作的开展以及人力紧张状态的持续，我们需要进一步的去识别研发过程中能够被进一步抽象和标准化的部分，并将变化的部分通过可配置、可编排的方式提供灵活的服务，并赋予业务实施的过程；需要进一步强化和明确在系统架构和信息架构间前端的转化工作。

该阶段考虑的部分逐渐破开前端的固有视角，开始从业务特征的视角，从数据消费者的视角，从用科学方法来解构专业的视角，来建设前端的能力。同时，也开始从前端自身的开发架构慢慢转变到有一定业务特征的应用架构。

我看大型企业级架构前端分层

分层目的

分层的目的从根本上说有两点：

这两点最终都能够反应到效率上：一个效率点是瀑布式开发转变成并行基于接口的开发，缩短开发任务路径；另一个效率点是在面对业务调整时，降低复杂度的分层系统具备更强的灵活性，从而提升整个系统的响应效率。另外，分层对稳定性也有一定意义的帮助，基于层的测试能够做的更加纯粹和有针对性。同时，接口调用性能监控和全链路的性能监控在其中非常关键，用来做因为分层带来的额外性能开销可能存在风险的监控。

主流模型

主流的模型有两种：

那么，应用模型数据聚合(为UI提供数据)和服务端渲染用什么实现呢？客户端在承担越来越多职责的情况下会进一步的引起思考，一些计算任务放置到服务端会更合适; 而业务领域模型的数据无法直接有效的对UI服务，需要有一层来处理数据消费者视角的数据加工工作。结合「同构」的意义，我们会发现JavaScript有了更大的应用场景。而我的观点是JavaScript的运行时有了更大的应用场景，故不论是Node.js、Nashorn(甚至以前的Rhino)，亦或是直接使用V8都是可以做到我们想要做的事情，而让JavaScript跑在服务端之外，整件事更应该关注的是稳定性，容灾容错，弹性，监控告警这些我们现在还有些陌生的领域。选型这件事不是语言偏好和角色之争，而是系统应该做成什么状态的思考。

分层通用原则

分层的通用原则有：

分层架构通过将事务处理的分层来分化系统的复杂性，提高系统的可扩展和可维护性。但同时因为分层事务处理导致需要在多个层间传递能力，会导致性能的损耗。目前谈论的前端分层主要是集中在 presentation layer 和 business layer中的一部分。“每一层功能的接口定义与接口实现分离，对该层的访问只能通过接口”，这个原则对前端的分层同样有很强的指导意义，太多的不兼容底层框架升级导致业务实施有太多的额外成本开销。这个恰恰是分层架构给我们前端在本职工作上需要的更多思考。

国际化站点的前端业务的特点

国际化站点的业务对于前端而言，最显而易见的第一个问题是国际化部署; 然后是内容的国际化管理; 再往后是目前还在尝试中的本地化。国际化部署对于前端而言不仅仅是把资源文件同步分发到全球各地机房就结束了的，源站和全球CDN中就有非常多的治理工作，比如CDN预热、热区规划、缓存版本管理等; 而且资源文件和应用的发布在全球化发布过程中会被无限放大发布时间差的问题，应用的跨版本平滑发布，配置和文件幂等检测等。

内容的国际化管理，首先是语种的国际化管理、用集中式键值对管理、热部署、页面内容识别等方法解决常用的应用中XML资源文件式的管理存在的管理困难，分散在应用中而带来的冗余，发布困难，多语种应用定位等问题; 其次是类似 “单位 / 日期 / 货币 / 姓名格式” 等更精细化的国际化差异系统级管理。当然这里还有些挺特殊的例子，比如阿拉伯语、希伯来语的从右到左书写方式。本地化(localization)区别于国际化(international)，更注重在本土文化的差异性上，目前还在探索。

我看大型企业中前端团队的管理

关于团队管理的问题，没有正确答案。组织结构是在承接战略而灵活变动的，而其中的优劣也是相对而言。作为管理者，需要解决的恰恰是享受了优势之后随之而来的问题，因为任何问题都会成对出现。例如，是否应当将前端的同学合拢在一个团队呢？我们可以从专业建设、视角和组织灵活性来分析一下。

专业建设

视角

组织灵活性

不论以哪种方式来组织前端的同学，都需要让组织更加灵活，相应的关键因素有两个：

这里统一的技术基础和一致的角色价值认知，一实一虚，对应着技术的基础和角色的文化：

前端群体发展方向：「云」和「端」。

「泛前端」或「大前端」的概念喊了很多年了，我认同这两个词，但有一些我自己的逻辑。前端当初出现的原因是「人机交互体验」，用什么技术用什么语言去实现这个人机交互过程并不关键，但理念和目标应该是一致的，甚至在整个知识树中，可能除了不同的端、不同语言、不同端交互的特征之外，基本知识结构上不会相差太多，甚至有差异性的地方还有很好的互相借鉴意义。

在企业中，前端的合作伙伴有非常多。理论上，作为前端个体而言，转型成任何一种角色都挺正常。但对于一个群体而言，我认为在大纬度上会有两种方向——「云」和「端」。

• 「端」容易理解，在各个端，利用各种技术，完成业务产品中的数据消费，信息架构，人机交互的工作(PC、无线、VR、AR等)。
  
• 「云」不是通常意义的云计算，而是借云计算和云开发者之间的关系类比一下，这里指「端」开发者在完成业务产品时所需要的基础研发能力以及产品的能力的提供者。
  

前端工程师发展建议：思辨、容纳和好奇心

我们的前端生态很活跃，这让我的心理挺矛盾的。我一方面高兴，是因为活跃的社区才能充满创造力，而前端又极端的需要创造力。另一方面我又担心，是因为在活跃的社区中，明天就有可能天翻地覆，谁都不知道我今天选择的是不是代表未来，有那么点赌博的味道；而且频繁的调整业务实现方式，困扰的不只是前端自己。

上文曾提到，我们通过分层架构，尝试从技术上解决前端技术体系的频繁变动而导致临近技术体系需要被动调整的问题。除了技术上的应对，前端人或甚至说技术人想在这样的环境中成长，应以什么样的心态来应对呢？我有三个建议：思辨、容纳和好奇心。

思辨

社区的活跃中，有语言的进步，有工具的进步。语言是你决定成为前端之后的首先需要牢牢关注的基石，如果有精力，应该关注语言的进步背后的推动力，这是能够让你一定意义上拥有以不变应万变的能力。工具是你在目前的社区上，在工作中最常谈论最常用上，它们具备一定的通用性，看上去能解决所有人的某些问题，但也更容易被革新。这部分需要关注，因为这是你能更好解决问题的方法，但不要过于沉迷于工具，随着技术的发展，面对问题域的进一步复杂化，甚至其他工具的发展，新的工具会源源不断的被发明，旧的工具一样会周而复始的被抛弃，这个生命周期是一定存在的。

容纳

所有在社区中出现的东西，都是为了解决它所在的场景中的问题而诞生的，存在即合理在这个语境下挺合用的，先开放的接受之后，明白自己想要用这个东西做什么： 学习用法? 学习解决问题的思路? 学习代码的组织方式? 学习编程的技巧? 明确这个问题后，会发现自己的目的性就明确多了，也会发现学习的脉络就会慢慢浮现上来。

好奇心

做前端需要有充足的好奇心，这个好奇心是指： 对所有不熟悉的东西都有兴趣去了解一下; 了解之后会有兴趣上手实践一下; 实践之后有兴趣思考一下; 在合适的场景合适的时机应用一下，或者优化一下。综合在一起，可以这样来描述：

很庆幸，在我踏入职场不久就让我接触到了前端这个角色，让我有机会把对美好设计感的追求和技术的力量叠在一起，在B类业务经历的这段时间，让我有更多的机会和责任去思考成为前端的追求，总算略有些成果，和大家分享。