本文目录导航：
为什么要继续集成?
在没有运行继续集成之前，传统的开发形式是名目一开局就划分模块，而后等一切的代码都开发实现之后再集成到一同启动测试，随着软件技术的开展，各种软件方法百花齐放，软件规模也在扩展，软件需求越来越复杂，软件曾经不能便捷地经过划分模块的形式来开发，须要名目外部相互协作，划 分模块这种传统的形式的弊病也越来越显著，由于很多 bug 在名目标早期就存在，到最后集成的时刻才发现疑问，开发者须要在集成阶段破费少量的期间来寻觅 bug 的根源，加上软件的复杂性，疑问的根源很难定位，甚至发生不得不调整底层架构的状况，在这个阶段的除虫会议（bug meetings）特意多，会议的内容基本上都是探讨 bug 是怎样发生的，最后往往开展成为不同模块的担任人相互推诿责任。
继续集成最大的好处是可以防止这种传统形式在集成阶段的除虫会议。
继续集成主张名目标开发人员频繁的将他们对源码的修正提交(check in)到一个繁多的源码库，并验证这些扭转能否对名目带来了破坏，继续集成包含以下几大要点：访问繁多源码库，将一切的源代码保留在繁多的地点（源码控制系统）， 让一切人都能从这里失掉最新的源代码（以及以前的版本）。
允许智能化创立脚本，使 创立环节齐全智能化，让任何人都可以只输入一条命令就实现系统的创立。
测试齐全智能化，要求开发人员提供自测试的代码，让 任何人都可以只输入一条命令就运转一套完整的系统测试。
提供主创立，让任何人都可以只输入一条命令就可以开局主创立。
倡议开发人员频繁的提交（check in）修正过的代码。
继续集成的关键是齐全的智能化，读取源代码、编译、衔接、测试，整个创立环节都应该智能实现。
关于一次性成功的创立，要求在这个智能化环节中的每一步都不能出错，而最关键的一步是测试，只要最后经过测试的创立才是成功的创立。
在继续集成外面创立不再只是传统的编译和衔接那么便捷，创立还应该包含自测试，自测试的代码是开发人员提交源码的时刻同时提交的，是针对源码的单元测试（源自 XP 的通常），将一切的这些自测试代码整合到一同构成测试集，在 一切的最新的源码经过编译和衔接之后还必定经过这个测试集的测试才算是成功的创立。
这 种测试的关键目标是为了验证创立的正确性，M cConnell 称之为冒烟测试，在 继续集成外面，这 叫做集成验收测试Build Verify Test，简称 BVT。
BVT 测试是品质的基础，QA 小组不会感遭到 BVT 的存在，他们只针对成功的创立启动测试（如配置测试）。
BVT 测试应该尽量的详尽，详尽的测试才干发现更多的疑问，而由此失掉的反应结果也更有参考意义，测试应该所有口头终了，这样失掉的反应结果才是完整的，而不是遇到失误就丢弃测试环节。
继续集成和日创立相比还有以下特点：继续集成强调了集成频率，和日创立相比，继续集成显得愈加频繁，目前介绍的最佳通常是每一个小时就集成一次性。
继续集成强调及时反应，日创立的目标是失掉一个可以经常使用的稳固的颁布版本，而继续集成强调的是集成失败之后向开发人员提供极速的反应，当 然成功创立的结果也是失掉稳固的版本。
日创立并没有强调开发人员提交（check in）源码的频率，而继续集成激励并允许开发人员尽快的提交对源码的修正并失掉尽快的反应。
从下面列出的续集成和日创立相比的特点来看，很显著， 频率和反应这两个词发生的特意多，持 续集成有一个与直觉相悖的基本要点，那 就是 经常性的集成比偶然集成要好。
Martin Fowler 以为关于继续集成来说，集成越频繁，成果越好 ，假设你的集成不是经常启动的（少于每天一次性），那么集成就是一件痛苦的事件，假设集成偶然才启动一次性（一周甚至一个月）， 等到集成阶段发现bug，而后找要素处置bug，会消耗你少量的期间与精神，而且这种形式有点象传统的集成形式，这违反了继续集成的初衷。
依据Martin Fowler 的观念，名目 bug 的参与和期间并不是线性增长的相关，而是和期间的平方成正比，两次集成距离的期间越长，bug 参与的数量越超越你的预期，处置 bug 付出的上班量也越大，而你越觉得付出的上班量越大，你就越想推早退以后去集成，希图到最后一次性性处置疑问，结果 bug 发生的就更多，造成下一次性集成的上班量更大，你越觉失掉集成的痛苦，就越将集成的期间推后，最后构成恶性循环。
因此假设集成的结果是让你感到痛苦，兴许就说明你应该更频繁地启动集成。
频繁的集成和及时的反应鞭笞着名目小组踊跃的面对疑问，而 不是将疑问推到最起初处置，如 果方法正确，更频繁的集成应该能缩小你的痛苦，让你浪费少量期间。
由于继续集成最终是经过测试来验证创立，所以你会发现关于继续集成的频率的要求跟Kent Beck 提出的测试驱动的开发方法外面测试第一的理念齐全分歧。
须要留意的是从名目标一开局就引入继续集成可以尽早的发现 bug，然而并不代表继续集成可以帮你你抓到一切的 bug。
继续集成的排错才干取决于测试技术，妇孺皆知，不可证实曾经经过测试的代码就曾经找到了一切的失误。
极限编程（XP）十二个最佳通常不包含（）。
【答案】：D极限编程是一种轻量级（矫捷）、高效、低危险、柔性、可预测、迷信软件开发形式。
4大价值观： 沟通、便捷性、反应和勇气。
5个准则：极速反应、便捷性假定、逐渐修正、倡议更改和优质上班。
12个最佳通常：方案游戏（极速制订方案、随着细节始终变动而完善）、小型颁布（系统设计要能够尽或者早地交付）、隐喻（找到适宜比喻传播消息）、便捷设计（只处置应前需求，使设计坚持便捷）、测试后行（先写测试代码，而后再编写程序）、重构（从新扫视需求和设计，从新明白地形容它们以合乎新和现有需求）、结队编程、群体代码一切制、继续集成（可以按日甚至按小时为客户提供可运转版本）、每周上班40个小时、现场客户和编码规范。
影响软件开发上班效率的关键要素有哪些，并解释怎样才干提高软件开发的消费率?
影响软件开发上班效率的关键要素有以下几个：
1.需求变卦和不明白的需求：需求的频繁变卦和不明白的需求会造成开发团队在开发环节中频繁调整和从新上班，从而影响上班效率。
2.技术选型和复杂性：选用不适宜的技术栈或面临复杂的技术应战会参与开发的难度和上班量，降落上班效率。
3.不足协作和沟通：开发团队外部成员之间的协作和沟通十分关键。
不足良好的沟通和协作会造成消息不疏通、义务重复和抵触，降落上班效率。
4.不正当的上班流程和工具：不足高效的上班流程和实用的工具会影响开发的效率。
例如，不足版本控制、智能化测试和部署等工具和流程，会参与开发的累赘。
5.不足规范和规范：不足一致的开发规范和规范会造成代码品质不分歧，参与保养和调试的难度，从而影响上班效率。
要提高软件开发的消费率，可以思考以下措施：
1.明晰的需求治理：与名目相关方充沛沟通，明白需求，防止频繁的变卦。
经常使用矫捷开发方法，如Scrum，可以协助团队更好地治理需求。
2.技术评价和培训：在名目开局行启动充沛的技术评价，选用适宜的技术栈。
同时，确保团队成员具有必要的技术才干，并提供培训和学习时机。
3.增强团队协作和沟通：建设良好的团队气氛，促成成员之间的协作和沟通。
经常使用协作工具和会议来分享消息、处置疑问和协调上班。
4.提升上班流程和工具：评价现有的上班流程和工具，寻觅可以提升和智能化的环节。
引入版本控制、智能化测试、继续集成等工具和流程，提高开发的效率和品质。
5.规范和规范化：制订一致的开发规范和规范，确保团队成员遵照一致的编码格调和最佳通常。
经常使用代码审查等形式来提高代码品质和可保养性。
6.继续学习和改良：软件开发畛域始终变动和开展，团队成员应继续学习新技术和工具，关注行业的最佳通常，并及时改良上班方法和流程。
经过以上措施，可以提高软件开发的消费率，放慢名目进展，提高代码品质，并增强团队的协作和发明力。
以上内容是由
