15｜模块导读：互联网时代架构师都面临哪些新挑战？

架构活动中如何跳出招式的套路，做到无招胜有招。有什么评判的基本原则？ 《生活的艺术家》中，李小龙是这么说的，招式所提供的答案，正是问题的症结所在，他为我们的自然成长设置了很多限制和障碍，妨碍了我们真正理解知识。他也是主张放下招式的。而在他的只言片语中，可以看到他有一条决策依据，就是效率。他说，越接近功夫的真谛，冗余的表达就越少。中国功夫里有些招式太过注重装饰，习武者往往因为动作的优雅和花哨而忘乎所以。 那架构设计呢？有没有相似之处？是否也可以从武功的练法，演法，杀法三个场景去划分。不同场景有自己决策招式的底层落地/原则。

🤔☕️🤔☕️🤔 * 📖：一个架构活动，可能上百甚至上千人参与，架构师要明确，什么事情自己应该做，什么事情其他参与者来做 * 🤔：这个参与数量，有点惊到我，老师能否举个例子，让这个恐怖的数字，有个可想象的实际情况。 * 🤔：架构师主导架构活动，这个能理解，成千上万人参与到架构活动，他们的角色是什么，也是架构师嘛，好像说不过去，可参与了架构活动，又不是架构师，好像还是说不过去。 * 📖：架构师的作用：建设共识、控制风险、保障交付、沉淀知识 * 🤔：沉淀知识，按理说是这几项里难度最低，可是我猜测，大部人架构师做不到，包括我自己。最近几年学习些技术外的所谓的多元思维，逐步掌握一个叫逐字稿的方式，慢慢发现脑子里想的东西，跟最终能用文字和图形表达出来的东西，差距不是一般大。更重要一点，放在脑子里的东西，总以为自己记得很清晰。实际上，当自己今天把它写下来画下来，过半个月来看，经常疑惑起来，这确定是我之前写写画画的东西嘛，看起来还挺不错，幸好当时抓紧记录下来。这就是我正在掌握和实践的知识沉淀法，凡事觉得重要，觉得以后必定还会有人来问我，或者必定我还要讲给别人听，那么我就会用逐字稿的方式去记录下来，提前模拟跟对方讲一遍，亲测有效。

很惭愧，这篇文章我是读了两遍后之后才找到自己的理解，也是因为自己再对之前的架构活动总结反思的时候脑子里突然闪现东白老师的架构师能在架构活动中起到的四个关键作用，才发现之前对建设共识、控制风险、保障交付、沉淀知识的理解不够深刻，正如东百老师提到的学习方法：先固化，再内化，最后才优化。 我自己共鸣最大的两点还是建设共识和控制风险，虽然我之前的架构活动只有几十人参与，但是也牵涉到跨公司、跨组织的协同，在前期建设共识过程康威定律再一次印证，不同团队的业务、技术背景不一样、架构活动的角色不同，导致大家对于目标的一致性很难统一，架构师要花费大量的心力去统一不同团队的上下文，前期沟通效率极低；另外一个是关于控制风险，虽然架构活动也都会有项目经理的参与，但是项目经理对于风险的控制主要还是集中在资源和业务交付内容，但是实际软件交付质量的核心要点、关键要素、核心人员安排只有架构师才能洞察，才能做出关键的风险预案； 后面东白老师针对架构活动全生命周期的每个节点还有更系统的介绍，自己要多思考，结合自己之前的经验教训，不断内化吸收，形成自己的架构指导方法。

听了这一课感觉架构师和项目经理的职责有重复，PMI要求在项目启动阶段和收尾阶段要做的事也包括这些，看来不会做PM的程序员做不好架构师

对于在多个团队协作的情况下，如何能够有效建设共识？往往都是各方僵持不下

“上百人甚至上千人参与的架构活动”，很是壮观，不过对我来说，公司上下也就七八条枪，不到二十个研发。 “以分布式为主的互联网研发活动”，我这边是以单体架构为主的传统软件研发，叹一口气。即使是这样，技术债其实也不少。 不知道今年的双十一会怎么样。 建设共识、控制风险、保障交付、沉淀知识，这四条即使在我们这样的小团队，也同样适用。 八个节点里面印象比较深的是“搭建架构环境”和“正式启动”两个，其中项目管理中也强调项目章程和项目启动会议的重要性，有些类似。

文中提到你有一套固定的架构规划模版，能不能分享下？

"不过在初学时期，我会想办法把完整的流程多跑几遍，将每个节点及其底层逻辑烂熟于心。然后再根据具体项目、工作环境和参与团队来做精简。不要连基本的招数都没学会，一上来就想着无招胜有招" 我理解这和我们小时候咿呀学语一样，最开始总是模仿父母或者其他人的发音，慢慢的这些会形成我们的“记忆”，最终会形成一套适用于我们自己的“语言”

干货满满。要是再上多点表单，感觉就是麦肯锡团队的工作风

一开始用模版，到不用模版，是先固化再内化最后再优化。