2018年的前端是否有『架构』可言?

最新推荐文章于 2022-12-30 09:51:35 发布

架构文摘

最新推荐文章于 2022-12-30 09:51:35 发布

阅读量306

点赞数

一、关注点

后端架构的目标，题主也说到了，高性能、高可用、可扩展、安全。

至于后面说的那么多知识点，虽然都是有用的，但是不免有些掉书袋了。你说高可用有各种难点，有各个方面，但事实上这些问题的解决方案也都非常明确了。如果不明确的也是业界公认暂时无解的问题，例如分布式CAP等。至于其中的具体策略，如果还需要自己去想，那这个后端工程师（还不叫架构师）应该是不合格的。做后端的架构其实基本上是选择。

那么前端呢？目前是高性能、高可用、可扩展、安全？所以数据库不用选，语言不用选，框架三选一，架构就简单了？我认为这是对前端的关注点理解不到位的体现。

二、前端的核心关注点——用户体验

作为前端工程师，关注点是什么呢？首先就是用户体验。

用户访问我的网站快不快，用起来爽不爽，会不会觉得卡，会不会觉得low。这才是前端最该关注的东西。

所以我做的架构一点都不高大上。如何让网站加载更快，如何不引入不必要的代码，把不必要的代码干掉，如何让用户加载最少的内容，如果让用户最快看到效果，前端渲染还是后端渲染，同步输出还是异步输出。

是不是觉得一点都不是架构师干的事？但前端构架师确实就是在干这些事。

诸如此类的事情非常多，比如报错是红色文字还是输入框变红？Loading放顶上还是页面中间？转菊花还是骨架屏？先显示占位图还是先白屏？

所以，你要说前端技术架构师，还不如说是用户体验架构师。跟后端不在一个维度上。

三、工程难度

题主说，“最多算上错误监控、埋点方案、缓存策略等偏运维的决策”，仿佛这些是一句话可以搞定的很简单的事情。

是，后端错误监控不难，无非try..catch嘛，再不挤进程挂了还有运维工具可以救人于水火。但是前端呢？一个ajax加载失败了怎么监控，一个css加载失败了怎么监控，再极端一点，浏览器卡死了怎么监控，页面崩溃了怎么监控？

至于埋点，能做得好的我都非常佩服。连用户关闭了你的页面都监控不到，还想通过埋点来获取业务和技术数据？

至于缓存就更奇葩了，到底有没有缓存，到底是200还是304还是没有请求了，到底版本对不对，到底有没有被代理瞎搞，到底这个神奇的浏览器是怎么处理缓存的……别以为说一句“加个缓存”，就这么轻轻松松地搞定了。每一个把缓存玩好的前端工程师都值得尊敬。就不说更多的什么localStorage/serviceWorker之类的了。

说这一大段，并不是要说前端架构师搞这些很苦很累，你们要尊重我们。而是想说，这些不起眼的事情，不如想象的那么容易，很多时候架构师是在帮助工程师探路或者踩坑，把这些东西的技术方案搞定。

四、面向团队

前端工程化还不成熟，这是个切实的情况。架构师在项目选型的同时，有相当部分的精力会放到工程化方案的选型上。是否用webpack，是否用npm，是否用typescript，是否用ES6/7/8，是否要babel，是否用postcss。是否要CI，是否要自动打包发布。是否要分包加载，是否要抽取CSS文件……

这些事，在后端可能不存在，在客户端可能也不存在，或者即使存在，也被IDE悄悄地代劳了。作为项目的选型者，写几个依赖，install一下就开工了。但是前端不行，前端这里有大量的工程化选型或者配置/开发的任务。

作为架构师，如何选择一套好用的、没有坑的语言/构建工具，也不容易。

我举个例子吧，大家可能觉得typescript很好，直接用不就好了吗？殊不知，typescript需要配置tsc或者webpack的ts-loader（现在babel也可以了），还有tsconfig文件，以及各种.d.ts文件。当然，即使这样，也有可能在写代码的时候报一堆无法解决的错误，需要你花大量的时间去研究为什么有这个做，怎样可以不报错（也可能根本就不能不报错）。当你在Vue中使用typescript时，你需要研究怎样让它识别Vue Component的类型，怎样做自动提示和类型检查。当你在ajax使用时会发现你要研究怎样将服务端返回的数据与某个类型映射起来（然后发现在runtime时毛用都没有）。

前端架构师，也有相当多的精力在这上面。

这是一个好的现状吗？未必，但现状确实如此，这个锅架构师不背谁来背？

五、小结

所谓架构，我理解是综合考虑目标、业界和团队，作为合理的方案选择，既能支撑业务的发展，又能令团队满意。如果能达到这个目标，自然就是一个好的架构。目前来看，前端要做到一个好的架构不容易，做的事情并不比后端少。

至于说前端架构师做的所谓的这些架构的事情是否高大上，那是另一个没有答案的问题。