Joe Moreno：我在苹果公司学到的编程技巧

Joe Moreno在1998年至2007年期间就职于苹果公司，是苹果在线商店的一名开发人员。通过此文，也可对苹果公司的一些产品开发细节有所了解。以下是全文。
　　当我还在苹果在线商店工作的时候，我们从来没有对在线网站做过负载测试。我们也不觉得需要这么做。然而，当每次史蒂夫·乔布斯在演示某个幻灯片过程中切换到在线商店时，会走下台来等待，这是非常有趣的经历。作为事后检查的一部分，每次在线商店重新上线时，我们都会问自己服务器的瓶颈在哪里：是CPU、网络带宽、磁盘I/O还是内存？虽然准确预测整个系统在实际环境中的行为非常困难，幸运的是我们有一整套的测试策略来确保在重新启动之前有足够的测试。 
 

作者：Joe Moreno

负载测试 / Load Testing
　　许多公司用负载测试来试验他们的web应用程序能够支持怎样的负载。一个最平常用到的，但是错误的方式是把web站点上线然后启动负载测试。这种方式的问题在于，它不会告诉你web站点从在线状态到不能提供服务这个过程中是如何运行的。当一个web站点在使用状态时宕机然后重新启动，这时web站点表现出的行为，一定与负载测试状态下有很大的区别。例如，我们发现在iTunes商店（iTunesStore）第一次启动时，一个被信任的WebObjects组件不是线程安全的，而这个问题只有在该对象处于重负荷情况下才会出现。
初生牛犊 / Cutting My Teeth
　　当我第一次加入苹果在线商店开发小组时，我和一位经验丰富的软件工程师搭档，他教会我如何快速地熟悉代码库，构建流程以及单元测试和组件测试。由于在线商店已经上线了，我们只有在对新代码进行测试以及搜集数据之后才能发布。
　　我的第一项任务是和搭档一起实现一个在网络上用特性表形式搜集产品信息的简单web服务。一般这样的简单web服务程序只需要一到两天，而我们俩在师傅的一步步指导下花了一整个礼拜，通过结对编程方式完成了整个流程。（虽然我们采用结对编程，但是我们使用的是Agile/Scrum，而不是极限编程。每个开发小组可以在保证进度的前提下使用任何他们达成共识的开发技术。我服务的团队碰巧有几个经过训练的scrum大师，他们得到了管理团队的支持。）
　　在实际开始编写产品代码之前，我们需要编写单元测试。所有的软件工程师都被要求先为他们的API编写单元测试，这个一个很值得学习的规范。（编注：测试在敏捷当中非常重要，参考这篇《敏捷方法中测试人员的价值》。）接下来，我们在Eclipse/WOLips上使用WebObjects/Java编写代码，与此同时我们为应用程序设下关键的断点，然后在调试模式下运行，这样我们就可以单步调试代码。我见到了有太多在别处工作的软件工程师，他们不断地编码然，就像他们在不断地往墙上扔东西，然后看看到底会有什么会粘在墙上（像碰运气一样）。
　　在我们检入我们代码的同时，软件仓库会自动构建所有的应用程序，然后对它们运行单元测试。如果你的代码让这次构建失败，开发小组的每个人，包括一到两位项目经理会受到邮件通知——你就是构建失败的罪魁祸首。
令牌 / Token
　　我们有一段非常特殊的软件代码，一次只能由一个软件工程师检出（check out）、编写（work on）、然后检入（checkin）。你只有在得到一个物理令牌时才能够接触到这段代码。在我们这里，这个令牌就是一个DarthTater玩偶，它放在你的工作的格子间或者书架上最显眼的地方。
搜集度量数据/ Gathering Metrics
　　一旦我们的服务编码完成，没有错误，并且被检入到代码仓库后，我们开始组件测试并搜集新代码的度量数据。这是另外一个在新手团队里被忽略的步骤。我怀疑“搜集度量数据”这个步骤甚至都没有被包含在Joel测试中，因为JoelSpolsky的产品是一个桌面应用程序而不是一个需要重负载测试的web程序（或者，也许这个被隐含在“你有测试工程师吗？”这个步骤里）
　　甚至在我们考虑将代码放到实时代码分支之前，我们就已经对代码进行了数百万次的请求测试。在苹果公司，我们有一个非常复杂的缓存算法，根据我们设定的目标，它可以保存我们需要的任意数目的记录。我们是否需要五百个或是五万个产品的请求记录缓存呢？在一次冷启动开始之后，我们是否需要对指定的产品用缓存来“热身”呢？在没有任何的请求命中时，我们需要等多久才把一个产品从缓存中移除并释放内存呢？
　　附注一点，我们的缓存通常是一个哈希表。哈希表的优点在于它的大O表示法运行时间是常量O(1)。当你在一个面试中被问道“什么事最快的查找函数”时，千万不要说“一个B树二叉树”。完美的哈希表通常会轻松胜出。
调整并完成 / Tweaking and Done
　　我们会不断调整代码直到我们得到可接受的度量数据。我们的测量数据会对缓存内存消耗多少以及满足每个服务请求/响应的时间长短进行度量。根据我们的需求，我们会努力达到99.7%的服务请求在35毫秒之内返回，95%的请求在10毫秒之内返回，没有单个请求超过50毫秒的响应时间。
　　这些测试在一个非常接近产品环境的实时数据库的拷贝中运行。这不能完美地指出web应用程序一旦在实际环境中会如何执行。但是将它变成一个设定期望的很好的办法，这不会需要很久时间。
　　在我们“疾跑”（Sprint）结束的时候，所有这些度量数据都会作为敏捷定义“完成”时演示的一部分。这时代码已经准备就绪可以被检入质量保证的代码分支，在代码发布上线之前还会进行功能测试。
编注：
　　1. 大O表示法：用来描述算法的时间复杂度，O(1)的时间复杂度最低
　　2. 疾跑（Sprint）：是scrum开发方法的一个最基本开发单元