22 lines
1.7 KiB
Markdown
22 lines
1.7 KiB
Markdown
---
|
||
title: Integration Hell
|
||
localeTitle: 整合地狱
|
||
---
|
||
## 整合地狱
|
||
|
||
Integration Hell是一个俚语，当开发团队的所有成员都经过随机时间实现代码的过程时，无法将不同的代码片段合并到一个无缝的代码中。开发团队将不得不花费几个小时或几天来测试和调整代码，以使其全部工作。
|
||
|
||
实际上，较长的组件是孤立开发的，界面越容易偏离预期。当组件最终在项目结束时集成时，它将花费更多的时间而不是分配，通常会导致最后期限压力和难以集成。在项目结束时这种痛苦的整合工作是同名的地狱。
|
||
|
||
持续集成，开发团队应该使用特定工具来“持续集成”他们每天多次处理的代码部分，以便工具可以将不同的“代码块”匹配在一起，以便更加无缝地集成比以前。
|
||
|
||
代码存储库，像Git（它是我们都知道和喜欢的开源接口，GitHub）允许开发团队组织他们的工作，这样可以花更多的时间来编码，而不用担心代码的不同部分是否全部集成。
|
||
|
||
[持续集成](https://guide.freecodecamp.org/agile/continuous-integration/)是解决这一问题的敏捷解决方案。集成仍然很痛苦，但至少每天这样做会使接口不会过分分散。
|
||
|
||
#### 更多信息：
|
||
|
||
* [避免整合地狱](https://tobeagile.com/2017/03/08/avoiding-integration-hell/)
|
||
* [整合地狱](http://wiki.c2.com/?IntegrationHell)
|
||
* [通过持续集成避免“整合地狱”的五大提示](https://www.apicasystems.com/blog/top-5-tips-avoid-integration-hell-continuous-integration/)
|
||
* [D-Zone关于Integration Hell的文章以及Continous Integration如何帮助它几乎成为过去](https://dzone.com/articles/continuous-integration-how-0) |