围绕ArchGuard，我们一直在探索适合大多数企业的治理模型。一般来说，对于应用架构的治理，我们预期的目标是相应的架构设计（广义上）能够被采纳和遵循。如果过程中出现流程问题，架构在实施过程中会不断偏离预期的设计。然后，我们将着手匹配和设计相应的规范、规则和功能，以确保在后续的实施过程中能够正确实施。因此，在架构治理方面，我们可以用一些简单的元素来概括。模型。找到不好的品味，用好的设计来改进它。规格。架构决策的文档。规则。规范的工具化和形式化意味着在我们的场景中，架构治理解决方案可以围绕三个元素构建。模式：坏品味和好的解决方案在我们的行业中，针对特定问题的解决方案称为模式，例如设计模式和架构模式。这些广为流传的编程模式是很好的最佳实践。不过在我看来，还有一类，坏模式其实就是模式，只是我们常说的臭味（Smell），代码就是代码味，架构就是架构。不好吃。在一个组织中，代码遵循内部人员流动、自定义框架的编码风格、公司层面的规范定义，从而使整体代码模式趋于一致。这种一致性会在短期内受到人员变动的影响。几个高水平的“新人”，可能会给团队带来新鲜的注解；大量新人的涌入，也可能冲淡原有的好模式。但是，无论如何，被替换的只是纹样本身，而不是纹样的存在。坏品味本身就是与好的实践应该是什么的好模型的比较。因此，治理的第一步是让恶臭浮出水面。它可以通过人工查看项目代码得到一些初步的结论，并根据这些结论建立洞察力；也可以是像ArchGuard这样的专家系统，可以通过AST从语法中分析出难闻的气味，并可视化出来。规范：架构决策的文档规范是我们在日常开发过程中约定的标准，其本质是一系列架构决策的文档化。作为架构师/开发人员，我们是否定义了所有API的外观？如何处理数据？如何打造品质保障？在另一个主题：轻量级架构决策中，我们定义架构决策应该写在格式化文档中。一个好的规范的本质是推荐一组最佳实践。“年轻”的开发人员往往不理解很多做法的意义，为什么要这样呢？不这样做有什么影响？有时，有经验的开发人员需要告诉他们，为什么+什么+怎么做。然而，在一些大型的IT组织中，人们往往仍然以一种简单粗暴的方式使用“考试”来保证什么是好的模式/实践的知识就是一切。不管规范是明文规定的，还是约定俗成的，我们都能发现，当生意兴隆或有新人加入时，都会逐渐被破坏。因此，我们开始寻找使规范更有效的方法。规则：规范的工具化和形式化从某种意义上说，规则是规范工具化的一种手段。最常见的方式是Linter，一种基于语法树/语法结构的正则化工具。这种规则可以是我们学习英语时的语法规则，是语言中高度抽象的组合和聚合关系的习惯语言规则，包括组合规则和聚合规则。比如在英语中，常见的句型可以是：主谓宾宾补语（我英语四级还没过，这是噩梦）。围绕这些规则，可以构建一系列自动化检测工具。这样一个工具也可以是我们用Java写企业应用时的Checkstyle；或者我们使用TypeScript编写前端应用程序时的ESLint。从这个意义上说，它们是共同规则的形式化。治理：匹配模式、显示问题、调整和演变模式、规范和规则都取决于编写工具的人。他应该是架构专家，精通编码+语言本身。或者将两者结合起来设计这样一个系统。回到编程治理问题，从流程的角度来看，我们治理架构问题的方式是：设计，找到对应的规范（也就是最佳实践），人为地识别代码中的模式，然后进行匹配通过编写代码，即规则。通过可视化+分析的方式展示代码中的问题。对规范进行正则化，并用上述指标构建适应度函数来指导系统的演化。以ArchGuard中查询SQL规则为例，以下是代码中的SQL（修改）：overridefungetById(systemId:Long):SystemInfo?{valsql="select*fromsystem_infowhereid=:systemId"返回jdbi。withHandle
