为什么要有前端架构师

任何一种岗位的诞生, 都源于问题规模的膨胀

前端工程师的诞生, 就源于 web 开发这个问题规模的膨胀, 早期的网络程序员, 和现在的全栈工程师具有类似的属性, 唯一的区别是处理问题的规模相差极大, 在使用 jsp, asp 编写网页的年代, web 开发在页面端需要处理的问题规模极小, 不考虑 UI, 交互等用户体验的场景下, 仅仅是数据的呈现载体, 通过简单的模板绑定数据, 服务端渲染既可解决问题, 而且彼时, 数据库也仅仅是数据库, 高并发, 集群, 大数据, 云计算, 也仅仅是概念, 并未像现在这般大规模应用.

为了解决日益膨胀的 web 开发中"端"的问题, 前端工程师就诞生了, 在这个逐步发展的过程中, 前后端的职责也日益清晰, 不再混沌. 然而互联网发展速度之快, 超乎人们的想象, 前端开发问题的膨胀速度同样惊人, 堆砌的业务逻辑和复杂多元的技术栈体系以及不统一的工程体系加上 js 灵活的语言特性, 促使前端开发这个问题的规模以惊人的速度膨胀, 以至于前端工程师调侃自己是 "重做工程师". 于是顺理成章的, 前端架构师就诞生了.

在前端开发的早期, 架构是一种非常隐晦的概念, 原因在于前端开发的问题规模较小, 在 JQuery 大行其道的年代, 基于 JQuery 的插件式架构, 基本是所有前端应用的默认模式, 即便加上 Backbone 带来的 MVC, 背后的架构也是趋同的. 而此时, 前端还不直接处理业务, 大多是实现一些视觉和交互上的效果, 通过上网扣 JQuery 插件就能很好的解决问题. 然而这种状况随着前后端分离的兴起, 很快被打破, 从 angular1.0 到 React, 从 browserify 到 npm, 从 requireJS 到 es6Module, 前端的发展突然加速, 令人目不暇接, 技术更替的周期越来越短. 在这种环境下, 前端工程师无心梳理应用中的架构, 埋没在技术更替和业务迭代之中, 而背后的架构模式, 在不同的技术体系组合中也开始四分五裂. 管生不管养的业务代码成了摧毁应用架构的最后一根稻草.

" 这代码不重构, 根本改不动! "
" 这代码就像一坨屎, 谁写的? "
" 卧槽, 根本理不清这业务逻辑. "

一时间, 重构 && 重做成了解决问题的银弹, 然而真的是如此么? 且不说重构带来的技术风险, 使用新技术重构老代码实际上是借助一些库背后所隐藏的架构模式来解决现有架构上的混乱, 然而就跟盖房子和装修一样, 即便房子的户型做得再好, 硬件设计的再妙, 住进去的人一样能把你好好的房子搞的一团糟, 在技术上你即便用了 React 或者 Vue 全家桶, 我敢说迭代个七八次, 代码一样能乱的你爹妈都分不清.

如果作为 TL, 你对以上这些深有同感, 那你可能就需要给你的团队配一名前端架构师,
如果作为资深工程师, 你对以上这些深有同感, 或许你该考虑转职成一个名前端架构师.
所以为什么要有前端架构师? 因为问题太多, hold 不住啊!

前端架构师的职责

没有文档的代码 = 放弃治疗

作为前端架构师, 首先要解决的问题就是让日益膨胀的代码可控,因此你需要 梳理代码, 建立架构, 组织文档, 管理架构的更新和维护, 评审技术方案对架构的影响, 核心模块的方案设计, 重点项目的方案设计, CodeReview 等.

架构师和资深开发在工作职责上有着明确的界限, 在一个没有架构师的团队, 每一个资深开发或多或少都承担了一部分架构的工作, 但都是破碎的, 不成体系而且不统一, 从某种意义上讲, 这种隐晦的架构还不如没有架构. 所以确立一名架构师, 从管理上也是将混乱统一的唯一途径, 在团队还小的时候, TL 可能会默认承担架构师的角色, 但团队规模增长到一定程度, TL会变得力不从心起来, 将工作分给专业的人, 永远都是工程上自然而然的结果.

相比实际的 coding, 用一段代码解决某个问题, 实现某个需求, 架构要复杂和烧脑的多, 本质上工程的问题, 只能用架构解, 而没法用代码解, 所以没有架构, 谈不上工程化. 因此架构师的第一要务, 是梳理代码确立架构

把前端架构立起来

在立起来之前, 我们首先要明确, 树立前端架构的作用, 当你担负起架构师的职责, 你可能首先面对的就是代码, 各种老代码, 我们着手去树立前端架构, 本质上就是要将代码隔离在各自的区域之内, 为接下来的工作打下基础.

因此第一步, 我们先要找出所有属于你团队的代码, 大到 git 仓库, 小到某段逻辑, 事无巨细, 我们把这个工作可以称为 "技术资产盘点".
等盘点清楚了技术资产, 就是第二步, 编写资产白皮书, 以文件为单位把所有的技术资产说清楚, 每个文件都是干嘛的, 资产白皮书非常重要, 这个将是你日后架构维护工作的核心.
第三步, 手上有料, 事情就好办了, 文件已经说明了解决的问题, 按照问题域和技术域, 对文件进行归类, 最后得到的就是现状, 99%的情况下, 现状都应该让你沮丧, 因为看起来就是一坨 shit. 但是这就是你要面对的 "shit 架构".

接下来考验架构设计能力的时候到了, 把 "shit 架构" 画成你心中的架构, 两者之间的路线图, 结合现状, 结合业务, 结合团队, 做出迁移的方案, 这些都做完, 你就成功的把前端架构给立起来了, 这个过程中你可能不需要写多少代码, 你要完成的都将是新架构中的核心功能的代码.

前端架构就是你的孩子, 你要保护他

如今你眼前的架构看起来应该不错了, 作为架构师你的职责就是保护他, 在你没有想到什么金钟罩之类的秘籍之前, 你只能用你的肉体了, 自己设计技术方案, 或者参与技术方案的评审, 在 CodeReview 中找出任何可能污染架构的代码, 总之你的核心工作是, 确保代码和架构设计之间的联系的真实性, 这部分工作往往体现在你如何高效的维护文档和 CodeReview, 这里有个小提示, 你的架构设计的越棒, 这部分工作就越轻松, 如果这部分工作让你疲惫不堪, 那你可能需要重新审视你的架构设计了. 另一部分来自于外部, 毕竟 CodeReview 是最后的保障手段, 但真正的防御应该是在设计之初, 任何对架构的修改, 在设计阶段就应该被你的火眼金睛察觉到那些不好的味道, 然后通过修改, 隔离等各种方式防止对架构的破坏和污染.

总之, 保护好你的架构, 无论他有多烂, 总比没有强, 等你的架构变得健壮而灵活, 带给团队的收益将远超你的想象.

某野生前端架构师
写于2017年夏末