前端是否需要架构师岗位

不要怀疑，前端是需要架构师的。

前端架构师和其它职能的也是不一样的，不能套用。

需要的条件如下：

1、团队大了，10人以上。越大越需要。

人多就意味着协同和效率，协同和效率看似互相成就，实际上矛盾重重。每个开发人员都有自己的技术习惯，项目功能分工后，必然存在独立到组合的过程，没有统一的规范，这个过程就困难无比。不仅不提升效率，反而影响。规范影响到研发环节的每个细节，即使是git分支合并这一件事，就能让所有人烦一天。

2、业务复杂度大，有多个业务领域，且交织。

业务复杂带来的是所有事情的复杂，包括后端、测试、运维、大数据等。前端绝非独立于这些职能之外，每一个研发部其它部门都需要前端的参与。

如果没有架构师这个角色，前端在每个地方都是被动参与，结果就是前端的参与形式都是被非前端规范好的，这对前端开发人员来说是很痛苦的。

3、对需求迭代速度有要求了

相信所有程序员都有一个感觉，只要上线时间没要求，编程就是一件艺术，是一种生活享受。但只要有deadline，编程就成了烫手的山芋。

如果研发链路还是原始的，没有章法的，那开发人员就得在跟需求没关的技术锁事上耗费精力。速度就上不来。

4、线上用户大了，稳定性开始直接影响营收

一旦线上稳定性被提上日程，就是件费精力的事情，有很多基础设施要建设，前端资源的版本控制、灰度控制、监控告警等。

指望其它职能的架构师帮前端做这些事情是不可能的。

Tips:

没有架构师也可以的。它不是必须的。

前端主管的职责和架构师的职责有重复，但不重叠，是2个岗位。

正确认识架构师和一线开发的关系

基本上每个开发都想做架构师，所以，每个人或多或少，都会学习和练习与之相关的知识。

所有每个人都有自己的想法，但是想法和做，是两件事。

因此，要有清晰的认知。

关系是：它从开发中来，担着责任，服务开发。

从开发中脱颖而出，也很困难。

举个例子：

1、先说规范。A有想法，但让A去制定其中一项规范，他就不太想干，因为说服团队所有成员用这个规范是有难度的，也是需要勇气的，只要去干，就需要综合能力，绝非单技术。

2、再说基础设施。比如解决线上部署，这个确实不需要说服其它成员，但是要和运维、后端协同做这件事，面临的挑战不比团队内部小。而且这个产品是否真的让开发人员方便，是否能让部署更流畅，资源更稳定，这些都是要担责任的，怕背锅就别干。

事上有两件事，所有人都下意识逃避，从古至今。

沟通和责任。

沟通的逃避本质是说服，人都是很难说服的，所以这件事极费心力，这么费能量的事，逃避也是为生存好，没什么好害臊的。

娱乐性质的聊天只是生活，不是沟通。

责任更不必说，只要主张，就得承担责任，何况所有程序上线都在你的产品上过一遍，出什么问题都要先拿你问一遍。所以大厂的技术产品得配专门的客服。

做架构师，不只是技术上的事。技术、能力、心力、耐心都要强大。

架构师是技术，是服务人员，也是产品经理。

希望有志做架构师的同学，要正视这个问题，多方面锻炼自己。

前端架构师都要做啥

一、对业务全盘掌握

前端大多对业务大盘不熟，只对自己写过的需求熟悉。初级工程师可以，但架构师不行。

要明白，脱离业务是搞不好架构的，关于这一点，上篇文章中也有阐述。

原因如下

• 需求迭代一定引发工程复杂性，根据业务大盘，规划好工程类目、模板类型、cdn资源分发目录等都需要全面了解业务后才能合理规划，否则容易引发笑话，损失个人口碑还好，让前端团队陷入混乱就麻烦了。
• 线上稳定，业务多了之后，各系统领域之间来回交织，会形成一张看不见的网，只要对业务不了解，在遇到线上问题的时候很难解决问题，因为你必须把所有领域的人拉进来，讨论无休止，你一定遇到过。
• 技术决策需要，对新的大型需求，必须引进新技术，或者是重大系统重构也要技术决策，如果对业务不熟会容易在过程中引发不可挽回的损失，到时只能走，还留了一堆烂摊子。
• 跨职能部门协作，架构师是经常性和其它职能合作的，规范、基础设施、业务架构、数据收集，甚至汇报材料，业务搞不清楚容易在管理层会议上闹笑话，影响工作。
• 影响立项，影响面评估不能不评估业务范围，也有可能要说服运营和产品。

如何掌握

• 一是新手保护期拼命的问人，因为是刚来，你问什么都不是错，反而让人觉得你用心，过了保护期再问，就是傻。所以珍惜这个保护期，3个月左右。你最应该做的不是搞事情，而是在做好项目开发的基础上，做个十万个为什么。
• 二是多和测试聊天搞好关系，测试不仅熟知需求，还熟知需求底层的数据流转，这就是为什么老员工测试总是底气足的原因。技术再好，业务一问三不知能有什么底气，有底气技术一般都让人觉得好！离谱是吧！
• 三是多看代码，一切都在代码里，前端、后端、数据库都得连着看。

二、基础设施建设

也就是前端的研发链路，一定要先完善，把底子先整理清楚。

• 技术选型：在业务了解清楚后，就需要对现有业务和未来业务进行判断，选择适合的技术栈组合，当成员多的时候还要考量清楚成员已经掌握的技术栈情况。
• 工程模板：也就是脚手架，针对业务的不同要有不同的模板，比如h5的和pc的肯定不同，后台系统和前台也不同，等等，因为前端开发需要依赖大量的三方库，不同业务形态对库的需求也是不一样的，为了保障工程干净，就必须有多套模板，这个架构师可以带领小组里技术好的一起来做。
• 代码规范：前期选用开源的已经有的规范集成在工程中就可以了，没必要自己搞一套。
• 调试工具：这个弄不好，直接影响开发效率、一线开发的工作体验、bug清空效率，线上问题排查效率，很多团队不重视这个，实际上非常重要，能够在很多关键时刻救场，甚至保住职位。建议和测试、运维、native开发团队一起商量建设。
• 部署：在一线前端开看，部署跟前端没多大关系，实际关系巨大！像跨域这种基因问题，在这一层面可以得到很好的处理，还有后端api调用的规范也可以在这一层协商，还有自动化部署、版本控制、灰度发布、cdn接入等都可以在这一环节处理妥当，平台化，只有平台化，前端开发人员才有主动权调整以上这些事情，要不然干什么都要向运维部门提工单，费时费力，还耗费运维同事的心力。
• 质量保障：前端主要参与的就是日志监控，这个可以自建(elk)，也可以用开源的，如sentry,日志的收集不难，难的是处理、告警、fix。

基础建设非常繁琐，需要团队一起建设，当然需要架构师的团队肯定不小，小团队挂个架构师也没必要。

三、业务架构决策

前端，成了架构师，就不只是前端了。

必须要和其它职能的架构师有充分沟通，各系统之间的运转需要知道。

特别是后端很容易把前端忽视，以为前端只写页面就行了，如果真这样，业务只要发展一段时间，必须乱成一团。前端架构师有责任和其它架构师协商好业务架构。

那有哪些需要协商呢

• api规范：出入参数据格式，调用路径规范，响应规范，跨域解决方案，用户态方案，调用日志传递等
• 云服务：文件存储空间的分配、cdn资源、媒体资源、内外网网关、开发环境等
• 关键技术：有些核心技术需要前后端一起共建的
• 内部系统：前后端都能写，怎么规范的问题
• node服务：很多业务用node更方便，这个就需要融入后端的微服务架构，也需要运维的参与，大多数后端负责排斥node，需要极大心力和材料去沟通。
• 大数据：哪些是前端负责收集的，哪些是后端负责的，要和数据团队一起划分清楚。

具体在工作中是很多的，总之就是前端架构师不能只看前端，要关注整个研发部的动向，让前端融入到里面，不能置身事外。

四、新技术引进

为什么，有可能业务方向变了，也有可能有合作方进来，有可能买了一个系统等等，中大型公司遇到这样的事非常正常。架构师要有这个定力和自信，去接纳新的技术。

不仅要接纳，还要研究，尽快判断它的必要性。

这里又需要对业务的发展有认知，要争取在一些中层管理会议上有旁听权，避免对未来的业务一概不知。

• 应对集团架构变动

如果是大厂，需要应对来自集团技术架构的变动。

变动因素有很多：

比如维护某个技术产品的团队被裁了，在国内业务领导不太重视技术。这种事是存在的。

比如技术产品出现一次大迭代，导致上下游要跟着改，甚至不提前通知。

比如技术产品出现稳定性问题。

等，这里不一一罗列。

作为架构师，在不得不，在集团架构之上建立研发链路时，必须做好应对措施，对各技术平台的联系人，平常都要保持联络。

总结：

前端架构师的核心职责，是保障前端的生产效率、生产质量、生产体验。为此，他需要把视野放在整个业务部门，把动作放在各职能负责人之间，把自身摆在重要的位置放大影响力，千万不要弱化自身。