从我的个人经验来看，我们每天庸庸碌碌，忙于处理各种各样的任务，但却并一定不了解这些处理方式背后的真实原因。与之相应地，我们自然也都不清楚每个决定背后的原因。在工作和个人生活上，大都如此。大家遵循着一种特定的模式处理日常事务，尽管这个模式并一定是最有成效的，但大家早已习以为常。
不过，还是有一些迹象或警告的信号暗示出这些模式在工作效率方面的“损失”。为了方便讨论,我们可以通过审问自己，为什么会以某种特定方式做(或不做)某件事，如果答案是:“因为总是这样做的”、“我们（完全）没有别的方法”、“如果没坏，就不用去修”，或是我最喜欢的理由:“尽管工作量大，但这就是解决的办法”——这些回答，都表明了其实有一个更好、更有效率的方式来完成这些任务。
因为长期在一家专注于减少任务构建和开发时间的公司工作，我对这些信号早已见怪不怪了。任务进展得越慢，如C++构建，这样的信号就出现得越多。
所以，如果你正在进行C++构建，以下任何一个信号出现，都意味着你的构建速度太慢，需要优化了。而市场上也有一些伟大的发明，可以用来优化任务，或者帮助我们更好地决策。不论这些工具是洗碗机还是搜索引擎，能解决问题，何乐而不用呢？
但首要的，还是要识别下面这些信号。
信号 #1:谁的构建出错了
如果你发现自己在不停地寻找那个破坏构建进程的人，这意味着提交的冲突已远超过你的处理能力，很明显你也没能参与每次提交。但如果你是通过信息发射源（Information Radiator）定位构建中断的原因，那问题不大。你需要确切地了解是谁打破了构建：找到创建提交的人。我们都希望能参与每一次提交，但是，这个过程需要频繁地构建。如果构建太慢，就不能用这种方式进行。否则，你将白白浪费太多时间，却一事无成。
另一个问题是自动化。备受赞誉的自动化进程也参与每一次提交，而且通常在构建失败时发送一个通知，出错者也将因此卷入一场修复、重新提交的紧张竞赛中（相信你也了解自动化工具和平台本身也有漏洞）
同时，也不要忘记封闭提交和封闭签入。字面理解，即创建提交时需要封闭签入，这些操作让构建保持清洁。
信号 #2: 新的团队焦虑：“通宵构建会成功吗？”
如果你“提交后不停地祈祷构建成功”，或者如果你痛苦地发现，夜间的构建再一次失败了（而且你没有任何能在白天交付的清洁构建）。这是一个信号。如果夜间构建让你焦虑不安，那就寻求专业的帮助吧。我指的不是那些治标不治本的药片，而是从根源上彻底解决问题的方案。
当你的构建速度快如闪电，你可以一直进行构建。我再重复一遍：一直。一个构建失败了（希望只是其中的一次提交出错）别担心，另一个会很快跟上。你有听过“Joel 测试”吗，Joel推荐在白天进行构建。所以，在晚上，除了睡觉不要做任何事，远离焦虑（与构建有关的焦虑），回归美好生活。
信号 #3: “让我们减少测试”
敏捷和高速的发布需要我们在一些测试上做出让步。测试把本来冗长的构建时间拉得更长，所以你时常禁不住想：“到此为止吧，让我们跳过这一步。”另一个情境是忽略一些失败的测试结果，然后盲目推进。错误！大错特错！这些测试是构建的保护网，而安全保护再多也不为过。集成测试、回归测试（完整的）、单元测试——这些工作，都是必不可少的，以确保产品质量和用户体验，你不能不重视。
在C++的情况下，运行更多的测试尤其重要，一个错误的组件引发另一个组件错误，这种连环效应是尤其常见的。如果你不但能在每个构建/提交上运行单元测试，而且还可以运行集成测试，这样就可以有效避免跨团队的挫败和毫无意义的责备，同时省下大量时间。QA团队也会因此感激你，因为他们能够集中精力研究产品的新特性，而不是一直在监督产品质量上浪费时间。
所以，不停地测试，就像没有明天一样，就像测试是生命的必需品一样(实际上产品的生命力依赖于测试)，测试多多益善。你应该根据产品和用户的效益做决定，而不是为了缩短构建时间而仓促了事。你的思考过程应该更多地遵循这样的思路:“完整的回归测试?”确定。集成测试?当然。”
信号 #4: “什么是静态代码分析？”
当你逼着自己要记住什么是 静态代码分析——另一个坏信号出现了。这意味着你现在没有做过，甚至，你从来没有试过。不过这确实是一个让人头疼的过程。从头到尾一行一行地检查这些代码，确实是不容易，对构建时间的影响也不容忽视。然而，静态代码分析的好处确是巨大的。毕竟，代码质量是基础，静态代码分析能高效定位有问题的模式，还可以检测代码中的安全漏洞(这是近来的热门话题)。但对构建时间的影响呢?我们还是不要去想这个问题吧。
信号 #5: “我不要增加这个——会拖慢我的构建”
今天的所谓奢侈品，会成为明天的必需品。在开发进程中增加工具集和功能集，如开源工具、第三方商业库、以及扩展当前的基础架构（测试覆盖面），对构建大有裨益。但是，如果你忽略了这些“奢侈品”，原因不是预算问题，而是构建时间会延长，这也是一个不好的信号。不论构建时间多长，都应该积极进行扩展，增加各种有效的工具集，扩大测试覆盖面（甚至在没有构建单元帮助的情况下添加预提交测试）。
惊吓之余，改如何处理这些信号？
首先，不论如何，你都可以被吓到，适当的情绪发泄是好的。但是看到这些信号之后却无动于衷，这才不好。惊吓之后，请微笑应对：你还有很多选择（控制修复）。你可以选择重新编排代码，储备硬件库存，或者可以使用 IncrediBuild，保持代码(以及基础架构和硬件设施)完整。所以，现在能够微笑面对了吗？
未想到的路
“未想到的路”更像是“未选择的路”的延伸。在耗尽你的耐心之前，我想进行另一种解释。寻找快速构建的方法更像是“未想到路”，而不是“未选择路”。一旦真正看到了这些信号，也许你就会灵光一现，立刻想到优化构建时间的最佳方法！希望我的建议能为你带来一些灵感，剩下的就靠你自己了。
