这篇文章主要还是阅读所感，总结出来共勉，不喜勿喷，也欢迎有不同意见的指教。
首先，主要是以问题起步，如何成为一个优秀的架构师？
这个问题主要分成两种情况，其一就是所谓的面霸架构师，其二则是领导眼中不可或缺的人。
第一种，只要经历过项目的架构，并且理解项目背后所要解决的场景问题，以及把里面所用到的技术背后的原理搞清楚，那么你就是一个面霸架构师，可是面霸架构师并不一定就是领导眼中不可或缺的人。那么问题就来到了，如何成为一个领导眼中不可或缺的人。
以下以一个大佬的真实经历来解答这个问题。
ps: 下文中的我指 xx 大佬。
无关职责，帮助领导解决技术难题
第一个经历，我工作第三年的时候，认识了一个老板。某个周六，他打电话给我，说他们的系统碰到了一个问题，做了某一个操作之后，整个页面就会冻结，怎么点都没有用，他们的技术人员没有头绪，客户也一直在催，让我赶紧帮忙看看。
我打开看了一下，的确是做了操作之后，整个界面都无法点击或者输入信息了，然后我重现了很多次问题，发现整个界面冻结的时候，好像颜色有点不一样，会不会是一个透明的浮层置顶了？最终确认，确实是 bug 造成浮层没有退出。
那么为什么他们的技术人员都没有头绪？因为他们主要是后端开发，js 工作经验比较少，而我的经历也属于偏向后端，可是我能跟领导说，这个问题不属于我的专业范围，因为我是做后端的吗？
领导并不会在乎你的职责是什么，领导喜欢的是可以帮他解决技术难题的人。
总结: 要有能够帮助领导解决技术难题的能力（无关职责）。
理解领导的非技术难题
第二个经历，这是我在外企当中碰到的一个问题。
有一天，公司的领导过来问我，"你有没有觉得我们的开发速度很慢？是不是我们的技术不行？"
"您能跟我详细说说，是哪些地方慢？"
"产品部的人跟我说，他们现在提一个需求，经常要好几个月才能上线，有时候一个简单改文字的需求都是这样。"
这个问题确实不好解释清楚，因为这次沟通一开始就不在一个维度上。开发人员认为，说开发速度慢，应该是指开始开发到最终上线的时间久。可是领导认为，一个需求从提出到最终上线的时间久，就是开发速度慢。
那么开发速度慢算是一个技术问题吗？可以算，也可以不算。那么最终如何解决？开发团队最终一起讨论列出了所有影响开发效率的问题，然后能用技术解决就用技术解决。
所以有时候领导跟你谈的问题并不是单纯的技术问题，你需要把领导的问题转化成技术可以解决的问题。
总结： 理解领导的非技术难题，并最终转化成技术可以解决的问题。
搞清楚领导对你的期望值
可能有人会想，开发效率低这种事情不应该找架构师，这是管理的问题。下面接着说第三个经历。xx 公司系统用了 4 年，架构相对比较老旧，然后有一个新的项目，需求比较多，一位架构师提议，趁着这次的需求把架构更新一下，
然后就跟领导仔细讨论了架构更新的代价和好处，最终达成了一致的意见。
可是任何一个项目都会有各种各样的变数，比如业务方的临时需求变更，再比如有些系统可以不用迁移，只需要对接一下，也会有有一部分人不熟悉新架构，就需要多花一点时间去学习，最终项目延期了。
某一次会议，领导说架构师不行，这次系统上线以后如果不稳定，就把架构师开了，主要还是因为项目延期了。开发也解释了一下不全是架构师的问题，还有一些需求变更，可是领导认为需求改动不大，不至于延期一两个月。然后开发团队私下商量着保住这个架构师，不能让他一个人担责。
后来一次聚餐，领导解释他的压力也很大，本来跟老板说好可以按时完成，结果拖了这么久。
事后团队回顾了一下，这件事情之所以是架构师担责，其实最重要的一个原因就是老板对架构师的期望值是什么，是开发效率，系统稳定性保障，还是复杂问题的突破？
所以整件事由架构师承担的原因就是，大家对架构师的期望值是不一样的。所以，作为架构师最重要的一点就是要明白公司对你的期望值。
总结: 明白公司或者领导对你的期望值。
最后
当然，以上经历并不能代表所有公司的评判标准，并且架构师的优秀也有很多维度可以讲，但是这三个故事可以给我们一些启发。
- 要有能够帮助领导解决技术难题的能力（无关职责）。
- 理解领导的非技术难题，并最终转化成技术可以解决的问题。
- 明白公司或者领导对你的期望值。
以上的三个要点，个人也比较赞同的。