大淘宝技能前端工程师梧忌引荐语：有幸在大淘宝与洋风同学同事了一段时间。他在终端架构侧有丰厚的经历，他所打造的终端调试东西 AppDevTools 、终端请求库 mtop.js 在阿里内部被广泛运用。洋风从自己的经历动身，在这篇文章中叙述了前端架构师的作业领域和怎么做好前端架构，信赖关于希望往该方向生长的同学会有所协助。
参加大淘宝到现在也有六年多了，一路走来很高兴能够一直做技能。担任过事务、根底库、东西以及架构，希望自己不断生长。想对之前的作业做一些考虑和记录，也想为后续的作业找一个适宜的开端。有蛮多话想说的，这次就先从 “前端架构” 这个论题慢慢说起吧。
聊聊架构
好的代码和差的代码都能运行，但咱们会寻求好的代码，获得更好的维护性和可读性。同理没有架构的体系也能作业，但假如一个事务团队没有好的架构，整个团队将陷入混乱，最终难以支撑事务快速变化。
架构是为了处理问题，将杂乱、含糊的问题，变得明晰、有逻辑。问题的尺度上，能够大到整个公司的体系规划，也能够小到一个模块怎么烘托。问题的时间上，能够是当下的问题，也能够是预期今后会发生的问题。怎么做好结构和怎么处理好问题有许多相似之处，比方把杂乱问题简略化，比方找到多种处理计划并在其间找到最适宜有效的计划，比方要考虑本钱和完成，操控好危险等等。网上也有许多关于架构规划的原则和思想等，这里就不在赘述了。
我所寻求的架构，不只需明晰有逻辑，还要简略灵敏好扩展；能切实处理问题，也能支撑事务快速稳定开展，并不断演进。
聊聊前端架构师
所谓架构师，浅显的说便是架构的规划者或构建者。《架构师到底是做什么的？》很有意思，其间有一段话是这么说的：
一个架构师， 好的架构师， 便是反复做四件事：榜首，先选一个好的应战， 第二， 把简略的东西想杂乱 ；第三， 把杂乱的东西做简略；第四， 最终把杂乱的东西讲简略。
做榜首件事是为了发明价值， 第二件事是为了操控好危险和准备好未来， 做第三件事请是为了做好产品且操控好本钱， 而做第四件事情是为了做好传承。
架构师有必要依靠团队的支撑，不同的专心领域衍生出不同的架构师，这里主要聊聊前端架构师。曾有人说前端架构师便是选选框架，搞搞文件目录就能够了，但随同根底设施的开展、大前端体系的不断增大以及用户体会的不断升级，前端架构师有了更大的价值和更高的上限。环绕用户体会链路，前端架构师能够将具有不同重视点的团队联系起来，包含产品、规划、前端、服务端、客户端、工程、数据、运维等团队，用户视角也能协助前端架构师发现更多问题。环绕大前端技能，前端架构师能够主导一切技能体系的规划和完成，甚至会影响安排架构的调整（比方终端工程师的诞生）。
当然前端架构师的目标也离不开高性能、高可用、易扩展以及处理体系杂乱度。举个处理首屏加载速度慢问题的比方，咱们做了以下事情：
- 了解事务：全面调研当时事务和竞品的现状，充沛了解当时烘托链路和节点，确认当时存在的问题
- 寻觅计划：预估未来开展的方向，尽可能多的了解相关处理计划或立异自己的计划，比方：SSR，ER，预烘托，预加载，静态化等
- 评价计划：和相关同学评论或开会，评价一切可行的计划及其适宜度、杂乱度、前瞻性和 ROI。选出至少一个候选计划，比方：SSR
- Demo 开发：基于现有开发才能为一切候选计划开发对应 Demo，提早探路并验证危险和可行性，协助产出更适宜的计划规划
- 计划规划：整理清楚 SSR 完好链路上相关节点和合作方，多写、多画、多考虑、多评论相关架构和规划，深入细节产出 RFC 文档
- RFC 评定：充沛评定规划、完成和产品细节，可多次评定直至一切成员达到一致。确定相关开发和团队分工，确保计划完善可执行
- 落到实处：推进项目开发，多与开发团队交流，并至少参加一部分编码作业，打通一切相关开发和运维链路，保证产品简略好用
- 沉淀传承：沉淀文档，经过会议、分享或文章协助其他人了解 SSR 计划和架构，用好 SSR。做好答疑，并推动计划施行
- 不断演进：重视 SSR 的开展，演进已有链路，比方，个性化的 SSR，结合 ER 的 SSR 等
从开发、构建发布到全量用户运用，从数据衡量到问题排查，咱们交付了一个完好的 SSR 计划，其间处处有前端架构师的规划和影响。
前端架构师是否和你幻想的有所不同？不只仅要产出架构图，确保架构的正确执行，深入完成并至少要参加一部分编码作业，落实一个一个处理计划一起，前端架构师也要能阅读代码并常常与各个开发团队交流。能够说整个用户体会链路都有前端架构师的影子，他们了解用户体会；不设限，有审美才能，优雅；能看到其他人看不到的问题，也能处理一些其他人处理不了的问题；能够把杂乱的体系想得清楚和透彻，也能够了解各个模块和环节；对未来开展有自己的考虑和判别，并不断处理 DX 和 UX 相关问题。
考虑和总结
回顾过去的作业，得益于团队的信赖及大前端的不断演进，我能够不断学习考虑实践、权衡重构及与人打交道，令我十分愉悦，受益匪浅。严格来说我应该算个前端处理计划架构师，在前端架构的方向，我也还有许多需求开展和改善的当地，下面整理下个人的考虑和总结：我认为一个好的架构师，不只技能要好，还要懂事务；能从全体规划架构，也能在局部完成功用。首先，技能好是成为架构师的根底条件。在平常的开发中，需求多留意让你的代码容易阅读和扩展，多想想是否有更好的完成方法，多参加代码审查作业。这样经过大量的编码实践，能够逐渐地培养出好的架构思想。成为架构师后也要多写代码，假如不写代码，是不能体会出开发的痛点和规划不好带来的问题，无法及时地对架构中的问题做出调整，所规划的架构可能不实用，甚至甚脱离现实。
架构师不同于高级开发能够只寻求技能的深度，还需求有必定的技能广度。因为技能的选型，通常不能局限于一种技能，需求依据事务特色和团队特色灵敏地挑选，是 “T”字形的生长模型：
- 广度：做技能计划时，要有多种挑选，最好能够熟悉各个链路的联系
- 深度：要能处理一些他人搞不定的问题，至少也能辅导从某个方向入手排查
其次，要充沛了解事务并时刻重视事务变化，使架构不只能够很好地支撑事务特色，并具有必定的前瞻性。架构师需求站在推进事务开展的角度上合理地改进和优化架构规划，为事务的快速开展做好保证。做“适宜”的架构十分重要，防止拿着锤子找钉子。
再者，要做一个靠谱并有良好的交流和协调才能的人。架构师往往要面临着跨组、跨团队甚至跨 BU 的一些技能计划，需求在互信赖任的前提下交流和协调各方的诉求和抵触。好的架构师也能够让事务、技能、团队一起变得更好。
最终，我想说其实做架构规划，并不代表必定要有一个架构师的头衔。每个人都能够参加到架构规划中来，只需心中有全局有架构思想，能了解当时架构规划，不断更好的优化和执行，就能写出好代码做出好架构，提升全体的凝聚力和战斗力。
要想成为好的架构师，没有什么捷径能够走。继续的学习，不停的考虑，多问为什么，多想想还能不能更好。愿我们都能够成为一个优异靠谱的程序员、架构师。
