系统对性能方面的非功能性需求应当同所有架构、设计的领域一样被置于重要位置。无论你是开发只容许纳秒级延时的低延迟交易系统，还是管理“待办事项”的手机应用，你都应该了解用户所认为的“太慢”。

在考虑我们是否需要就代码性能进行代码审查之前，我们应该问自己几个关于具体需求是什么的问题。虽然一些应用确实不需要考虑每毫秒都花费在哪里，对于大部分应用，花费几个小时的折腾进行优化来获得的些许CPU下降的价值也是有限的，但有些地方还是审查者可以检查一下的，进而确保代码不会有一些常见可避免的性能缺陷。

　　这段代码是否有硬性的性能需求？

接受审查的代码是否涉及之前发布的服务等级协议（SLA）？或这个需求本身有特别的性能需求？

如果代码导致“登录页面加载太慢”，那原始的开发者需要找出合适的加载时间是多久，不然审查者或作者本人如何确保改进后的速度足够快？

如果有硬性的需求，是否有测试能证明满足了该需求？任何注重性能的系统应该就性能提供自动化测试，这能确保发布的SLA达到预期（如所有订单请求要在10毫秒内处理）。没有这些，你只能依靠你的用户来告诉你没有达到对应的SLA。这不仅是一种糟糕的用户体验，还会带来原本可避免的罚金和支出。

　　这个修复或新增的功能是否会反向影响到任何现存的性能测试结果

如果你定期运行性能测试或有测试套件可以按需运行它们，那你就需要检查新的代码是否使得性能关键区域的系统性能有所下降。这可以是一个自动化的流程，但由于在持续集成环境中更常运行单元测试而不是性能测试，所以值得特别指出可以在代码审查中检查这项。

　　调用外部的服务或应用的代价是昂贵的

任何通过网路来使用外部系统的方式通常会比没有很好优化的方法有更差的性能。考虑以下几点：

调用数据库：最坏的情况是问题隐藏在系统抽象中，如关系对象映射（ORM）中。但是在代码审查中你应该可以找到常见的导致性能问题的问题，如在循环中逐个调用数据库，一种情况就是加载ID列表之后，再在数据库中逐个查询ID对应的每条数据。

不必要的网络调用：就像数据库一样，远程服务有时也会被过度使用，原来只要一个远程调用就可实现的，或者可以使用批量或缓存防止昂贵网络调用的，却使用多个远程调用来实现。再次强调，像数据库一样，有时抽象类会隐藏调用远程API的方法。

移动或可穿戴应用过于频繁地调用后端程序：这基本上和“不必要的网络调用”相同，但是在移动设备上会产生其他问题，这不仅会产生不必要的调用后端使得性能变差，还会更快地消耗电量甚至导致用户的金钱支出。

　　有效且高效地使用资源

代码是否用锁来控制共享资源的访问？这是否会导致性能降低或死锁？

锁是一个性能开销大户，并在多线程环境中很难理清。考虑使用以下模式：单线程写或修改值，atv，其余线程只读，或使用无锁算法。

是否存在内存泄露？Java中一些常见的原因会是：可变的静态字段，使用ThreadLocal变量和使用类加载器。

是否存在内存无限增长？这个和内存泄露不同，内存泄漏是指无用的对象不能被垃圾回收器回收。但对于任何语言，就算是没有垃圾回收的语言，也能创建无限变大的数据结构。作为审查者，如果你看见新的变量不断被加到list或map中，你就要问下，这个list或map什么时候失效或清除无用数据。

代码是否关闭了连接或数据流？关闭连接或文件、网络数据流很容易会被忘记。当你审查别人代码时，如果使用到文件、网络或数据库连接，就要确保它们被正确地关闭了。

资源池是否配置正确？针对一个环境的最佳配置取决于很多因素，所以作为审查者你很难马上知道像数据库连接池大小是否正确等这些问题。但是有一些是你一眼就可以看出来的，像资源池是否太小（比如大小设置为1）或太大（如数百万线程）。如果无法确定，就从默认值开始。没有使用默认值的就需要提供一定的测试或计算来证明这么配置的合理性。

　　审查者可以轻松找出的警告信号

一些代码一眼就能看出存在潜在性能问题。这依赖于所使用的语言和类库。

反射：Java的反射比正常调用要慢。如果你在审查含有反射的代码，你就要问下是否必须使用它。

(责任编辑：本港台直播)