1. 充分校验入参

有一句话叫 “All input is evil”，即一切的输入都可能是恶意的。 因此，经验丰富的工程师会对接口的入参进行严格的校验，从最基础的非空、长度校验，到复杂的业务逻辑校验都不应忽略。例如，在典型的电商下单场景中，我们需要校验用户状态是否正常、商品是否上架、库存是否充足、优惠券是否可用等。请记住，入参校验是防止低级错误的第一道防线，养成这个习惯至关重要。

2. 完整记录日志

我们总希望自己写的代码在本地、测试、甚至生产环境下都能完美执行。但现实中，业务异常情况常常发生，即使我们拥有像ELK、Skywalking这样的日志收集和链路追踪工具，日志记录的全面性和合理性仍直接影响我们排查问题的效率。日志的覆盖面应该包括关键路径、异常处理等。你今天省下的日志记录时间，将来很可能会在排查问题时花费更多。

3. RPC 调用需考虑网络问题

RPC 调用不同于本地调用，因为网络不稳定性带来了许多不确定因素。你需要思考以下问题：

• 请求未能到达服务提供者怎么办？
• 请求到达但未返回结果时如何处理？
• 超时和重试策略如何设置？

根据不同业务场景（如读请求、写请求，高并发与非高并发），处理策略应该有所不同，不能一概而论。

4. 批量处理替代单次处理

在需要多次执行 RPC 或数据库操作时，如果每次都在循环中调用单次接口，而不采用批量处理，将大大降低性能，尤其是在大量数据场景下。 此外，在循环体中添加日志记录时也要注意，避免生成大量日志，消耗磁盘资源。

5. 复杂 SQL 需先执行计划

那种海量数据下多表关联查询的SQL语句，一次执行把整个数据库搞挂并不是完全的小概率事件。因此，如果你写完一个这样的SQL语句，一定要记得怀有敬畏之心地先执行一下，看看效果。记住，不要在测试环境的数据库中执行，因为有的公司的测试库和生产库的数据量是天差地别，数据分布形态也不一样，执行结果可能没有参考性。记得要去生产库的从库去执行，因为主库一旦出现问题，影响范围太大。从库也不要直接去执行，执行之前还是要explain一下，看看执行计划的。如果执行计划中出现了大表的type=all，那也就别再执行SQL了，把从库打挂了影响也不小，先想办法优化吧。

6. 扩展或新增，不直接修改

维护中台服务时，如果对业务全貌还不熟悉，不要轻易修改业务主流程，特别是在多个业务线共用同一服务的情况下。采用扩展或新增的方式，可以减少对已有功能的影响，避免牵一发而动全身的风险。

7. 重构而非重写

重构的目标是优化现有代码的结构，而非推翻重写。相比于重新编写整个系统，合理的重构可以提升代码的可维护性，避免造成大规模的业务中断。

牢记：重构是为了提高代码质量，而非推倒重来。

8. 非必要，不引入

在满足业务需求的前提下，技术方案越简单越好。例如：

• 如果 MySQL 足以承受业务请求压力，就不需要引入 Redis 或 ES。
• 如果同步调用能够满足业务需求，就不要盲目使用异步 MQ。
• 如果简单coding即可高效迭代的需求，那就绝对不引入设计模式；

过度引入新技术不仅增加了系统复杂性，也提高了维护成本。一个出色的工程师，他的特质是喜欢迎接挑战，但一个营收惊人的关键系统，对它最好的方式是杜绝挑战。

9. 保证数据一致性

当业务系统采用多数据源时（如 MySQL 主从模式或 MySQL + Redis 组合），需明确哪个是主数据源，发生数据不一致时以主数据源为准。此外，需设计策略确保多数据源最终一致性，以免系统埋下隐患。

10. 避免过度前瞻性设计

有些工程师在项目初期就着眼于未来的高并发或大规模扩展，过早地拆分微服务、进行数据库分库分表。这种过度设计会增加开发和调试难度，尤其是在业务前景不明朗的情况下，可能导致资源浪费。 我们要根据实际业务情况设计系统，保持简单而实用，避免不必要的复杂性。