前端工程师转型架构师的经历

前言

前端架构师， 听起来就是个很高大上的 Title， 每个初入行的前端工程师在面试时， 被问到你未来的方向是什么？ 我们或许都会很顺口的回答， “嗯， 朝着架构方向走吧。..”， 那这个像是顺口溜的答案背后， 从身体到思维， 我们究竟经历了什么样的转变呢？ 嗯。.， 让我努力回忆下， 从头开始， 向各位分享这种奇妙的转变过程。

当我第一次看到架构这个词， 是在旧的翻了毛边的编程书上， 而此时对于我来说， 架构仅仅是一个词， 两个汉字和一堆概念。 而第一次我自己说出这个词， 是在14年， 那时转行写代码刚满1年， 对一个码农来说， 1年经验很浅， 无论是从思考还是手感， 都谈不上有太多积累， 但是当对面的面试官， 问道： “ 你未来有什么发展方向？ ”， 我还是不假思索的说出了 ： “朝架构发展吧。.. ”， “你觉得什么是架构？ ”， “ 。.. ”

这次的面试时间很长， 长到我已经忘记了， 我是怎么回答， 什么是架构这个问题， 但是从我说出架构这个词开始， 对架构的思索的种子， 就在我脑海中种下了， 每当坐地铁， 闲下来， 蹲坑的时候， 我都会想起这个问题。 虽然我经常思考， 但这个问题在我脑海中依然是一堆问号。 如果要给整个转变划分个阶段的话， 我想这个阶段可以称为 ［ 架构思维的萌芽 ］

架构思维的萌芽

每一种思维模式都会有一个思维的起点， 如果把架构看成是一种思维模式运作的结果， 那我们在思考架构的时候， 其实是启动了一种思维模式， 通过在这种思维模式下不断的思考， 我们的大脑会不断建立起各种联系， 这种联系会将你所有的知识， 经验串联起来， 最终得到一种快速的思维通路， 你越思考， 理解得就越深刻， 架构就逐渐在你脑海里清晰起来， 这一切自然有一个起点， 那就是架构思维的萌芽

各种碎片时间下不断对架构的思考， 巩固了架构思维在我大脑中的地位， 促使我开始从架构的角度去看待问题， 需求和代码， 代码的世界是一种依靠逻辑维护的奇妙世界， 随着世界的膨胀， 各种逻辑变得难以维护， 最终整个世界崩塌， 但当我加入一点架构之后， 世界的结构开始清晰起来， 慢慢的我开始看到逻辑背后的联系， 代码背后的那些隐藏的轮廓。 在这个世界里， 没有完美的架构， 自然也没有银弹， 不管如何调整， 维护， 设计和变更， 我们最终都会迎来这个世界的消亡， 但是一个有架构的世界， 即便是消亡也是有序的。

第一次尝试加入架构， 是在那次面试失败之后， 我手上有一个 SPA 的项目， 那时候 angular1.0 还没有发布， backbone 还在大行其道， 我依靠对架构的一点理解， 尝试自己去构建一个有序的代码世界， 结果显而易见的失败了， 因为我的知识和经验储备不足做出一个有效的架构， 但是这一次尝试让我明白了架构的重要性， 相对于 jQuery 时代的面条代码， 将代码合理分层显然能让这个世界显得更有序些。 无论是 MVC， MVW， MVVM， MVP， 都是对开发 GUI 应用如何更好的设计代码的一种尝试。

事实上， 在这个阶段， 我对架构的理解比起最初的时候更混乱了， 设计模式， 框架， 架构， 这些词在某一时刻互相混淆在一起， 傻傻分不清， 而有时候， 我会陷入究竟如何区分他们的困境中， 为了解决这个问题， 我阅读了一些书籍， 进行了更深入的思考， 我发现光靠这三个概念， 是不够的， 为了走出这个困境， 我发现必须引入新的工具， 这个工具叫上下文， 也叫语境。 而这个阶段应当称为 ［ 架构思维的混沌 ］

架构思维的混沌

时间过得很快， 在15年的时候， 我进入大厂工作， 在经历了各种信息的， 概念的轮番轰炸， 我对架构的思考开始引入上下文， 我发现有了上下文， 模式， 框架， 架构就开始变得不那么格格不入了， 在某一个上下文中， 它可以是模式， 在某一个上下文中， 它可以是框架， 模式， 框架， 架构在上下文的组合下， 开始能够被灵活使用了， 它们成了我设计和思考架构的工具箱中常用的工具。 同时期， 我开始接触 UML ， 另外还包括DDD， TDD 等一些概念， 还有常用的架构模式， 像六边形架构等等， 以及多了一种新工具“边界”， 但是很快我发现我陷入了另一种困境， 一些新的工具很难被应用在以 JS 为基础的前端领域， 而光依靠模式， 框架， 边界， 上下文设计出来的架构很难进一步细化， 前端架构成了空中楼阁， 无法落地。 我尝试生硬的怼， 但最终是徒劳的， 看起来这一阶段变得更痛苦了， 没错， 就像一个埋头走了三千里， 原本以为是终点， 但抬头发现依然是一望无际的痛苦。 或许前端不存在“架构”？ 不愿意接受这种答案的我， 开始进入下一阶段， 我称为 ［ 架构思维的成型 ］

架构思维的成型

这里本没有路， 走的人多了就成了路， 软件工程从建筑领域搬来诸多概念， 例如架构， 回顾历史， 从四人帮整理出设计模式开始， 软件开发经历了巨大的变革， 即便是 UML 都在持续发展， 但其实在这个领域内一直有一块没有被覆盖到的角落， 那就是前端， JavaScript 从一种玩具语言发展到如今的 Web 开发中的“汇编语言”， 变化巨大， 但在架构上的思考其实并不多， 从 Facebook 提出的 Flux 架构， 前端开始脱离历史的影响， 我们发现， 不是前端没有架构， 而是还没我们被创造出来。

大厂技术上的束缚， 迫使我离开寻找新的平台， 这个世界在快速变革， 但不是所有平台都能适应这种变革， 也不是所有平台能发挥出每个人的能力， 作为工程师， 我们不光为钱， 也为一点点情怀， 改变世界， 即使一点点。

17年， 我离开大厂， 加入一家准上市公司负责前端架构的工作， 翻了翻拉勾， 前端架构师开始进入我们的视野， 虽然比起传统意义上的架构师， 岗位还很少， 但是欣慰的已经不是那么凤毛麟角， 前端规模化的增长， 对架构师的需求开始反推企业改善现有的团队架构， 引入架构师更好的解决问题。 这个阶段， 思考架构开始变得不这么磕磕碰碰， 充足的知识和经验储备， 让我开始建立起自己的架构思维， 得益于对 Flux 架构的应用， 我发现很多前端领域的问题可以用一个环来解决， 我称之为“环形架构”， 或者“流水线架构”，把同一纬度的数据放在一个环中去处理， 前端复杂的数据流可以被很好的隔离和管理。

就如本文开头提到的， 我所看到的这个代码的世界， 开始有了层次， 有了架构， 开始有方法去解决混沌和无序， 而我想这其实也仅仅是架构师生涯的开始， 后面的阶段应该叫 ［ 架构师思维的发展 ］了吧。