Python 高手编程系列三百八十六：首先要能工作

一个很常见的错误是，在编写代码时就尝试优化代码。这是没有意义的，因为真正的
瓶颈往往位于你从未想到过的地方。
应用程序通常由非常复杂的交互组成，并且，在真正使用它之前，我们不可能全面的
了解应用程序的功能。
当然，这不是不去尝试优化一个函数或方法的原因。你应该非常细心并且尽可能降低其复
杂性，避免无用的重复。但是第一个目标是使它正常工作。优化工作不应该阻碍这个首要目标。
对于行级代码，Python 的哲学是用一种方法，最好是只有一种方法来做一件事。所以，
只要你坚持使用 Python 化的语法，这些语法在第 2 章和第 3 章中提到过，你的代码应该是
很好的。通常，编写较少的代码比编写更多的代码更好更快。
在到你的代码正常工作以及你准备好调优之前，不要做任何以下这些事情。
• 开始编写全局字典以缓存函数的数据。
• 考虑使用 C 语言或者混合语言（如 Cython）外部化一部分代码。
• 查找一些进行基本计算的外部库。
对于非常专业的领域，如科学计算或游戏，专业库的使用以及外部化可能从一开始就
是不可避免的。另一方面，使用像 NumPy 这样的库可以缓解特定功能的开发，并且最终产
生更简单和更快的代码。此外，如果有一个很好的库可以满足你的需求，你就没必要重新
写一个。
例如，Soya 3D 是 OpenGL 上的游戏引擎（参见 http://home.gna.org/oomadness/en/soya3d/
index.html），在进行实时 3D 渲染时使用 C 和 Pyrex 进行快速矩阵运算。
从用户的角度考虑
我见过有团队致力于优化应用程序服务器的启动时间，当该服务器启动并运行时，它
工作地很好。一旦他们完成提速，他们把这项工作成果推广给他们的客户。他们有点沮丧，
他们注意到客户并不太关心这个优化的成果。这是因为加速工作不是由用户反馈而是由开
发者的观点驱动的。创建系统的人每天多次启动服务器。所以启动时间对他们来说意味着
很多，但是对用户来说，似乎影响不大。
虽然从一个绝对的角度来说，让程序启动更快是一件好事，但是团队应该小心安排优
化工作的顺序，并问自己以下问题：
• 我被要求更快吗？
• 谁发现程序慢？
• 它真的很慢，还是可以接受？
• 使它更快地运行需要多少成本，值得吗？
• 什么部分需要很快？
记住，优化是需要成本的，并且开发人员的观点对客户来说是没有意义的，除非你正
在编写框架或库，并且客户是开发人员。
保持代码的可读性和可维护性
即使 Python 试图使常见的代码模式是最快的，优化工作可能也会混淆你的代码，使代
码变得难以阅读。所以，在保持代码的可读性和可维护性与为了优化而搞的代码面目全非
之间，要有一个平衡。
当你达到了 90%的优化目标，剩下的 10%将使你的代码完全不可读，那么你最好停止
那里的工作或者寻找其他的解决方案。
优化策略
如果说你的程序真的有一个速度问题需要解决。不要试图猜测如何使它更快。通常，
通过查看代码是很难找到瓶颈的，所以，需要一套工具来找到真正的问题。
良好的优化策略可以从 3 个步骤开始。
• 找到另外的罪魁祸首：确保第三方服务器或资源没有故障。
• 扩展硬件：确保资源充足。
• 编写速度测试：创建具有速度目标的场景。
找到另外的罪魁祸首
通常，在生产级别出现性能问题，客户会通知你，在测试时软件正常工作，而现在却
不能正常工作了。性能问题可能会发生，因为应用程序没有计划在大量用户和增加数据大
小的现实世界中工作。
但是如果应用程序与其他应用程序交互，首先要做的是检查瓶颈是否位于这些
交互。例如，数据库服务器或 LDAP 服务器会导致一些额外的开销，可能会使一切
都变慢。
应该考虑应用程序之间的物理链接。也许，由于错误的配置或者网络拥塞，你的应用
程序服务器和内网中的另一个服务器之间的网络连接真的很慢。
设计文档应提供所有交互和每个连接的性质的设计图，从中可以获得系统的整体架构，
这会有助于解决速度问题。