某年 某月 某日, 某司在一个月黑风高的夜晚, 刚刚结束了本年度的第一次前端技术架构 Review
最近跟老板们一起开会的频率有点高, 涉及方方面面, 有面试标准相关, 也有像这次的纯技术会议, 一群架构师和TL们聚在一起, 比比谁的 PPT 做的更丑 :(|)
架构师干久了, 遇到的问题也会越来越多, 就拿架构 Review 这件事来说, 在开始之初, 其实我们是不知道, 也并不明确, 究竟要 Review 什么? 架构 Review 的意义又是什么?
刚开始, 我这么理解架构 Review
"要求架构师对团队的技术架构进行 Review, 相关问题包括但不限于 1..2...3...4", 刚接到这项工作的时候, 其实是整个技术部派发下来的要求, 还专门为我们准备了一本小册子, 但说实话, 我是抗拒的. 因为从白皮书上看, 10条里只有1条和我们前端有明确的关系和要求, 那就是 web开发安全措施...于是我只能从自我的角度出发去理解架构 Review 在前端这领域应该做什么, 我思考了很久, 想到一件能做的事情, 那就是对团队技术现状的梳理, 就跟搞装修的, 先得找到之前的结构图, 知道哪些能动, 哪些不能动, 其实技术架构有异曲同工之妙
举个例子, 我之前的团队, 有一个 http 请求模块设计的有问题, 就是每次发送请求之前都会 new 一个新的实例, 保存 headers 之类的配置, 这导致多次请求后应用的内存消耗的非常快, 但其实重构的难度不小, 就像承重墙, 这种底层模块一般改起来就是牵一发而动全身, 如果不能有一个对这个模块的依赖和使用情况的清晰文档, 一个不小心可能就导致无法预测的 bug.
所以对技术现状的梳理, 找出现状中的问题, 进一步思考解决方案, 从而配合业务节奏将方案落地, 这是我对架构 Review 这件事本身的初步理解.
事实证明我的理解没有错, 但不是全部, 而且我想的太简单了...
我按照自我的理解, 对团队的技术现状进行梳理, 但遇到了非常大的困难, 首先代码多, 文档残缺不齐, 基本靠读, 注释又少, 仓库分布广泛, 涉及的三方二方技术更是让人抓狂, 这就跟你在一个已经运作多年的商业大楼里, 手拿尺子去量结构图一样, 只有痛苦.
为此, 我迅速调整了策略, 因为我是一个推崇效率工作, 不喜欢低效加班的懒人 :(|), 我找到产品进行了沟通, 我心里想要的是业务接下来的规划和节奏, 从而确定我在技术梳理的工作上的切入点. 这个方案不错, 和产品做了充分沟通, 又找了运营聊一聊, 再和后端吃个饭, 我心里基本有了一个大致的框框, 将那些老旧的系统打上标记, 这是老旧资产, 暂不梳理, 找出核心代码, 梳理的工作量大大减少, 最后我做了一份还能看的 ppt, 参加了第一次架构Review.
被打回的 ppt, 视角不够全面
很蛋疼的被老板拍了回来, 原因是没有横向去做梳理, 比如一个功能模块, 其他团队是否有开发过, 他们的情况如何? 具体的 case 类似人脸识别这种相对通用的功能. 我和兄弟团队的架构师 / 核心开发做了一次深入的, 四菜一汤的沟通, 大家就如何进行通用功能的规范化合作达成了友好的协商, 顺手各自完善了下各自的 ppt, 事实上到这一步, 我们都完成了这一次的架构 Review, 交了作业, 事后我总结了下, 这次架构Review 工作主要是两方面.
- 对核心技术现状的梳理, 找出问题, 给出具体的方案, 论证方案的合理性与可行性, 配合业务节奏实施落地.
- 横向梳理兄弟团队之间的业务关联, 技术架构现状和规划上的交集, 找出能够共建和复用的技术点.
相应的架构 Review 的作用也有 2 点
- 为团队的技术发展找出一条优先路径, 并实现.
- 一定程度上避免技术资源浪费, 减少不同团队之间无意义的轮子, 寻求技术资源效率最大化.
但是没完, 很快第二次架构 Review 开始了
老板之所以是老板, 就是因为他的套路你猜不到, 被套路了你还得感激他, 因为你又学到了新知识
本以为轻车熟路的我们, 在新的一轮架构 Review 中再次翻车, 因为标准又提高了, 这次不仅仅是之前提到的 2 点, 好要求要有清晰明确的技术架构规划和落地计划, 包括可预估的时间点和完成情况, 这对于刚被调到新事业部的我来说, 无疑是个致命打击, 因为我还忙着从头梳理前两点, 无奈之下, 我只好用日常开发中做的技术方案的 issue 链接放在 ppt 中, 你可以想想, 这是一个包含大量外链的 ppt, 好不好全凭一张嘴. 这里我倒是顺嘴提一句, 很多程序员对于架构师嘴皮子这件事颇有微词, 但实际上对于架构师这个岗位来说, 你能不能清晰的表达你的观点, 你的讲述是否具备一定的感染力, 还是有必然的要求的, 同时 ppt 的制作能力也算是一个硬性的指标吧.
第二次架构 Review 并没有经历第一次那样频繁的打回重写, 毕竟老司机 :(|)
这一次我就不叙述过程了, 直接总结吧
在第二次架构 Review 中加了一个比较坑爹的互评环节, 当然老板的本意是希望架构师之间多一些观察和交流, 但直接 diss 彼此的 ppt 还是略显凶残了点, 好在大家还是比较克制且客观的做了评价, 没有变成全武行, 在之前两点之上, 我们对架构 Review 的要求又增加了几条:
- 有明确的技术架构规划和演进路径, 任一技术产品的要有版本路径, 且具备可行性
- 技术架构的规划在一定程度上应该领先业务的发展, 通俗地讲, 跑到业务前面去.
相应的作用也有几条:
- 避免一次性的技术产品, 比如这次做了脚手架 1.0, 就没后续了, 不断重复的造轮子, 技术产品规划上没有任何延续性, 无法演进, 这样的技术架构/产品是明令禁止的.
- 这点主要是需求到业务到研发存在滞后性, 如果不能打提前量, 那就只有加班啦....有时候加班也不一定能搞定, 另外也不利于后期发展出能驱动业务的创新型的技术架构/产品.对公司而言, 研发的投入成本无法产生足够的效益.
- 对于老板而言, 通过架构 Review 对齐了研发团队之间的技术标准, 路径, 大框架, 同时也明确了一个架构师主要的工作职责, 不至于各自为政, 越跑越偏, 收不回来, 达成管理上的目标.
最后补张图, 来说明我理解的架构师和TL之间的差异
打个小广告：挖财 无线 & 前端团队求贤若渴，如果你喜欢各种新奇的 Cool 的技术，喜欢捣鼓各种工具， 喜欢研究架构，本团队提供各种环境和机会，欢迎简历来投，流程超快，当天出签，急速入职！！！