前言
知道做架构师最头疼的是什么, 自然是画图.
最难画的图是什么图, 叫现状图, 之前看到一个蚂蚁的离职 P7 用代码屎山来形容老代码, 我想说维护这些都不算啥, 你有本事把这屎山画出来试试...
做了几年架构师, 我明白一个道理, 架构图就是充满美感的, 描绘屎一样现状的架构图是不存在的, 因为现状没有架构, 没有架构你怎么让我画图, 那不是为难人么.
所以如果有老板让你用图说明现状, 请让他自己画.
正文
写这篇文是为了理清楚我做架构师这几年遇到的一个灵魂问题, 如何把那么完美的架构设计, 成功的扣在屎山上, 然后净化它, 扣了多年的我, 貌似终于扣出了点味道
"舔了舔手指, 是内味了"
架构设计, 现状梳理两步走
作为架构师的主要工作之一就是摸清楚业务现状, 然后在架构设计中做出取舍和权衡, 打造一套适合业务的架构, 并且落地实施, 但这种方式仅限于小规模的团队和相对不那么复杂的项目, 当你承担的是一个近百个前端工程师几十条业务线共同维护的巨型项目的架构设计工作, 这么做就有点力不从心了, 经过一段时间的实践, 我发现还是有办法的.
那就是先摸一摸业务的轮廓, 然后开始架构设计, 将业务的部分放在较小的区域里, 先设计业务无关的部分, 将业务相关的锁定在特定的层里面, 不管他.
另一边召集业务核心开发和业务线的架构师, 开始技术架构治理的摸排工作, 主要两条线
- 控制增量
- 梳理存量
控制增量
针对增量问题, 例如新项目, 新的集成和对接, 技术重构等进行严格的评审和技术管控, 作为总架构师你需要亲自参与这些增量问题的评审和相关会议, 然后对这些项目和技术方案的评审把握一条精髓 "有规范的按规范来, 没规范的按现存方式, 不准玩新花样", 务必把业务上的增量问题控制在可控的范围, 避免扩大存量问题的基数.
梳理存量
增量那一头一锤子买卖, 暴力解决, 存量这里就得慢工出细活, 一条一条梳理, 根据你目前设计好的架构预期, 预设落地的条件, 比如要落一个微前端的架构, 可能就需要梳理清楚
- 基于微前端中的应用定义, 目前哪些业务实际情况是超出了的
- 现状中, 不同业务之间是如何互相嵌入的
- 接入方需要为被接入应用提供哪些能力等等
梳理存量要以架构落地的必要条件为准绳进行梳理, 这样一旦梳理过程中发现和落地的必要条件之间有严重冲突, 那可能就需要调整设计方案, 同时考虑如何解决冲突, 上个图
截屏2020-06-23 下午5.27.09
找出架构设计中的落地点
一套架构必然包含很复杂的层与边界, 架构设计落地毕竟不像盖章, 一戳子下去就完事, 我们需要找到整套架构中的落地点, 这个落地点就是整个架构设计中用来包裹业务的那部分.
依然是以微前端架构举例, 微前端架构要落地, 其核心的落地点是应用, 即需要先定义清楚什么应用, 应用对业务的控制是一个什么程度, 业务线要做哪些改造来将自己变成你架构设计中定义的那个应用, 在架构的其他部分, 应用管理, 应用治理, 发布构建等等落地之前, 必须先搞定这个落地点, 只有将业务收敛在你定义好的应用内, 才有可能落地你设计好的这套微前端架构
俗话说, 万事开头难, 这一脚踩稳了不说成功落地把, 但至少赢了一半.
后话
架构设计落地是比架构设计本身更加考验架构师功力的地方, 本文总计的关键点主要是这几条
- 架构设计, 业务信息收集两手抓, 两手都要硬
- 设置架构落地必要条件, 落地前不断 match 业务现状
- 找准架构落地点, 以业务为基础的单元
- 架构落地的每一步无论怎么小心都不为过
本文使用 mdnice 排版