说起前端架构师，给人感觉上是一个高大上的名称， 每个初入行的前端工程师在面试时, 被问到你未来的方向是什么? 我们或许都会很顺口的回答, "嗯, 朝着架构方向走吧...", 那这个像是顺口溜的答案背后, 从身体到思维, 我们究竟经历了怎样的转变呢？其实转变不是一朝一夕的事，而是一种知识与能力的积累。
当我第一次看到架构这个词, 是在旧的翻了毛边的编程书上, 而此时对于我来说, 架构仅仅是一个词, 两个汉字和一堆概念. 而第一次我自己说出这个词, 是在14年, 那时转行写代码刚满1年, 对一个码农来说, 1年经验很浅, 无论是从思考还是手感, 都谈不上有太多积累, 但是当对面的面试官, 问道: " 你未来有什么发展方向? ", 我还是不假思索的说出了 : "朝架构发展吧... ", "你觉得什么是架构? ", " ... "
各种碎片时间下不断对架构的思考, 巩固了架构思维在我大脑中的地位, 促使我开始从架构的角度去看待问题, 需求和代码, 代码的世界是一种依靠逻辑维护的奇妙世界, 随着世界的膨胀, 各种逻辑变得难以维护, 最终整个世界崩塌, 但当我加入一点架构之后, 世界的结构开始清晰起来, 慢慢的我开始看到逻辑背后的联系, 代码背后的那些隐藏的轮廓. 尚学堂•百战程序员陈老师指出在这个世界里, 没有完美的架构, 自然也没有银弹, 不管如何调整, 维护, 设计和变更, 我们最终都会迎来这个世界的消亡, 但是一个有架构的世界, 即便是消亡也是有序的。
第一次尝试加入架构, 是在那次面试失败之后, 我手上有一个 SPA 的项目, 那时候 angular1.0 还没有发布, backbone 还在大行其道, 我依靠对架构的一点理解, 尝试自己去构建一个有序的代码世界, 结果显而易见的失败了, 因为我的知识和经验储备不足做出一个有效的架构, 但是这一次尝试让我明白了架构的重要性, 相对于 jQuery 时代的面条代码, 将代码合理分层显然能让这个世界显得更有序些. 无论是 MVC, MVW, MVVM, MVP, 都是对开发 GUI 应用如何更好的设计代码的一种尝试。
事实上, 在这个阶段, 我对架构的理解比起最初的时候更混乱了, 设计模式, 框架, 架构, 这些词在某一时刻互相混淆在一起, 傻傻分不清, 而有时候, 我会陷入究竟如何区分他们的困境中, 为了解决这个问题, 我阅读了一些书籍, 进行了更深入的思考, 我发现光靠这三个概念, 是不够的, 为了走出这个困境, 我发现必须引入新的工具, 这个工具叫上下文, 也叫语境。
随着工作的不断深入，也要接触各种新的概念, 我对架构的思考开始引入上下文, 我发现有了上下文, 模式, 框架, 架构就开始变得不那么格格不入了, 在某一个上下文中, 它可以是模式, 在某一个上下文中, 它可以是框架, 模式, 框架, 架构在上下文的组合下, 开始能够被灵活使用了, 它们成了我设计和思考架构的工具箱中常用的工具. 同时期, 我开始接触 UML , 另外还包括DDD, TDD 等一些概念, 还有常用的架构模式, 像六边形架构等等, 以及多了一种新工具"边界", 但是很快我发现我陷入了另一种困境, 一些新的工具很难被应用在以 JS 为基础的前端领域, 而光依靠模式, 框架, 边界, 上下文设计出来的架构很难进一步细化, 前端架构成了空中楼阁, 无法落地. 我尝试生硬的怼, 但最终是徒劳的, 看起来这一阶段变得更痛苦了, 没错, 就像一个埋头走了三千里, 原本以为是终点, 但抬头发现依然是一望无际的痛苦. 或许前端不存在"架构"?
在工作几年之后，我加入一家准上市公司负责前端架构的工作, 翻了翻拉勾, 前端架构师开始进入我们的视野, 虽然比起传统意义上的架构师, 岗位还很少, 但是欣慰的已经不是那么凤毛麟角, 前端规模化的增长, 对架构师的需求开始反推企业改善现有的团队架构, 引入架构师更好的解决问题. 这个阶段, 思考架构开始变得不这么磕磕碰碰, 充足的知识和经验储备, 让我开始建立起自己的架构思维, 得益于对 Flux 架构的应用, 我发现很多前端领域的问题可以用一个环来解决, 我称之为"环形架构", 或者"流水线架构",把同一纬度的数据放在一个环中去处理, 前端复杂的数据流可以被很好的隔离和管理。