C++ 构建太慢的 5 个信号

Guy Golan
Guy Golan / 1月 30 2020
C++ 构建太慢的 5 个信号

从我的个人经验来看,我们每天庸庸碌碌,忙于处理各种各样的任务,但却并一定不了解这些处理方式背后的真实原因。与之相应地,我们自然也都不清楚每个决定背后的原因。在工作和个人生活上,大都如此。大家遵循着一种特定的模式处理日常事务,尽管这个模式并一定是最有成效的,但大家早已习以为常。

不过,还是有一些迹象或警告的信号暗示出这些模式在工作效率方面的“损失”。为了方便讨论,我们可以通过审问自己,为什么会以某种特定方式做(或不做)某件事,如果答案是:“因为总是这样做的”、“我们(完全)没有别的方法”、“如果没坏,就不用去修”,或是我最喜欢的理由:“尽管工作量大,但这就是解决的办法”——这些回答,都表明了其实有一个更好、更有效率的方式来完成这些任务。

因为长期在一家专注于减少任务构建和开发时间的公司工作,我对这些信号早已见怪不怪了。任务进展得越慢,如C++构建,这样的信号就出现得越多。

所以,如果你正在进行C++构建,以下任何一个信号出现,都意味着你的构建速度太慢,需要优化了。而市场上也有一些伟大的发明,可以用来优化任务,或者帮助我们更好地决策。不论这些工具是洗碗机还是搜索引擎,能解决问题,何乐而不用呢?

但首要的,还是要识别下面这些信号。

信号 #1:谁的构建出错了

如果你发现自己在不停地寻找那个破坏构建进程的人,这意味着提交的冲突已远超过你的处理能力,很明显你也没能参与每次提交。但如果你是通过信息发射源(Information Radiator)定位构建中断的原因,那问题不大。你需要确切地了解是谁打破了构建:找到创建提交的人。我们都希望能参与每一次提交,但是,这个过程需要频繁地构建。如果构建太慢,就不能用这种方式进行。否则,你将白白浪费太多时间,却一事无成。

另一个问题是自动化。备受赞誉的自动化进程也参与每一次提交,而且通常在构建失败时发送一个通知,出错者也将因此卷入一场修复、重新提交的紧张竞赛中(相信你也了解自动化工具和平台本身也有漏洞)

同时,也不要忘记封闭提交和封闭签入。字面理解,即创建提交时需要封闭签入,这些操作让构建保持清洁。

信号 #2: 新的团队焦虑:“通宵构建会成功吗?”

如果你“提交后不停地祈祷构建成功”,或者如果你痛苦地发现,夜间的构建再一次失败了(而且你没有任何能在白天交付的清洁构建)。这是一个信号。如果夜间构建让你焦虑不安,那就寻求专业的帮助吧。我指的不是那些治标不治本的药片,而是从根源上彻底解决问题的方案。

当你的构建速度快如闪电,你可以一直进行构建。我再重复一遍:一直。一个构建失败了(希望只是其中的一次提交出错)别担心,另一个会很快跟上。你有听过“Joel 测试”吗,Joel推荐在白天进行构建。所以,在晚上,除了睡觉不要做任何事,远离焦虑(与构建有关的焦虑),回归美好生活。

信号 #3: “让我们减少测试”

敏捷和高速的发布需要我们在一些测试上做出让步。测试把本来冗长的构建时间拉得更长,所以你时常禁不住想:“到此为止吧,让我们跳过这一步。”另一个情境是忽略一些失败的测试结果,然后盲目推进。错误!大错特错!这些测试是构建的保护网,而安全保护再多也不为过。集成测试、回归测试(完整的)、单元测试——这些工作,都是必不可少的,以确保产品质量和用户体验,你不能不重视。

在C++的情况下,运行更多的测试尤其重要,一个错误的组件引发另一个组件错误,这种连环效应是尤其常见的。如果你不但能在每个构建/提交上运行单元测试,而且还可以运行集成测试,这样就可以有效避免跨团队的挫败和毫无意义的责备,同时省下大量时间。QA团队也会因此感激你,因为他们能够集中精力研究产品的新特性,而不是一直在监督产品质量上浪费时间。

所以,不停地测试,就像没有明天一样,就像测试是生命的必需品一样(实际上产品的生命力依赖于测试),测试多多益善。你应该根据产品和用户的效益做决定,而不是为了缩短构建时间而仓促了事。你的思考过程应该更多地遵循这样的思路:“完整的回归测试?”确定。集成测试?当然。”

信号 #4: “什么是静态代码分析?”

当你逼着自己要记住什么是 静态代码分析——另一个坏信号出现了。这意味着你现在没有做过,甚至,你从来没有试过。不过这确实是一个让人头疼的过程。从头到尾一行一行地检查这些代码,确实是不容易,对构建时间的影响也不容忽视。然而,静态代码分析的好处确是巨大的。毕竟,代码质量是基础,静态代码分析能高效定位有问题的模式,还可以检测代码中的安全漏洞(这是近来的热门话题)。但对构建时间的影响呢?我们还是不要去想这个问题吧。

信号 #5: “我不要增加这个——会拖慢我的构建”

今天的所谓奢侈品,会成为明天的必需品。在开发进程中增加工具集和功能集,如开源工具、第三方商业库、以及扩展当前的基础架构(测试覆盖面),对构建大有裨益。但是,如果你忽略了这些“奢侈品”,原因不是预算问题,而是构建时间会延长,这也是一个不好的信号。不论构建时间多长,都应该积极进行扩展,增加各种有效的工具集,扩大测试覆盖面(甚至在没有构建单元帮助的情况下添加预提交测试)。

惊吓之余,改如何处理这些信号?

首先,不论如何,你都可以被吓到,适当的情绪发泄是好的。但是看到这些信号之后却无动于衷,这才不好。惊吓之后,请微笑应对:你还有很多选择(控制修复)。你可以选择重新编排代码,储备硬件库存,或者可以使用 IncrediBuild,保持代码(以及基础架构和硬件设施)完整。所以,现在能够微笑面对了吗?

未想到的路

“未想到的路”更像是“未选择的路”的延伸。在耗尽你的耐心之前,我想进行另一种解释。寻找快速构建的方法更像是“未想到路”,而不是“未选择路”。一旦真正看到了这些信号,也许你就会灵光一现,立刻想到优化构建时间的最佳方法!希望我的建议能为你带来一些灵感,剩下的就靠你自己了。

订阅博客

阅读 Incredibuild 独家内容

Guy Golan