这玩意儿是有章可循的

脑子里闪过的关注点是：

可测试性，可维护性（想的是运维，其实包含整个SCM周期）

按着这个思路还会有可扩展性（开闭法则等等巴拉巴拉）和可伸缩性（水平->k8s HPA，垂直->k8s node join cluster and redeploy）

---

目标

• 一是要定制一份约定（规则，规范文档），包含一系列的严格约束指标和设计要求指导
• 二是在这份约定的基础上形成执行的策略————政策的生命在于执行么，但如何执行，也要有行动指南
  • 就好像上场打比赛，不是打就完了，得有套路，坚决的执行挡拆战术，还是把球交给我的王牌球员
  • 这就意味着不仅包括通常的流程的定义（比如各种前审，包含概设评审、代码评审），还要包含流程简化条件（什么时候可以省略掉一些流程环节，比如不做概设评审了）
  • 最终是审计后的合规整改
    • 如果是前置约束文本的疏漏，那么补全规则文本，并发布新的规则文档
    • 如果是因为流程简化而导致的，那么调整规则文本执行策略的规定，相当于增加不该例外的情形，将来如果再遇到要坚决贯彻前置约束规则
    • 无论是什么原因导致的审计不合规（或测试发现的不合规），要坚决整改，具体阐述可参照狼性奋斗公司红头文件，其中提到“都不得以进度、功能、特性等为理由来降低可信的要求”，说的就是这里应该持有的态度，基本上该文的可信性讲的就是非功能性需求的内容，我们当然不是要认同类似996的文化——如果它也算是一种文化的话，反动的文化，但是先进的工程管理意识值得认同
• 执行约束和整改约束的工具层面的不断加强
  • 研发自身的，围绕pull request的前审，测试的有效开展，保证基线的质量（也就是稳定有节奏地确定和生成软件基线）
    • 目前代码前审力度和效果都不够，要有更细致的规则（提交MR时候的description的格式，附加内容），并结合工具约束（带approved的代码托管平台选用）
    • PR在合并前的测试，需要硬件资源，测试case积累