从软件角度来说，要保持这样的优势就意味着必须尽可能缩短文档和开发阶段所占的时间。当然，保持软件的弹性也很重要，提供优秀的服务是 Algolia 的重要目标之一。我们有许多高端用户，搜索功能对业务有非常重要的影响，所以不能接受宕机时间，尤其是在黑色星期五之类的特殊时间段。
因此，开发者 必须在软件的弹性与创新之间找到合适的平衡点。 这两方面是相互牵制的：要让软件具有弹性，就要进行详尽的测试，这会消耗大量精力，占用我们进行创新的时间。因此，一个比较好的折衷方案就是在生产环境进行测试。
为什么要在生产环境进行测试？
在生产环境进行测试就是把新代码发布到生产环境中，直接用真实的生产数据和流量进行“测试”的过程。与之形成对比的就是运行全面的测试用例集。这个风险很大，开发者的第一直觉肯定不要这么做。但随着软件规模的发展，你会发现进行详尽的测试越来越不可能了。
让我们看看 Algolia 引擎。我们有二十多个查询参数。假设它们全是 Boolean 类型，那么要运行的用例总数就会达到一百万个，二十个参数，每个有两个可能值，那就是 2^20 种可能的场景。
谈到与测试相关的工作所要消耗的时间，有三方面要考虑：
-
写测试用例的时间
-
维护测试用例的时间
-
运行测试用例的时间
写出一百万个测试用例来，这个工作量已经很惊人了。一旦写出来，它们就成了项目内容的一部分。就像维护别的源代码一样，也要花精力去维护它们，所以每次软件迭代所要做的事情就更多了。
假设你的团队足够大，有充足的人力可以编写和维护这些测试用例，但运行它们一样需要不少时间。假设运行每个测试用例只需要 10 毫秒，那全运行一遍就需要 2 小时 45 分钟。不管代码中有什么更新，都需要花 2 小时 45 分钟才能验证完。
客户购买我们的产品不止是看中了当前已经具备的功能，更是看中了未来将会发布的功能。他们希望我们可以定期发布新功能，帮助他们成长，变得更容易创新和更具有弹性。因此，我们必须提升自己的效率。
在开发新功能时，我们只会写些简单的用例来验证功能，并对明显的边界条件进行测试。要对功能进行全面验证，我们会采取灰度发布的方式，直接在生产环境中进行测试。这样即使代码中有缺陷，也可以把对客户的影响控制得尽量小。通过这样的方法，我们就可以按时发布新功能了。
（编辑：新余站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
