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

当我还在苹果在线商店工作的时候,我们从来没有对在线网站做过负载测试。我们也不觉得需要这么做。然而,当每次史蒂夫·乔布斯在演示某个幻灯片过程中切换到在线商店时,会走下台来等待,这是非常有趣的经历。作为事后检查的一部分,每次在线商店重新上线时,我们都会问自己服务器的瓶颈在哪里:是CPU、 网络带宽、磁盘I/O还是内存?虽然准确预测整个系统在实际环境中的行为非常困难,幸运的是我们有一整套的测试策略来确保在重新启动之前有足够的测试。

负载测试 / Load Testing

许多公司用负载测试来试验他们的web应用程序能够支持怎样的负载。一个最平常用到的,但是错误的方式是把web站点上线然后启动负载测试。这种方式 的问题在于,它不会告诉你web站点从在线状态到不能提供服务这个过程中是如何运行的。当一个web站点在使用状态时宕机然后重新启动,这时web站点表现出的行为,一定与负载测试状态下有很大的区别。例如,我们发现在iTunes商店(iTunes Store)第一次启动时,一个被信任的WebObjects组件不是线程安全的,而这个问题只有在该对象处于重负荷情况下才会出现。

初生牛犊 / Cutting My Teeth

当我第一次加入苹果在线商店开发小组时,我和一位经验丰富的软件工程师搭档,他教会我如何快速地熟悉代码库,构建流程以及单元测试和组件测试。由于在线商店已经上线了,我们只有在对新代码进行测试以及搜集数据之后才能发布。 我的第一项任务是和搭档一起实现一个在网络上用特性表形式搜集产品信息的简单web服务。一般这样的简单web服务程序只需要一到两天,而我们俩在师傅的一步步指导下花了一整个礼拜,通过结对编程方式完成了整个流程。(虽然我们采用结对编程,但是我们使用的是Agile/Scrum,而不是极限编程。 每个开发小组可以在保证进度的前提下使用任何他们达成共识的开发技术。我服务的团队碰巧有几个经过训练的scrum大师,他们得到了管理团队的支持。) 在实际开始编写产品代码之前,我们需要编写单元测试。所有的软件工程师都被要求先为他们的API编写单元测试,这个一个很值得学习的规范。(编注:测试在敏捷当中非常重要,参考这篇《敏捷方法中测试人员的价值》。) 接下来,我们在 Eclipse/WOLips上使用WebObjects/Java编写代码,与此同时我们为应用程序设下关键的断点,然后在调试模式下运行,这样我们就 可以单步调试代码。我见到了有太多在别处工作的软件工程师,他们不断地编码,就像他们在不断地往墙上扔东西,然后看看到底会有什么会粘在墙上(像碰运气 一样)。 在我们检入我们代码的同时,软件仓库会自动构建所有的应用程序,然后对它们运行单元测试。如果你的代码让这次构建失败,开发小组的每个人,包括一到两位项目经理会受到邮件通知——你就是构建失败的罪魁祸首。

令牌 / Token 我们有一段非常特殊的软件代码,一次只能由一个软件工程师检出(check out)、编写(work on)、然后检入(check in)。你只有在得到一个物理令牌时才能够接触到这段代码。在我们这里,这个令牌就是一个Darth Tater玩偶,它放在你的工作的格子间或者书架上最显眼的地方。 搜集度量数据 / Gathering Metrics 一旦我们的服务编码完成,没有错误,并且被检入到代码仓库后,我们开始组件测试并搜集新代码的度量数据。这是另外一个在新手团队里被忽略的步骤。我怀 疑“搜集度量数据”这个步骤甚至都没有被包含在Joel测试中,因为Joel Spolsky的产品是一个桌面应用程序而不是一个需要重负载测试的web程序。 甚至在我们考虑将代码放到实时代码分支之前,我们就已经对代码进行了数百万次的请求测试。在苹果公司,我们有一个非常复杂的缓存算法,根据我们设定的目标,它可以保存我们需要的任意数目的记录。我们是否需要五百个或是五万个产品的请求记录缓存呢?在一次冷启动开始之后,我们是否需要对指定的产品用缓存来“热身”呢?在没有任何的请求命中时,我们需要等多久才把一个产品从缓存中移除并释放内存呢? 附注一点,我们的缓存通常是一个哈希表。哈希表的优点在于它的大O表示法(用来描述算法的时间复杂度,O(1)的时间复杂度最低)运行时间是常量O(1)。当你在一个面试中被问道“什么是最快的查找函数”时,千万不要说“一个B树二叉树”。因为完美的哈希表通常会轻松胜出。

调整并完成 / Tweaking and Done 我们会不断调整代码直到我们得到可接受的度量数据。我们的测量数据会对缓存内存消耗多少以及满足每个服务请求/响应的时间长短进行度量。根据我们的需求,我们会努力达到99.7%的服务请求在35毫秒之内返回,95%的请求在10毫秒之内返回,没有单个请求超过50毫秒的响应时间。 这些测试在一个非常接近产品环境的实时数据库的拷贝中运行。这不能完美地指出web应用程序一旦在实际环境中会如何执行。但是将它变成一个设定期望的很好的办法,这不会需要很久时间。 在我们“疾跑”(Sprint,是scrum开发方法的一个最基本开发单元)结束的时候,所有这些度量数据都会作为敏捷定义“完成”时演示的一部分。这时代码已经准备就绪可以被检入质量保证的代码分支,在代码发布上线之前还会进行功能测试。


原文发布于微信公众号 - 程序员互动联盟(coder_online)

原文发表时间:2015-08-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏python学习指南

python爬虫(一)_爬虫原理和数据抓取

本篇将开始介绍Python原理,更多内容请参考:Python学习指南 为什么要做爬虫 著名的革命家、思想家、政治家、战略家、社会改革的主要领导人物马云曾经...

3646
来自专栏web前端教室

领读《深入浅出NODEJS》—第二章 模块机制

领读,领你读,把书的重点提出来。尝试以知识管理、快速阅读的方式来学习。 为什么要写这个类型的文章呢?第一是想要学习NODEJS了,第二是觉得之前写了那么多的学习...

2068
来自专栏林喜东的专栏

你的账号安全吗?

账号安全无小事,近些年持续不断爆出的安全事件,有很多低级错误其实都是拥有一个健壮的账号体系可以避免的;多次听闻后曾写一写账号安全相关的东西,但直...

1764
来自专栏IT大咖说

Metrics:让微服务运行更透明

摘要 让微服务运行状态清晰可见。 Metrics是什么 直译是“度量”,不同的领域定义有所区别,在微服务领域中的定义: “对微服务的某个指标给予一个可量化程度的...

44712
来自专栏潇涧技术专栏

How to know your application’s battery stats

众所周知,Android系统内置了应用的耗电量统计分析功能,但是并没有提供相应的API和文档,只是可以查看耗电量排行榜前10的应用的耗电百分比。此外,随着And...

1612
来自专栏美团技术团队

互联网企业安全之端口监控

背景 外网端口监控系统是整个安全体系中非常重要的一环,它就像眼睛一样,时刻监控外网端口开放情况,并且在发现高危端口时能够及时提醒安全、运维人员做出相应处理。 对...

49915
来自专栏张善友的专栏

别再设计易碎的Web API

原文作者Mathieu Fenniak在博文中大呼:不要再设计易碎的Web API 了,否则你的合作伙伴或第三方开发者会因此恨你,而离你远去的。他认为,想设计出...

2058
来自专栏谭伟华)的专栏

Amazon Aurora:云时代的数据库 ( 下)

本文详尽的介绍了 Aurora 设计背后的驱动和思考,以及如何在云上实现一个同时满足高并发、高吞吐量、高稳定性、高可用、高扩展的云数据库。

3550
来自专栏北京马哥教育

sqlserver、Mysql、Oracle三种数据库的优缺点总结

? 一、sqlserver 优点: 易用性、适合分布式组织的可伸缩性、用于决策支持的数据仓库功能、与许多其他服务器软件紧密关联的集成性、良好的性价比等; 为...

4166
来自专栏程序人生

从开发者的角度看:打包和部署

如今的互联网软件越来越碎片化(micro services),Queue无处不在,服务依赖越来越多,使得软件功能的开发,到软件功能的部署,中间有很长的一段路。这...

3529

扫码关注云+社区