前言
在展开做架构究竟比写代码难在哪之前, 我们先来讨论一些有意思的东西
"诶, 你们最近忙么..."
"忙死了, 天天加班到凌晨."
"你们那个架构师呢"
"别提了, 啥也不干, 就知道写 PPT.."
以上对话, 大家应该都比较熟悉吧..没错这些对话经常发生在公司食堂, 摸鱼路上, 厕所包间之间, 也是大多数一线开发普遍对所谓 "架构师" 的直接印象, 这种矛盾就如淘宝店家的卖家秀和买家秀一样尖锐
程序员心目中的架构师
- 技术大牛, 精通各种技术, 以一当十
- 头秃
- 掌握很多一般开发不能掌握的技术秘密
程序员现实中看到的架构师
- 天天开会, 就知道写 PPT, 画图
- 张嘴 高并发, 闭口 高可用
- 不知道 React 的生命周期, 写得代码也就那样
- 头秃
em, 🤔 看来唯一的共同点就 头秃
我在之前一篇文章 前端职业规划 - 如何从一线开发转职架构师 抛出了一个观点, 从正是成为架构师开始, 你面对的竞争将比原来做开发的时候激烈 10 倍, 不再给你按部就班的时间去成长, 你所面临的挑战从接受这个岗位就已经开始了, 为什么会这样?
因为成为架构师, 意味着你不再直接掌控细节, 这种摸不着代码的恐惧将一直伴随你.
我们都知道在军队中, 将军大多数都是一线士兵升上来的, 相比直接面对敌人作战, 将军要面对的是如何在摸不着刀枪棍棒的情况下依然能有效的指挥军队并赢得胜利, 这需要经验同时也需要天赋, 并不是所有的将军都是优秀的, 依然是 10 个里面有一个, 其余皆庸才. 甚至庸才干久了, 还不如底下的小兵
一个将军肥头大脑, 舞不动刀枪棍棒, 也不知行军打仗为何物, 但 10年前他可能是个一身腱子肉, 能冲锋陷阵的猛将.
所以架构师也一样, 成为架构师之后, 那种脱离技术细节的恐惧, 和不断发展的技术之间无法同步的焦虑时时刻刻都在摧残架构师的心智, 很大一部分就有可能变成 PPT 专家, 走上自我催眠和放弃的道路, 于是就陷入了写代码不如下面的高级开发, 做架构却只能面向 PPT 架构的职业窘境, 直到被时代淘汰.
所以不要小看大家眼中的 PPT 架构师, 他们曾经也是极其优秀的开发者, 并且成功建立架构思维转职, 只是在后续的竞争中逐渐迷失罢了.
让我们回到本文的关注的焦点
做架构究竟比写代码难在哪里?
无论多么伟大的前端架构, 其最小组成依然是代码, 底层是 01010, 这些就是架构的基础材料, 就像你盖房子总得和水泥, 总得掺沙子一样, 那为什么建筑架构设计可以脱离对水泥沙子的掌控, 只做图纸和上层设计, 但是到了前端架构就行不通了呢?
因为前端技术更新太快了, 快到还没充分掌握这些细节, 一些技术就已经落伍了, 你能想象么, 一个建筑设计师在做建筑架构的时候, 设计到一半, 工人告诉他你这个不行, 现在都不用这种材料了, 你那个不行, 这种水泥早就过时了, 现在盖房子都不需要浇筑了...
没法想象对吧, 设计师估计得疯, 怎么我做建筑架构十几年的一直用的都是这些材料啊, 最多有些新材料新工艺, 怎么突然就天翻地覆了, 这架构还怎么做??!!
但是这种情况在前端技术领域却真实发生了, 前端架构师面临的就是这种尴尬的境地, 动不动就更新的技术标准, 技术框架和各种各样对相同问题的不同的解决方案, 我这正用 HOC 做着一套架构呢, 什么 Hooks 不错? 好吧得研究研究, 诶 CTO 要开会, 只能业余时间搞了, 啊 孩子又发烧了...
前端架构师也是人, 在面对复杂的场景和不断变更的需求间, 他需要做很多工作, 但是前端技术发展的速度又倒逼他不得不去了解, 但是任何一种新技术你通过看文档, 不实际在业务中用一下你敢说自己掌握了? 即便你自己偷摸用 TODOMVC 试了一把, 但是真的运用在自己的架构设计中, 相比实际写代码的一线开发, 总是如隔靴搔痒一般感到心慌, 毕竟不像自己在当高级开发时候积累的丰富经验, 这种新技术只是浅尝即止, 有没有坑, 好不好用, 自己在架构设计中对这种技术的应用和理解是否正确, 一切都变得未知起来.
所以做前端架构设计如果使用的是你在高级开发期间积累的技术和经验其实不难, 只是思维转换而已, 但是难的是你在成为前端架构师之后, 失去了写代码的机会, 再也摸不到代码, 面对前端技术的快速发展如何让自己对技术的理解保持在高级开发的水准的同时, 又应用到架构设计中, 还要不断学习和提升自己的架构能力.
所以成为前端架构师的最大的挑战不是能力问题, 而是前端领域技术更新的速度导致精力跟不上, 随着时间的推移, 对技术细节的掌握逐渐失控从而无法有效的维护和设计架构
你做一线开发的时候, 遇到有前景的新技术都不一定能在项目中试, 作为架构师为了稳定性考虑, 这种操作就更不可能了, 所以你现在知道为啥很多高级开发做开发的时候技术挺牛逼的, 怎么当了几年架构师技术反而不行了呢?
将军不上阵久了也就舞不动刀了.
那这是无解的么? 当然不是, 要摆脱这种一边要做架构, 一边又要不断的维持对技术细节的掌握, 只有一条路, 那就是成为 "架构师的架构师"
我在另一篇文章中说过, 架构工作的本质就是构建边界, 保持边界能空间的平衡, 当你作为一线架构师, 面向开发的时候, 你要保持平衡需要做非常多的工作, 花费大量的精力, 因为不断更新的前端技术就是持续向边界渗出的压力, 当你无法在架构工作和技术细节的掌握上维持平衡, 就会坍塌, 你的架构生涯也会逐渐告吹. 所以这算啥, 这算是职业架构
架构无处不在
因此用架构思维来讲, 我们要降低维持平衡的难度, 就是必须往上再建立边界, 行程第二次空间来减少一线开发传达过来的压力, 这就是架构师的架构师, 你知道 阿里的 P9 吧, 大概就是这样的角色, 所谓为什么带前端团队的 P9 可以不是一个技术大牛, 或者对技术细节掌握非常好的人? 因为他跨过了一线架构这层压力最大的空间, 通过维持他和一线甚至二线架构之间的边界平衡就足以完成工作, 对这一级别的人来说, 已经是跳出细节看全局, 他们的挑战在于未知, 创新, 未来, 动向, 这是另一个维度的故事了, 当然我没到这么高的级别, 所以也不好跟你们描述那地方的风景了哈哈, 不过你要坚信, 挑战只会越来越大, 你越往上, 面临的挑战就会越难, 站的越高风越大, 这是亘古不变的道理
后话
本文致力于解释架构师和一线开发的工作上的区别, 以及探讨目前很多一线开发眼里的架构师为啥是那个样子的原因, 我希望如果你有一天成为架构师能跨过这道压力陷阱, 同时不做架构师一直做一线开发也是一条路, 其实从职业寿命上来说两者相差不大, 基本上一线架构师如果被这种压力击溃, 后续也很难有更高的职业成就, 只能坐吃山空, 吃往年经验的老本
所以人生也不是游戏, 不是简单的打怪升级, 成为前端架构师也不一定是更好的选择, 选适合自己的路, 对职业规划来说至关重要.
