前端架构师的一些思考和总结

前端架构师的一些思考和总结已关闭评论

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

聊聊架构

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

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

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

聊聊前端架构师

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

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

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

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

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

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

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

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

思考和总结

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

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

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

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

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

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

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


来源: 大淘宝前端技术