Yohai West
著名的未来学家 Ray Kurzweil 主要凭借对未来预测的准确性而闻名世界。在他过去 30 多年的 147 次预测中，有86% 的预测都被证实了。几乎比得上电视剧《辛普森一家》了！因此，我们也可以说他很擅长观察我们的成长和发展。
1999 年，Kurzweil 预测称到了 2020年 的时候，我们的手机将和我们一样聪明。他说对了吗？我们分析一下！一方面，我们的手机能够进行图像和语音识别、自动回话，还能检测电信欺诈。从本质上讲，手机是处理大量数据的紧凑型超级计算机。
另一方面，人类仍需继续设计、编译和编程机器工作所需的软件和芯片。关于 Kurzweil 的预测，有趣的是，他低估了我们对手机的重视程度——我们重视手机甚至超过了我们对其他人的重视程度。不相信我吗？我们进行一个快速的思维实验。假如你正身处商场，你的手机和你的孩子都丢了。你先找的是哪个？这个场景可能有些极端；那我们再来看一下不那么极端的一个场景。你开车的时候，多久看一次手机？即使你明知道开车的时候看手机会大大增加发生致命事故的机率，你看了多少次？
没有什么万全之策
但真正的问题是，为什么我们还没有实现 Kurzweil 的预言呢？因为，说实话，事情没有那么简单。Fred Brooks 在 1987 年发表的有影响力的一篇论文《没有万全之策——软件工程的本质和意外》中提出，虽然目前取得了一些（在他看来是未来的）进步，但没有真正的方法可以可靠地实现任何软件项目的时间、成本和质量目标。Brooks 对我们能否找到一个万无一失的方法来防止软件开发变成一个无法控制的怪物持怀疑态度。
不过，我们再深入地探讨一下。从本质上讲，我们说的是我们要如何理解系统需求的业务逻辑。事故部分是所有这些我们可以解决的事情——要么通过更好的实践，要么通过更好的工具。我们把重点放在后者上——拥有更好的工具如何能够对减少事故发生数量提供帮助，并让团队人员更专注于开发的本质。
我认为有两件事几十年来没有改变——著名歌手 Willie Nelson 仍旧著名，而开发人员也仍旧还在等待产品编译完成。我们来看一下下面这幅 XKCD 创作的漫画。乍一看，你能看出最近 20 年来哪些方面没有发生变化吗？事实上，对于大多数开发人员而言，这一点还真的属实。
最近，Incredibuild 对各行业的300 多名管理人员进行了一项调查，为了找出他们开发周期的最大压力和问题所在。不出所料（基于我们目前正在谈论的内容），96% 的调查对象表示，2021 年他们的编译的时间增加了，三分之二以上的调查对象都表示大部分的时间都浪费在这上面了。我本以为开会是最浪费时间的事情，但我想这就是没有人找我做调查的原因吧，我压根就不知道人们关注的重点。
多任务处理的神话
上面的 XKCD 创作的漫画很有趣，但它也强调了开发人员的一个主要问题——内容切换。当我们不得不长时间等待完成构建或编译时，我们可以简单切换至其他平行发生的另一项任务，去打一下乒乓球比赛，去玩一下椅子对决等等，你知道我说的意思了吧。我们会在编码和阅读拉取请求之间交替进行，回答 Slack 的信息，或滚动浏览 Reddit。
我的想法是，好吧，还不是那么糟糕，我非常擅长多任务处理！但事实上，很抱歉，你可能并不擅长处理多任务。一些研究发现，事实上只有 2.5% 的人真正在同时进行多任务处理。通常,切换至第二项任务是一种错误的经济行为；我们在多任务处理方面比我们的自我认知要差得多。每次我们需要停下来，重新投入到不同任务中时，我们就会失去精力。在结束了一整天的工作内容转换之后，我们会感到更加疲惫。
这与构建时间如何影响你的 CI 管道密切相关。开发中的延迟将导致文本和分支的妥协，从而导致集成的频率有限(持续集成过程的一个关键部分)。这也让人很难断言“到底是谁破坏了构建”，延迟了对开发人员的关键反馈。
这也导致了可测试的构建达成得更晚，创造了 QA 瓶颈，从而导致了更高的缺陷风险。也就是说，这也会导致延迟发布、推迟热修复，并影响进一步的发展。
那我们还得到了什么？质量差，创造性解决方案少，开发人员体验差，最终客户体验也不好。
无论何事、无论何处、同时进行
嵌入式软件开发有时会让人觉得你在同时做一百万件事。你需要密切熟悉你软件的目标硬件，你需要考虑连接性、安全性和可用性，现在还需要考虑 AI 能力。就像我们在上面看到的那样，我们可能擅长“无论何事”的部分，但我们绝对不擅长“同时进行”。
你知道谁更擅长吗？SETI 可以。你可能不记得了，但几年前，美国国家航空航天局要求人们在电脑上安装了这个软件，便于在电脑空闲时间利用其闲置的计算能力。这个行为的目的是为了扩大其卫星和望远镜系统的能力，从而寻找太空中的生命迹象。为什么我提到了这些看似互不相关的事情呢？因为这就是 Incredibuild 思路（以及我们如何分配资源丰富的任务）的来源。
反思开发加速
SETI 利用计算能力和闲置的内核来提高卫星覆盖范围，而开发加速也使用了同样的概念，只不过是为了加速你嵌入式软件的构建时间。我们通过两种方式实现该目的。
第一种方法是将计算核心池中的资源动态分配到需要的位置。开发加速解决方案将为正确的进程设置理想的内核数量，不必再手动请求正确的数量。
第二种，也许更为重要的不仅仅是在一个问题上投入计算能力。开发加速工具分解了开发工具进程，可以复用缓存的构建输出，并在整个网络网格中并行执行其余部分。简单来说，可以利用现有的缓存输出减少工作量，不必每次都从头开始，然后一步一步地完成所有工作。此外，可以将进程分配给实际的多任务处理，不必再等待线性构建完成，显著地减少了等待时间。
我们来看看后台的情况，以便接下来进一步的分析。
- 当你开始第一级 CI 并行化启动时，你的加速平台启动了——它拦截了你的启动，并使用独特的构建缓存技术，在输入不变的情况下，重新使用早期构建的缓存输出。
- 然后，把各开发进程分解成多个微进程，在我们托管的资源池中动态分配，实现微进程并行化启动。
事实确实如此。就这么简单！如果你想获得激励，则应将任务分解到微进程层面，这样也可以变得更加细化，能够获得对构建的更多可见性，识别到进程中的任何低效率。
语境转换——这个已经是老黄历了吧？
开发加速的目标——也是核心——是使整个生活变得更加容易。开发人员快乐公司也会快乐，而公司变得快乐之后，公司也会有快乐的客户。语境转换对开发人员来说永远是一个问题。毕竟，无限期地盯着几百万行的代码并不容易。但是，不得不等待构建完成的日子（也就是那些在办公室里举办乒乓球比赛或者在隔间内进行击剑比赛的日子）可能很快就会成为过去。
想一想，如果你能把时间缩短至 6 分钟，你为什么要让你的开发人员等待一个小时来完成构建——而且失败率也许要高达 95%，他们还得被迫再次重启。这段时间很长，当然也还是没有排练一遍《公主新娘》那么长，但能让我们去喝杯咖啡再回来继续工作。在一个理想世界里，那幅 XKCD 的漫画将成为新一代开发人员对过去问题的铭记。
