前端的一些思考和总结-技术圈

加入大淘宝到现在也有六年多了，一路走来很开心可以一直做技术。负责过业务、基础库、工具以及架构，期望自己不断成长。想对之前的工作做一些思考和记录，也想为后续的工作找一个合适的开始。有蛮多话想说的，这次就先从 “前端架构” 这个话题慢慢说起吧。

聊聊架构

好的代码和差的代码都能运行，但我们会追求好的代码，获得更好的维护性和可读性。同理没有架构的系统也能工作，但如果一个业务团队没有好的架构，整个团队将陷入混乱，最终难以支撑业务快速变化。

架构是为了解决问题，将复杂、模糊的问题，变得清晰、有逻辑。问题的尺度上，可以大到整个公司的系统设计，也可以小到一个模块如何渲染。问题的时间上，可以是当下的问题，也可以是预期以后会发生的问题。如何做好结构和如何解决好问题有很多相似之处，比如把复杂问题简单化，比如找到多种解决方案并在其中找到最合适有效的方案，比如要考虑成本和实现，控制好风险等等。网上也有很多关于架构设计的原则和思维等，这里就不在赘述了。

我所追求的架构，不仅要清晰有逻辑，还要简单灵活好扩展；能切实解决问题，也能支撑业务快速稳定发展，并不断演进。

聊聊前端架构师

所谓架构师，通俗的说就是架构的设计者或构建者。《架构师到底是做什么的？》很有意思，其中有一段话是这么说的：

一个架构师，好的架构师，就是反复做四件事：第一，先选一个好的挑战，第二，把简单的东西想复杂；第三，把复杂的东西做简单；第四，最后把复杂的东西讲简单。

做第一件事是为了创造价值，第二件事是为了控制好风险和准备好未来，做第三件事请是为了做好产品且控制好成本，而做第四件事情是为了做好传承。

架构师必须依靠团队的支持，不同的专注领域衍生出不同的架构师，这里主要聊聊前端架构师。曾有人说前端架构师就是选选框架，搞搞文件目录就可以了，但伴随基础设施的发展、大前端体系的不断增大以及用户体验的不断升级，前端架构师有了更大的价值和更高的上限。围绕用户体验链路，前端架构师可以将具有不同关注点的团队联系起来，包括产品、设计、前端、服务端、客户端、工程、数据、运维等团队，用户视角也能帮助前端架构师发现更多问题。围绕大前端技术，前端架构师可以主导所有技术体系的设计和实现，甚至会影响组织架构的调整（比如终端工程师的诞生）。

当然前端架构师的目标也离不开高性能、高可用、易扩展以及解决系统复杂度。举个解决首屏加载速度慢问题的例子，我们做了以下事情：

了解业务：全面调研当前业务和竞品的现状，充分理解当前渲染链路和节点，确认当前存在的问题
寻找方案：预估未来发展的方向，尽可能多的了解相关解决方案或创新自己的方案，比如：SSR，ER，预渲染，预加载，静态化等
评估方案：和相关同学讨论或开会，评估所有可行的方案及其合适度、复杂度、前瞻性和 ROI。选出至少一个候选方案，比如：SSR
Demo 开发：基于现有开发能力为所有候选方案开发对应 Demo，提前探路并验证风险和可行性，帮助产出更合适的方案设计
方案设计：梳理清楚 SSR 完整链路上相关节点和合作方，多写、多画、多思考、多讨论相关架构和设计，深入细节产出 RFC 文档
RFC 评审：充分评审设计、实现和产物细节，可多次评审直至所有成员达成共识。确定相关开发和团队分工，保证方案完善可执行
落到实处：推进项目开发，多与开发团队沟通，并至少参与一部分编码工作，打通所有相关开发和运维链路，保障产物简单好用
沉淀传承：沉淀文档，通过会议、分享或文章帮助其他人理解 SSR 方案和架构，用好 SSR。做好答疑，并推动方案实施
不断演进：关注 SSR 的发展，演进已有链路，比如，个性化的 SSR，结合 ER 的 SSR 等

从开发、构建发布到全量用户使用，从数据衡量到问题排查，我们交付了一个完整的 SSR 方案，其中处处有前端架构师的设计和影响。

前端架构师是否和你想象的有所不同？不仅仅要产出架构图，保证架构的正确执行，深入实现并至少要参与一部分编码工作，落实一个一个解决方案同时，前端架构师也要能阅读代码并经常与各个开发团队交流。可以说整个用户体验链路都有前端架构师的影子，他们了解用户体验；不设限，有审美能力，优雅；能看到其他人看不到的问题，也能解决一些其他人解决不了的问题；能够把复杂的系统想得清楚和透彻，也能够了解各个模块和环节；对未来发展有自己的思考和判断，并不断解决 DX 和 UX 相关问题。

思考和总结

回顾过去的工作，得益于团队的信任及大前端的不断演进，我可以不断学习思考实践、权衡重构及与人打交道，令我非常愉悦，受益匪浅。严格来说我应该算个前端解决方案架构师，在前端架构的方向，我也还有很多需要发展和改善的地方，下面梳理下个人的思考和总结：我认为一个好的架构师，不仅技术要好，还要懂业务；能从整体设计架构，也能在局部实现功能。首先，技术好是成为架构师的基础条件。在平常的开发中，需要多注意让你的代码容易阅读和扩展，多想想是否有更好的实现方式，多参与代码审查工作。这样通过大量的编码实践，可以逐步地培养出好的架构思维。成为架构师后也要多写代码，如果不写代码，是不能体会出开发的痛点和设计不好带来的问题，无法及时地对架构中的问题做出调整，所设计的架构可能不实用，甚至甚脱离现实。

架构师不同于高级开发可以只追求技术的深度，还需要有一定的技术广度。因为技术的选型，通常不能局限于一种技术，需要根据业务特点和团队特点灵活地选择，是 “T”字形的成长模型：

广度：做技术方案时，要有多种选择，最好可以熟悉各个链路的关系
深度：要能解决一些别人搞不定的问题，至少也能指导从某个方向入手排查

其次，要充分理解业务并时刻关注业务变化，使架构不仅能够很好地支持业务特点，并具有一定的前瞻性。架构师需要站在推进业务发展的角度上合理地改进和优化架构设计，为业务的快速发展做好保障。做“合适”的架构非常重要，避免拿着锤子找钉子。

再者，要做一个靠谱并有良好的沟通和协调能力的人。架构师往往要面临着跨组、跨团队甚至跨 BU 的一些技术方案，需要在互相信任的前提下沟通和协调各方的诉求和冲突。好的架构师也可以让业务、技术、团队一起变得更好。

最后，我想说其实做架构设计，并不代表一定要有一个架构师的头衔。每个人都可以参与到架构设计中来，只要心中有大局有架构思维，能理解当前架构设计，不断更好的优化和执行，就能写出好代码做出好架构，提升整体的凝聚力和战斗力。

要想成为好的架构师，没有什么捷径可以走。持续的学习，不停的思考，多问为什么，多想想还能不能更好。愿大家都可以成为一个优秀靠谱的程序员、架构师。