我理解中的阿里“大前端”/“大无线”

内容包含五部分：前言，NodeJS职能变化，ReactNative的大规模应用，专门的架构组职能，总结。主要是介绍我从猎头视角所看到和听到的阿里大前端团队最近的一些变化和自己的思考。

前言

最近，有很多候选人会跟我聊阿里团队，而我又恰好跟很多阿里前端同学经常会聊一些细枝末节。所以，今天在这里，就我从猎头视角所看到和听到的阿里大前端/大无线团队的一些信息作一下分享。今天早晨，还看到一篇文章，讲“大前端”，文中展望了近年来“前端”影响的领域，从美工时代刀耕火种的时代到现在延伸到 NodeJS ，ReactNative甚至桌面端，以及传统前端的时代，听来的确让人非常兴奋和自豪，但是作为一名能看到行业的猎头，我觉得对于这种自High的论调一定要抱有谨慎的态度。

其实在技术选型上他们是一个激进却又保守的团队，所以，他们同大家伙一样，对于JS语言冒出来的给人无限想象的能力非常的敏锐和兴奋，但是在落地到真正的业务中的时候却要仔细权衡好它的真正的“价值”。此处的价值更多针对的是“对公司整体业务的价值”，而不是对团队或者个人的价值或是其他，所以，引入一个技术栈，绝非看起来那样简单，“新技术”可能会给你的团队或者业务带来加持，但是更多时候，外界的人云亦云却往往会夸大某个技术的价值，然后同时刻意避免谈及这些技术带来的问题，就是他们通常所说的“脱离场景讨论技术”，而且通常带来的问题比解决的问题还要多得多，这时候如果抱着“扩大前端团队的话语权”或者“做一步看一步毕竟业界都在这样玩”的态度，那就和“技术创造价值”的本意相违背了。

其实，大家会发现阿里大前端团队并不是一个保守的团队，从外面看，他们始终走在最前沿，但是从内部看，其实他们一直在关注“技术创造价值”这件事情的本质，所以他们给前端团队强化了很多职能，但是却走了一些不同的道路，之所以会这样，其实就是基于他们针对每个技术栈所做的思考，接下来我会举几个例子来讲。

其实我今天本来想讲的事情，并不只是“前端”，而是这次阿里大前端团队组织架构调整后的“大无线”，为什么要从“大前端”到“大无线”，也是基于最大化价值输出的考虑，这是后话。

这次调整，最大的三个动作就是， NodeJS的职能变化/ReactNative的引入/专门的架构组职能，然后包含其他一些小动作。

NodeJS 职能变化

对于 NodeJS ，我其实有挺多的话题想分享，关于前后端分离，关于服务端渲染，关于纯服务端开发。很长一段时间内，在阿里大前端团队，NodeJS 都是在做纯服务端开发，然后他们的核心关注点一直是致力于将NodeJS 在服务端开发的整个工程能力提升到和Java生态相当甚至是超越，包括开发/部署/运维/服务化/线上保障 等。值得注意的一点是，当他们的NodeJS 运用非常成熟的时候，他们却一直没有做业界大家在玩的服务端渲染，或者前后端分离中间层，其实不是他们不了解或者没有能力，而是他们一直在思考“为什么”，然后会”带来什么问题？“。我觉得很多公司在做服务端渲染或者前后端分离的时候，可能都没有非常全面的去思考过这个问题，是必须要做了而且带来的价值远远超越了风险？还是只是为了让团队占领更大的势力版图？我曾记得他们在讨论这个问题的时候还提到，包括在某些大公司内，做某些事情可能只是政治正确或者为了业绩好看，如果你去问一个服务端开发，他对这些事情的看法是什么？难有好评？那这件事情可能就已经走偏了，它可能关注了前端团队的自身价值，却偏离了整个技术团队的价值体现。

当然我不是表达不应该去做某些事情，而只是讲所有技术栈的落地都要基于场景去考量权衡。其实他们团队后来也做了业界意义上基于”服务端渲染”的”前后端分离“项目，在某个特殊业务中，他们衡量必须要做，与多方共同讨论，最终实施落地的一个和谐方案。做这个项目的目的足够单纯，但是他们并没有打算推广这个方案，因为在我看来，他只是解决某个特定场景的一个解决方案，而不是一种必须推开来的“开发方式”。而且对于服务端渲染引入的风险一定要做好风险评估，包含但不限于：运维/线上保障能力（前端的弱项）；前后端开发的复杂度；性能问题（真正做过服务端的同学对内存和cpu占用都会很敏感，但是目前一些方案看来在这方面的损耗还是太夸张）；NodeJS本身的开发能力熟悉程度。其实有些问题是很严重的问题，只是在业界大家讨论的时候，大家会刻意去弱化某些话题，而是强调其革新之处，或者是未来的趋势，而这些理由