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