一周之前买的这本书，每晚看一点，到今天翻完了。之所以看的这么快（我读书速度挺慢的），是因为书里有很多内容我感觉没必要细看，有些内容是普及概念的，有些内容是离我比较远的。不过，有些内容还是很令我印象深刻的。
（原文链接 juejin.cn/post/685457… ，未经允许禁止转载）
脱离业务的架构，就是耍流氓
什么是架构，什么是架构师？这个词、这个概念，众说纷纭，我们要去没必要非得去讨论出个定义。
不过书中提到一个观点：无论架构和架构师如何定义，它都必须是依赖于业务的，而不是依赖于技术的。我也觉得这一点非常重要。
无论你会多少编程语言，多少流行框架，造过多少轮子，原理源码的了解多深，工程化多熟练…… 只要你不了解这个公司的业务，或者干着和业务无关的工作，你的工作都和架构不沾边。
技术人员对待不同技术是有区别的，对自己喜欢的技术是有感情的，也会有自己不喜欢的技术。所以大家会为了“php 是不是最好的语言”吵群架。而且，技术人员喜欢追求新技术，实际工作开发时恨不得把网上热门的新技术都用个遍，感觉这才能体现出自己的与众不同。
架构师会很冷静、很平等的看待所有技术。他们会深刻思考业务流程，看看哪些技术能满足需求，而且会考虑使用成本、效率、稳定性、未来可扩展性等。而不是考虑这个技术是先进还是落后。总之，所以技术都是平等的，所以技术就是为业务服务的。
“不写代码就没有资格叫架构师” —— 这句话也不完全对。认真观察你会发现，越是级别高的架构师，越关注抽象的业务，就越有可能不是程序员出身。
架构师要权责匹配，因为架构的关键并不仅仅在于设计，而在于执行。如果权责不相等，那在实时执行、监控时，就有可能走歪了，或者根本执行不起来。
例如，架构设计时要求项目流程必须有 code review ，如果架构师没有权利要求大家去 code review ，那大家就会敷衍了事，或者干脆不积极参与。
所以，书中所讲的，一个组织真正的架构师就是 leader，而不是具有架构师头衔的人。那些手拿摇扇，指点江山，只出谋划策却没有实际权利的人，不算是架构师。
但是实际情况是，大部分情况下 leader 没有那么多精力去参与设计和执行监控，所以部门才会有一个架构师的职位。这种情况下，我见过比较有效的方式是：leader 在给员工评价绩效时，会非常看重架构师的意见。这样其实架构师就变相的有了点权利。
做架构的背景肯定都是业务复杂，参与人员多的情况。人员一多就涉及到人员组织结构，组织结构如果和架构不匹配，就会严重影响项目执行时的沟通。而后可能还有甩锅、打太极、护食分粥等高级动作。