在我的职业生涯中经常发现，通过了解在特定情况下不应该 做什么，可以学到更多知识。例如，在我职业生涯的早期，由于需要快速发布软件，我省略了单元测试，因为我认为不值得做这些工作。幸运的是，我已经学到绝不应该 将未经测试的代码投入生产；因此开始坚持编写单元测试。
整个 IT 行业似乎都主要采用这种学习方式；实际上，我们甚至专门创建了反模式（anti-pattern）这个词，表示在特定环境中不应该采用的做法。反模式是看起来似乎有好处，但是最终可能产生严重影响的解决方案。
看似真实的假象
遗憾的是，我发现当缺少经验的团队试图采用 CI 时，他们很可能错误地采用许多反模式，这最终导致他们不但没有获得预期的好处，反而遇到一大堆麻烦。不幸的是，在这种情况下，团队常常将麻烦归罪于 CI 本身。因此，我常常听到 “CI 不适合大项目” 或 “我们的项目太特殊，不适合采用 CI” 这样的说法，实际上 CI 根本不是问题的原因 — 是某些做法的不恰当应用或者缺少某些方法导致了这些麻烦。
在本文中，我要描述与 CI 相关的六个反模式：
签入不够频繁，这会导致集成被延迟
破碎的构建，这使团队无法转而执行其他任务
反馈太少，这使开发人员无法采取纠正措施
接收垃圾反馈，这使开发人员忽视反馈消息
所拥有的机器缓慢，这导致延迟反馈
依赖于膨胀的构建，这会降低反馈速度
如果您采用 CI 的时间足够长，那么几乎肯定体验过这些反模式的效果。这没关系，但是如果它们发生得太频繁，就会大大限制 CI 的好处。因此，如果您希望避免这些反模式并控制它们的负面影响，那么本文正适合您。
由于签入不够频繁导致的延迟集成
名称：签入不够频繁
反模式：由于所需的修改太多，源代码长时间签出存储库。
解决方案：频繁地提交比较小的代码块。
实施 CI 的前提是团队可以快速获得关于当前开发的代码的反馈；而且，与传统的集成相比，这种频繁的软件集成风格会减少集成花费的时间（和麻烦）。但是，有效的 CI 假设修改会频繁地发生（所以可以频繁地执行构建！）。如果代码长期留在开发人员的桌面（而不是存储库）中，那么就会出现糟糕的情况，因为在系统的不同部分中会出现其他修改。
从本质上说，如果不频繁地提交修改，集成就会延迟；延迟越长，消除其严重影响就越困难（比如其他人的修改可能会影响您的代码）。对于使用 CI 的项目，我建议开发人员至少 每天签入一次代码，但是我相信最好是每天签入多次。
任务越小，工作越轻松
文章来源于领测软件测试网 https://www.ltesting.net/
