新前端技术分享： 为何要有前端架构师？

你们好，我是玄铁 ，现已工做8年，如今在一线互联网公司担任前端架构师，负责系统架构、性能优化，规范、工程化建设，前端组内的技术分享、人才培养等工做，

技能：熟练HTML5/CSS/ES6/Nodejs/Webpack等web主流技术等。

熟练掌握React或Vue框架，熟悉框架相关技术生态等。

熟练配置项目脚手架，熟悉grunt, gulp, webpack, parcel等工具。

你想不到我都应该了解一点。

前端架构师的由来：

前端工程师的诞生, 就源于 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 是最后的保障手段, 但真正的防护应该是在设计之初, 任何对架构的修改, 在设计阶段就应该被你的火眼金睛察觉到那些很差的味道, 而后经过修改, 隔离等各类方式防止对架构的破坏和污染.

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

在其位，谋其政，站在架构师的职位上，架构师要本着对团队支持、对系统负责，对领导和业务相关方充分沟通与建议的基本准备，充分利用自身的经验与阅历，帮助团队规避各种或深或浅的系统之坑陷，保证业务线的正常运转，同时保持系统具有必定的灵活性、稳定性和可持续开发性。 尽人事，知天命，有所为，有所不为，架构师实际上是技术、业务、管理和资源等各种因素之间进行妥协、沟通和协调的角色，混很容易，作好很难。

前端图谱：