第18章 结束语：如何成为不可或缺的人

如何成为一个优秀的架构师？这个问题其实分为两种情况：

1. 面霸型架构师
2. 领导眼中不可或缺的人

对于第一种，如果你做到以下两件事，很大概率可以做到：

• 认真学习16次架构经历，完全理解背后要解决的场景问题
• 把里面用到的技术及其在这些经历中用法背后的原理搞清楚

下面主要讨论如何成为领导眼中不可或缺的人。为什么把这两个问题分开谈？因为面霸型架构师不一定就是领导眼中不可或缺的人。

下面讲几个真实经历。

18.1 无关职责，帮领导解决技术难题

工作第三年的时候，认识了一个老板，他有个做国外外包的公司，觉得我技术不错，一直希望我加入。不过我没答应，只是愿意给他兼职当顾问。

某个周六，他打电话给我，说他们的系统碰到一个问题，做了某一个操作后，整个页面就会冻结，怎么点都没有用，他们的技术人员没有头绪，客户一直在催，让我赶紧帮忙看看。

我打开看了一下，的确是做了操作后，整个界面都无法点击或输入信息了。然后我重现了很多次问题，发现整个界面冻结的时候，好像颜色有点不一样，会不会是一个透明的浮层置顶了？

最终确认，确实是bug造成浮层没退出。

那么为什么他们的技术人员都没有头绪？因为他们主要是后端开发，JS经验比较少。看了我的经历，你应该猜得出来，其实我也是偏后端的。

可是，你可以跟领导说，这个问题不属于我的专业范围，因为我是做后端的吗？

核心观点

领导不在乎你的职责是什么，老板最喜欢的是可以帮他解决技术难题的人。

18.2 理解领导的非技术问题

再说第二个经历，这是在外企碰到的一个问题。

有一天，公司的领导过来问我："你有没有觉得我们的开发速度很慢？是不是我们的技术不行？"

"您能跟我详细说说，是哪些地方慢？"

"产品部的人跟我说，他们现在提一个需求，经常需要好几个月才能上线，有时候一个简单改文字的需求都是这样。"

这个问题确实不好解释清楚，因为这次沟通一开始就不在一个维度上：

角色	对"开发速度慢"的理解
开发人员	开始开发到最终上线的时间久
领导	一个需求从提出到最终上线的时间久

另外，开发速度慢算是一个技术问题吗？可以算，也可以不算。

最终怎么解决？

开发团队一起讨论后列出了所有影响开发效率的问题，然后能用技术解决的就用技术解决。

问题	技术解决方案
需求排期等待时间长	优化需求管理流程，引入敏捷迭代
测试环境不足导致等待	容器化测试环境（参考第17章）
联调等待第三方接口	Mock服务（参考第16章）
发布流程繁琐	CI/CD自动化流水线

核心观点

有时候领导跟你谈的问题并不是单纯的技术问题。你需要把领导的问题转化成技术可以解决的问题。

18.3 弄清领导对你的期望值

可能有人会想，开发效率低这种事情不应该找架构师，这是管理的问题。下面接着讲第三个经历。

公司原来的系统用了4年，架构相对比较老旧。然后有一个新的项目，需求比较多。

一位架构师就提议，能不能趁着这次的需求把架构更新一下。之后，他就跟另一位负责这个项目的技术总监仔细讨论了架构更新的代价和好处，最终达成了一致的意见。

然后，他们一起将这个提案给了CTO，向CTO陈述了新架构的好处及代价：

• 代价：多花3周的时间
• 好处：以后系统会更稳定，问题更少，迭代速度也会更快

CTO是产品经理出身，爽快地同意了，然后团队就开始了如火如荼的项目开发。

意外的变数

当然，任何一个项目都有各种各样的变数：

1. 业务方临时的需求变更：他们之前没考虑清楚，还有一部分流程的遗漏，这部分遗漏必须解决，否则系统无法使用
2. 系统迁移范围扩大：原来决定不迁移的某个系统，因为数据库耦合的原因也必须迁移
3. 学习成本：部分人员因为不熟悉新架构，就需要多花一点时间去学习

最终，项目果然延期了。

责任归属

某一次会议期间，CTO就说："咱们的架构师不行啊，这次系统上线以后如果不稳定，就把他开了。"

开发这边惊讶地问道："为什么？还有其他的原因吗？"

CTO说："你看这次项目，本来要一个半月做完，因为加了新架构的迁移工作，变成两个多月了，现在都快拖到三个月了。这明显是架构师的问题，早知道这样的话，还不如不换新架构。"

然后开发这边就帮忙解释道："这其实不全是架构师的问题，项目中不是还有一些需求变更吗？"

CTO说："我知道，但是那些需求我看了，改动不大，不至于拖期一两个月。"

开发这边都沉默了，心想："当初迁移新架构，领导也是同意的。"

背后的原因

后来一次聚餐的时候，CTO跟开发团队解释道，他的压力也很大，本来跟老板说好可以按时完成，结果拖了这么久。关于架构迁移，老板原来是同意的，可是第二个月他已经忘记这件事了。老板对软件研发没什么概念。

团队事后回顾了一下，这件事情之所以是架构师担责，其实最重要的一个原因在于：老板对架构师的期望值是什么？

• 是开发效率？
• 是系统稳定性保障？
• 还是复杂问题的突破？

而这整件事情会由架构师承担的原因就是，大家对架构师的期望值是不一样的。

核心观点

作为架构师最重要的一点就是要明白公司对你的期望值。

18.4 小结

这就是我的3段经历。当然，架构师的优秀有很多的维度可以讲，以上经历并不代表所有公司的评判标准。

成为不可或缺的人的三个要点

要点	说明
解决技术难题	无关职责，主动帮领导解决问题
理解非技术问题	把领导的问题转化成技术可以解决的问题
明确期望值	弄清楚公司和领导对你的真正期望

希望这些分享能给你一点启发。当然，如果能够让你感同身受，那将是我最大的荣幸。

---

全书总结

本书通过16次真实的架构经历，从5个维度讲解了软件架构设计：

部分	主题	章节
第1部分	数据持久化层场景实战	冷热分离、查询分离、分表分库
第2部分	缓存层场景实战	读缓存、写缓存、数据收集、秒杀架构
第3部分	微服务场景实战	注册发现、链路追踪、熔断、限流
第4部分	微服务进阶场景实战	微服务的痛、数据一致性、数据同步、BFF
第5部分	开发运维场景实战	接口Mock、一人一套测试环境

只有先懂场景才能学好架构，相信看完本书之后，无论是在全局的架构思维上，还是面试时的思路展现上，抑或工作难点的突破上，你都会得到全面的提升。

一起学好软件架构，尽快成为一个优秀的架构师！