软件团队降本增效-建立技术评审机制

每个软件项目在初期，需求/功能实现效率非常高，每千行代码的缺陷率也较低。但随着时间推移，代码质量逐渐下降，逻辑关系愈发复杂，开发效率越来越差，缺陷率越来越高。

在项目忙碌之际，我们倾向于优先实现功能，相对地，会降低对代码质量和评审的重视程度。一旦放松对代码质量的要求，代码腐化的速度是非常惊人的。

在一些重要技术环节上，建立评审机制是必不可少的。比如数据库设计评审，接口评审。

数据库设计评审

数据库设计描述了软件的数据结构以及业务抽象结果。数据库的数据结果处于软件中非常重要的部分，直接影响了业务逻辑的实现。

在数据结构的抽象层出现错误，会对上层业务逻辑的执行产生负面影响，我们需要特别谨慎对待。在评审的执行上，我们一般建立一个以核心人员为主的评审小组，对数据结构的合理性，规范性和性能影响等方面进行评审，并对发现的问题提出改进意见。数据库评审机制除了能发现短期的严重问题外，还能在数据结构的长期一致性上贡献价值。

在关键数据结构设计上，我们还需要相关设计文档的完备性。方便后续项目组内传递设计思想。

接口评审

接口是不同组件或系统之间进行通信和交互的重要桥梁。为了保证接口的有效性和可靠性，接口设计需要遵循一些基本原则，如合理性、一致性和可读性。为了方便开发和维护，我们推荐使用DSL（领域特定语言）来定义接口，然后根据这些定义生成相应的代码。这些DSL通常还具有在接口发生变更时保持与旧接口兼容的能力，这有助于减少开发人员的工作量和避免潜在的错误。

在评审接口设计时，除了确保其合理性、可读性以及一致性之外，还需要关注向后兼容能力。这种能力使得在新的接口版本中添加或修改某些特性时，不会影响到旧版本的使用和功能，从而确保系统的稳定性和可靠性。

目前，一些主流的接口解决方案包括grpc和thrift等。这些方案都具有高度的可扩展性和灵活性，可以满足不同应用场景的需求。同时，它们还提供了丰富的工具和库，方便开发人员进行接口的开发、测试和维护。

代码评审

代码评审尽量先跑一遍linter，在linter没有报告严重问题的前提下，再进行代码评审。每次代码评审的代码规模一定要小(小于500行)，聚焦在业务逻辑，关键流程上面。不要太纠结于代码格式之类的问题。

在技术上可以使用一个中间仓库(gerrit)，在代码评审后再推入主仓库。