美团徐泼十四年架构经验：过程质量和结果质量并重 ｜ ArchSummit
作者 ｜李慧文
徐泼：我毕业已经十四年了，从传统行业到互联网软件，涉及了通信、游戏、社交、汽车 O2O、旅游电商、实物零售电商和社区团购等行业。2016 年我加入了美团，先后负责美团酒旅供应链商品、到店商品平台、美团优选商品和物流架构，期间担任过 IC、团队负责人和架构师各种角色。目前是美团优选架构师，专注在物流领域的架构工作。
徐泼：优选物流和之前接触的架构相比，非常显著的特点一是物流系统是 B 端系统，二是物流领域是一个非常专业的领域，业务领域知识众多，业务复杂性非常高。优选物流系统是既有着互联网级别的高并发又有着企业级复杂性的特点。
如果按照过程和结果将 SQALE 质量模型进行分类，则过程质量包含 Maintainability、Changeability、Testability 和 Reusability，结果质量包含 Reliability、Efficiency 和 Security。之前的架构关注更多的是结果质量，而物流架构更关注过程质量属性，过程质量和结果质量并重。
徐泼：架构不仅是设计层面的事，也是执行层面的事。对于架构师而言，职责之一就是要保障架构的落地，这也是在团队里做架构工作的一个难点。之前《聊聊架构》作者王概凯曾提到，架构师需要有调动资源的能力来保障执行的落地，这点比较重要，但我觉得这不一定要通过直接的权力来实现，也可以由授权来实现。架构落地是多方面综合因素作用的结果，我认为需要关注四个点，方向清晰、方案细致、方法实用、多方利益均衡。
方向清晰是指架构师要有前瞻性，要能正确把握长远的大方向，并将之清晰地描绘给团队。
方案细致是指架构的方案除了要有宏观的上层设计之外，也要关注关键细节，而且应该提供多种方案的选型，综合多方面因素进行评估。
方法实用是指架构师给团队的架构指导不能大而空、不切实际，一定要以解决问题为目标。
多方利益均衡是指架构的选择是多种方案的选型，也是多种因素结合的 tradeoff。架构相关各个团队实际是不同的利益相关方，架构工作也是一项社交活动。架构师要尊重所有与架构有关的人，换位思考，理解各方的感受，求同存异，最终达成一致。
徐泼：业界对架构师确实缺乏明确的定义，或者说目前架构师的职责是没有一个统一的标准的，这往往和公司的性质、规模以及公司业务所处的阶段有关。我看到有一个关于架构师的描述我觉得还是比较普适的，从斯科特·佩奇（Scott E. Page）《模型思考者 (The Model Thinker)》延伸的关于架构和模型，架构师和模型思考者的关系。模型是对现实世界问题的抽象，模型思考者需要针对问题，看穿客观事物的本质，选取或构建合适的模型，推导出问题的最优解。
架构和模型相似，架构师和模型思考者相似。架构师的职责是定义问题并识别方向，创建、选择或调整架构，找到最合适的方法，从而最终推进团队解决问题。
架构质量的优劣从业务发展的维度来评判，一定程度取决于系统在应对变化时所需要投入的研发成本。拿 Martin Fowler 的话来说“架构师最重要的任务之一就是从设计中消除不可逆的决策”。所以我认为架构师的核心价值是通过保障系统的质量属性，提升业务支持效率、降低研发成本。
这里高质量和低成本看起来虽然有些违背常理的，但是在系统架构层面，高质量就是意味着低成本。业内有一些相关专项分析，对比高质量架构和低质量架构在增量功能迭代和研发投入时间的增长曲线，发现基于低质量的架构，在数周内就显现出研发效率的降低，而自此之后的时间窗口中实现同样的增量功能，高质量架构所需要投入的研发时间远低于低质量架构。
徐泼：在组织架构的设计上，国内外的架构团队组织形式大致可归为三种类型：顾问型组织、团队型组织和梯队型组织。
顾问型组织架构师主要承担专业顾问的角色；
团队型组织按组织形式可以再分为实线组织或虚线组织，按合作方式可以分为项目制或 BP 制；
梯队型组织比较综合，可以结合架构岗位和架构角色，设置架构师梯队，实现 TOP-DOWN 和 BOTTOM-UP 的闭环，保障架构和研发团队的协同。比如国外某些公司将架构师按照 Enterprise Architect、Solution Architect 和 Application Architect 来进行划分，形成一个架构的梯队。
徐泼：我觉得技术人在职业决策过程中，要认清自己的能力特点，并了解在职业生涯中有哪些角色可选择，不同角色适合什么样的人，提前确定好职业的发展目标并做好规划。
很多人会觉得 IT 行业是青春饭，寻求能快速从程序员、IC 到其他岗位角色的转型，转型过程中也会在架构师和团队管理者角色之间纠结。
不过，我认为，无论目标是架构师还是团队管理者，都是要不断构建自己的知识体系，将经验总结沉淀为方法。将一年的经验重复了十年的工程师，随着年龄的增长，职业上面临的就不是一个选择的问题了。
这次的架构师专题我们也邀请了行业内优秀的架构师和管理者，给大家分享 IT 从业者如何做职业选择以及他们的架构师成长的心路历程。
徐泼：我觉得架构师比较重要的能力是宏观思维能力、抽象思维能力和钻研能力。美团内部也常说架构师需要能“站得高、望得远、扎得深”。
宏观思维就是要考虑整体，站在更高的层次上去看问题。这是架构师区别于工程师的一个标志。技术研发人员遇到问题时非常容易钻入细节中，因此在平时可以有意识地锻炼，跳出细节先看整体，找到关键重点再深入细节。
软件项目永远不变的就是“变化”，抽象是应对变化的主要手段。抽象能力要求工程师能看得更远，将现有和未来可能的业务场景综合起来进行分析，做出相对稳定的抽象，预留架构的扩展性。
钻研能力要求架构师具备深入细节的能力，能够攻克软件项目中的关键难题。所以架构师一定是从一线工程师成长起来，且对技术有较高追求的人。
徐泼：工程师在成长的过程中既要掌握好专业基础知识，提升专业技能，也要提升技术视野关注行业发展动态。对于架构师而言，关注技术领域和相关业务领域发展方向是非常重要的。但是“学海无涯，而吾生有涯”，专业的方向是可以有选择性的，并不是所有的技术都需要深入到细节层面。
潘加宇老师在讲解现在技术人员对“底层”的误解时，说过一句很有意思的话：“人性的弱点，正如钱钟书所说‘人和蝙蝠不同，人喜欢在兽群里当鸟，在鸟群里作兽’。”
这句话描述的是大部分的技术人员，没搞清楚自己所在岗位应该深入钻研的领域，无论身处什么性质的部门或岗位，都喜欢去钻研计算机科学知识，比如各种中间件或操作系统的底层实现，唯“底层”为王。作为业务部门的技术人员，不是说掌握这些不重要，相反非常重要，从知识面上一定要掌握，但是深入钻研细节就要权衡好 ROI，确定好研究的范围，挑重点来钻研。事实上，对业务部门的技术人员而言，在软件设计方法或软件工程的专业知识实际上是更应该花大力气去深入钻研的基础知识，这是该领域的“底层”。
具体的知识体系构建方法，在我们的专题中，百度的陈超老师会分享自己的心得，我这里就不多赘述了。
徐泼：在领域驱动设计的落地上，我觉得有两个难点。
一是领域驱动设计的掌握是有门槛的，需要的技术知识储备实际上是要远高于领域驱动本身的。
在领域驱动设计之前，系统的设计和开发架构或设计理论主要来自于 Martin Fowler、Uncle Bob（Robert C. Martin）、Kent Beck、Grady Booch、Jacobson（Ivar Jacobson）、Cockburn（Alistair Cockburn）等大师级人物。我觉得领域驱动设计本身是一种思想体系或非常开放的方法体系，强调转变思维模式，并综合了各个方向的软件理论，它囊括了众多大师的有关软件过程的思想和方法，如需求分析、架构风格 & 模式和建模方法等，因此落地需要很多基础的架构设计知识，比如 OOA、OOD 等。很多人都希望能速成，结果往往是空有其表，形似神不似。
二是理论指导上缺乏结合国内业务详情的资料。领域驱动设计主要是指导业务系统架构的设计，国内外或多或少存在一些业务模式差异，但相关专著以国外的资料为主，业务模式差异提高了理论的理解门槛。
不过，随着国内先驱者的应用实战，我们有了越来越多本土化的博文、课程和书籍，比如张逸老师的课程和书籍等。我相信后续会有更多企业或团队，采用领域驱动设计来指导项目的设计和落地。
嘉宾介绍
徐泼，美团优选架构师。2016 年加入美团，先后负责美团酒旅供应链商品、到店商品平台、美团优选商品和物流架构。
拥有十四年软件研发和架构设计经验，擅长软件架构、领域驱动设计、微服务和软件重构，经历了从传统行业到互联网软件，涉及通信、游戏、社交、汽车 O2O、旅游电商、实物零售电商和社区团购。关注国内外前沿的架构方法，注重软件设计方法理论的研究和架构知识体系的建设，提倡软件方法在业务研发团队的应用，原则、模式加实践结合的方式推进架构方法的落地，提升软件研发效率，保障软件交付质量。
在 2022 年 3 月 24-25 日，ArchSummit 全球架构师峰会（北京站）即将落地北京，本次会议我们也配置了微服务治理之基础架构、微服务治理之业务架构、架构师成长、客户端架构设计、数据库与存储技术、云原生技术应用、质效度量体系和测试平台建设、低代码实践与应用、领域驱动设计方案落地、高并发架构设计等专题，届时欢迎你的参与。
相关内容
微信扫码咨询专知VIP会员