辛德蕾拉|写了多年软件,我在软件性能上学到的 4 点教训


辛德蕾拉|写了多年软件,我在软件性能上学到的 4 点教训英文原文:
在职业生涯中 , 我至少参加了三个对软件性能表现有一定要求的项目 , 它们分别是 Livegrep 、 Taktician 和 Sorbet。 此外 , 我还对正使用的工具做了许多提升性能的工作 。
一、性能是软件的一个重要特性我很赞同这样一个观点 , 即软件性能不是独立于软件功能或软件特性集合的一个属性 。 性能(尤其是指能显著提升速度的性能)本身就是软件的一项功能 , 它从根本上改变了一个软件工具的使用和感知方式 。
在推出 Sorbet 后 , 我们从 Stripe 工程师那里得到大量反馈和赞赏 , 因为这个软件工具的性能非常优越 。
与之前缓慢的工具软件使用体验相比 , 开发人员真正体会到用高性能软件带来的快感(例如 , 对 Stripe 的代码库进行类型检查 , Sorbet 从冷启动加载都会比 Ruby 正常加载要快 , 更不用说执行其他代码 , 在我看来 , 这是 Ruby 生态不太好的地方) 。
我认为性能的价值在普遍意义上非常容易理解——许多工程师都知道并经常讨论响应时间感知阈值或 延迟对转换率的影响——但能真正理解性能内在含义的人实际上很少 , 大部分只是纸上谈兵 。 最近感觉抱怨软件运行速度缓慢的人很多 , 但是也很少有团队可以为此做些什么 , 以至于工具的性能变得越来越慢 。
从业经验告诉我 , 尽管我们的工具让编写高性能软件变得越来越难 , 但产出高性能软件不是没有可能 , 而且这一努力是值得的 。
二、性能改变了用户使用软件的方式毋庸置疑 , 用户更偏爱性能好、速度快的应用软件 , 因为与速度慢的软件相比 , 这会带来更好的用户体验 。
高性能软件改变了用户使用软件的方式, 这一点也许体现的不是很明显 。 用户通常会使用多种策略来实现目标任务 , 并且他们将会越来越频繁地选择使用更快的工具 。 性能更好的工具不仅可以帮助用户更快地完成任务 , 而且还能让用户以全新方式完成各种类型的任务 。
在做Sorbet 和Livegrep 工作时 , 我清楚地认识到这一点:
Sorbet 项目的主要目标之一是在开发过程中 , 为用户输入的代码提供快速反馈 。 Stripe 始终维护着一个扩展测试套件 , 该测试套件有较高的质量以及代码覆盖率 , 并且其运行时间始终维持在 10-15 分钟内 。 我们希望 Sorbet 可以减少一些软件测试和运行时错误 , 但是缩小测试用例或在生产环境中获得额外的安全性并不是我们的主要目标 。 相反 , 我们希望获得的最大收益是缩小开发过程的反馈循环 , 并使用户对其代码的操作反馈比以前更快 。
在开发环境中 , Stripe 的许多测试会执行 10-20 秒甚至更多 。 因为我们成功构建了 Sorbet , 所以可以在那个时间窗口内对整个代码库进行类型检查 , 这让开发人员能针对自己的代码获得合理的反馈 , 快速的检查基本输入问题、API 的不合理使用问题以及其他低级错误 。 这是他们为快速开发所做的选择 , 我们经常看到用户在产品开发和上线早期就选择 Sorbet 作为他们代码检查的工具 。 及时获得代码检查的反馈 , 这可以增加开发人员的信心 , 从而节省大量时间 , 这一点非常重要 。
快也意味着用户对误判有一定的容忍度(Sorbet 识别出的错误代码可能实际情况并不会出错) , 前提是软件知道如何解决错误(比如增加 T.must 声明) 。 如果 Sorbet 与 CI 的运行时间运行相近 , 比如 10 分钟左右 , 那么用户与 Sorbet 的关系将会是另一番样子 。 它必须在 CI 的基础上提供非常明显且有差异的附加价值 , 而且尽量不会为了兼顾 Sorbet 而要求用户进行更改 , 因为这个时候它不再具有向用户提供早期反馈的优势 。
观察用户使用 livegrep 的情况 , 我发现性能提升的另一个好处 。 Livegrep 的目标是在 100 毫秒内响应大多数搜索 ,100 毫秒这个阈值非空穴来风 , 它有据可查的 , 在此阈值内 , 大多数用户会感觉到响应几乎是瞬时的 , 没有什么滞后之感 。 由于 livegrep 是如此之快 , 用户能以一种交互的方式来使用它 , 这种交互方式在其他搜索引擎上几乎很少见到:用户输入一个初始查询 , 紧接着 , 如果得到大量或少量的搜索结果 , 用户可以根据结果列表进行再编辑 , 然后获得一组新的结果 , 这会进一步完善或扩展搜索条件 , 直到找到用户真正要查询的结果 。


推荐阅读