很多公司在项目过程中都有架构评审环节，但很少有人提起。对于参与者来说，这可能不是一种愉快的体验。各自心中一肚子苦涩，不忍回首。被评判的同学们都觉得自己被评判了，有人大声喊着“盛唐~~威武~~”，生怕我一个字不解释清楚，对面的黑脸胖子跳起来喊“开国”，复习不及格连死都没有。在我看来，这源于认知上的冲突（这个词是从《架构即未来》学来的），当事人认知上的不一致，甚至是情感上的冲突。今天简单说一下我对架构评审的理解，主要是review的意义，理解了意义，目标一致，自然而然地一起工作。有一次架构评审，两个其他部门的同事问我在架构设计上有什么特别的思考，掌握了哪些不为人知的高能技能。我当时还在想方案，直白的回答其实和编程开发是一样的。如何拆解、解耦、抽象和聚合，原理上是一样的。大概这个回答没有达到两位同事的预期。他们有些失望和不以为然。他们可能觉得我敷衍了事，或者觉得难为他们了，就不再交流了。好像没多久，他们就都离开了那家公司。不知道他们现在有没有找到满意的答案。现在想想，当年的答案确实太窄了，在架构设计上还要考虑很多其他方面。架构评审同技术方案评审、CodeReview一样，是项目过程中必不可少的环节，是指对架构设计方案的评审。在传统的软件工程理论中，设计阶段的输出是设计文档，包括概要设计/详细设计，但与产品和研发无关，因此文档既包括功能描述，也包括技术实现。有的外包给日本的项目，甲方发来的文件甚至写的都是伪代码，就等着你翻译成代码。外包工程师纯粹是翻译机器。但互联网时代提倡敏捷迭代，传统方式总被认为过于繁重，流程复杂，影响效率。一切都应该是短而快的。在扁平化的组织中，需求往往会被快速分配给一线研发，然后由个人去折腾。事实上，大多数达到一定规模的公司都会进行架构评审，即架构评审机构（架构评审委员会等）制定架构设计文档规范，设计师根据规范编写方案，设计师解释将方案当面交给审稿人，并回答审稿人的问题，审稿人提出意见和建议，双方讨论充分沟通，最后由审稿人决定是否通过。如果审核不通过，可以修改并重新审核。本质上，架构评审和测试一样，都是为了保证质量，也没有人那么反感测试，号称不通过测试就可以直接上线。由于技术人员普遍存在的看不起文人的心态，他们往往抗拒参与评审，被人扒光。审核过程中会提到实施的重点，因此一些相关人员也会参与了解，比如测试、数据、安全等，这无形中可能会增加被审核者的心理压力。毕竟架构设计代表着更高层次的技术能力。习惯了“一个人单独写代码”的研发人员，如果被当众指出，要求修改，很容易伤自尊，丢面子。技术个人自由倾向比较强的同学，不适合组队作战。只专注于研发和实现，拥有新潮技术，而不关注在线性能、持续运维和故障应急响应的程序员，不是好的攻城狮。如果在自己的设计中指出问题并提出改进建议，是心态不成熟的表现。架构审查的目的是什么？要检查，确保方案合格，考虑到方方面面，避免缺陷和疏漏，不求好方案，至少不出错。确保架构设计合理、基本一致，符合总体原则。保持对系统架构的全局理解，避免黑盒效应。通过评论发现创新亮点并推广最佳实践。以上四点按重要性从高到低排列。可见，检讨重的是事，而不是人。参与评审的各方一律平等，各司其职，项目为公司业务服务。有些人会自信地拍着胸脯说自己的设计已经足够好了，不需要花时间去告诉别人。你能保证别人和你一样好吗？这次好，下次好吗？方案设计不仅仅是功能实现，还有很多非功能需求，以及持续运维所需要的工作，需要工程实践经验，需要权衡取舍。架构设计往往没有想象中那么简单纯粹，甚至有一半以上的精力要放在非核心方面。举几个例子：互联网金融公司的系统没有对账机制，你还敢投资吗？有人号称玩高并发多线程。不够用，够了就减量更新。——不知白白消灭了多少。如果你滑动太多，你应该能够找到它。拜托，没有和解。你是怎么发现的？我没有完全考虑异常情况。如果数据流中断，数据就会丢失。再复杂的逻辑再等一会，再修复？担心你。对于核心业务应用，方案设计的很周到，但是我没有考虑过性能指标，也没有想过如何监控告警——这个从来没吃过亏，还中过坑。有人说起他们的黑客计划，还没等别人指出，就发现了数据逻辑没有完全封闭的问题。有人会说，经验是靠坑积累起来的，否则没法成长。能不能问问老大，愿不愿意把业务系统当做试验田去实践？所以有了架构审查，经验多的人花的时间成本少，方案设计过得快，三个皮匠都比诸葛亮强，更何况有资格做架构审查的，各种情况都见识过。但并不代表审稿人就高人一等，更权威。一个人再优秀，在讨论技术方案的时候，也要以说理服人。有些审稿人认为这是在浪费他们的时间，因为总有那些通病，还得耐心听。荣耀。有的评委在评判的过程中自卑，好像在评判别人，进一步想：“你评我干什么？你是谁？你不懂这行！”对不起，这真的不是商业百科知识竞赛。身边的人都不开心，觉得没什么特别的，遇到行业大神，都惊呼自己真是平易近人！其实大神们总是平易近人的，并不认为自己高人一等，成熟，自知之明。大牛之所以成为大牛，可能是因为不自鸣得意，脚踏实地，做事勤快，豁达，空杯心态。系统是为了满足需求，实现业务功能。大家坐在一起查漏补缺。只有良好的心态，才能合作共赢。功劳属于大家。当出现问题时，我们分担责任，不能置身事外。***一句话，既然都来了，有的放手，没有的放手，好好想想计划才是正道！ITCrossTalker)”获取联系方式及授权】点此阅读作者更多好文
