.. Kenneth Lee 版权所有 2021
:Authors: Kenneth Lee :Version: 1.0
架构的改革属性
这个文档原来的在公司内部博客里写的，里面很多信息都设计内部的东西，不适合在这里 总结。那个文档修改几个版本后，我对这个问题有更清楚的认识了，所以我可以不需要那 些例子就把问题说明白。本文就是这样描述的一个版本。
开发一个大型的产品，涉及很多的部门，市场，销售，法务，客户支持……当然还有我们做 架构最熟悉的，研发。而研发也不是只有一个部门，软件，硬件，芯片，外观……每个领域 还有不同的开发组。每个不同的部门，不同的人，都有自己不同的身份。一位后端工程师 ，可能同时也是一个家庭的儿子，母亲，兄弟姐妹……这些人要履行自己的角色，就需要不 断面对这样一个问题：我下一步干什么？
比如说，你一大早起来，老婆说今天约了律师讨论我们家房子和物业打官司的问题，儿子 说今天春游，要你送他去集合点，而你还想起昨天晚上越了投资委员会的人沟通你的项目 投资方案……你马上就面对这个决策：现在干什么？
和软件一样，我们这个世界上每个决策都是个逻辑问题，而逻辑之间是会冲突的。人们心 底上很容易有这么个希望：如果不用选就好了。但不选他们会后悔，比如，把律师的约会 推到下周吧——结果后来案子过了追诉期了，到时你就后悔了：如果那天不去开投资人的沟 通会就好了。但如果时间可以重来，那天你你去了律师那边，跟物业打赢了官司，但你公 司的投资没了，你会不会又说“如果当初不去律师那里就好了”呢？
所以，很多人都会趋向于为结果解释：“（既然都选择了见投资人），不去律师那里还是有 道理的，这种官司，本来就很难赢。而且，得罪了物业，以后日子都不好过，赢了又怎么 样呢？而且，虽然告不了物业，你看，现在做这个项目，赚的钱都不知道有多少，那个官 司怎么和这个比？……”
为结果找理由，总比为不可知的未来设定逻辑要容易得多。前者是确定的，只要找理由就 行，后者是变化的，要无时无刻维护自己的逻辑链，还不一定对。
但事前权衡，是你事后不会错的原因。提前分析见律师的收益和见投资人的收益，改变我 们后见所有的投资。当你开始深入思考这个问题，这个决策可能就很简单。比如你可能发 发现：见投资人最坏的情形是不能告物业，最多损失1万块钱，见律师最坏的情形是这个项 目启动不了，可能会延迟3年，你这段时间可能就没有好业务可以上了。这样这个问题就很 好判断了，你向这个方向去解决问题就好了。
这是这个问题的核心模型。我之前解释了很多“不要写‘我没错’的文档”，“不要在完成代码 以后写设计”……所有这些描述，本质就是这个问题。架构设计是事前的权衡，不是事后的解 释。
我过去对当架构师有个说法：当吉祥物，还是当架构师。当吉祥物呢，就是事情随便干， 干成啥样都解释“这是有道理的”。这操作起来一片祥和，心理感受很好，但基本上就和做 架构没啥关系。当架构师呢，直面选择，心理上就让所有人难受，追求最终的选择胜利。
所以，架构师不犯错，不吵架，一切都运筹纬幄，这必然是个吉祥物。
把这个问题想得大一点，对于产品的所有的参与者来说，每个人其实的都不希望变化，因 为变化就意味着额外的风险和思考成本。所有如果架构师什么都不管，让整个组织每个人 本来干什么就干什么，看见什么问题舒服就解决什么问题。这个架构师就是多余的，他就 变成了吉祥物。有他没他都一样，这不就是浪费钱摆这么个角色在这里。
如果不是，那么，我们面对的就不是简单的前面说的这个自己觉得见律师还是见投资人还 是送儿子的问题了。我们面对的是一个组织，任何一个改变，都会让一个开发组受损，让 另一个开发组受益。这就变成你死我活的政治斗争了。
所以，架构就不是个简单的技术问题，没有脱离了人和组织的架构。如果你做架构仅仅是“ 说说而已”，“反正我已经写了文档了，他们执不执行就不是我可以控制的了”。架构工作本 质上是个改革，变法一类的工作。就没有平平和和，皆大欢喜一说（当然，我们努力去向 这个方向靠，所谓和大怨，必有余怨么），我们常常觉得架构工作不好做，觉得“得不到支 持”，“大家都不听教”，很多时候是因为我们对架构工作的困难认识不足。
以我的经验，在企业中，如果要做架构，我首先会去测试领导层的决心，因为对于企业来 说，大部分只是打工的，领导者的作用是第一位的。如果领导层没有这个压力和决心，这 个事情大概率不行，这个事情就干脆别开始。
当然，这同样是看以哪个层次的目标，以什么时间范围为目标，没有一定的判断模型就是 了。