在我的職業生涯中經常發現，通過了解在特定情況下不應該 做什么，可以學到更多知識。例如，在我職業生涯的早期，由于需要快速發布軟件，我省略了單元測試，因為我認為不值得做這些工作。幸運的是，我已經學到絕不應該 將未經測試的代碼投入生產；因此開始堅持編寫單元測試。
整個 IT 行業似乎都主要采用這種學習方式；實際上，我們甚至專門創建了反模式（anti-pattern）這個詞，表示在特定環境中不應該采用的做法。反模式是看起來似乎有好處，但是最終可能產生嚴重影響的解決方案。
看似真實的假象
遺憾的是，我發現當缺少經驗的團隊試圖采用 CI 時，他們很可能錯誤地采用許多反模式，這最終導致他們不但沒有獲得預期的好處，反而遇到一大堆麻煩。不幸的是，在這種情況下，團隊常常將麻煩歸罪于 CI 本身。因此，我常常聽到 “CI 不適合大項目” 或 “我們的項目太特殊，不適合采用 CI” 這樣的說法，實際上 CI 根本不是問題的原因 — 是某些做法的不恰當應用或者缺少某些方法導致了這些麻煩。
在本文中，我要描述與 CI 相關的六個反模式：
簽入不夠頻繁，這會導致集成被延遲
破碎的構建，這使團隊無法轉而執行其他任務
反饋太少，這使開發人員無法采取糾正措施
接收垃圾反饋，這使開發人員忽視反饋消息
所擁有的機器緩慢，這導致延遲反饋
依賴于膨脹的構建，這會降低反饋速度
如果您采用 CI 的時間足夠長，那么幾乎肯定體驗過這些反模式的效果。這沒關系，但是如果它們發生得太頻繁，就會大大限制 CI 的好處。因此，如果您希望避免這些反模式并控制它們的負面影響，那么本文正適合您。
由于簽入不夠頻繁導致的延遲集成
名稱：簽入不夠頻繁
反模式：由于所需的修改太多，源代碼長時間簽出存儲庫。
解決方案：頻繁地提交比較小的代碼塊。
實施 CI 的前提是團隊可以快速獲得關于當前開發的代碼的反饋；而且，與傳統的集成相比，這種頻繁的軟件集成風格會減少集成花費的時間（和麻煩）。但是，有效的 CI 假設修改會頻繁地發生（所以可以頻繁地執行構建�。�。如果代碼長期留在開發人員的桌面（而不是存儲庫）中，那么就會出現糟糕的情況，因為在系統的不同部分中會出現其他修改。
從本質上說，如果不頻繁地提交修改，集成就會延遲；延遲越長，消除其嚴重影響就越困難（比如其他人的修改可能會影響您的代碼）。對于使用 CI 的項目，我建議開發人員至少 每天簽入一次代碼，但是我相信最好是每天簽入多次。
任務越小，工作越輕松
文章來源于領測軟件測試網 http://www.kjueaiud.com/
