Chapter02软件工程.pptVIP

Pair Programming XP中，所有的代码都是由两个程序员在同一台机器上一起写的——这是XP中让人争议最多、也是最难实施的一点。这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因此得到提高。看起来这样象是在浪费人力资源，但是各种研究表明事实恰恰相反。——?这种工作方式极大地提高了工作强度和工作效率。? 很多程序员一开始是被迫尝试这点的（XP也需要行政命令的支持）。开始时总是不习惯的，而且两个人的效率不会比一个人的效率高。这种做法的效果往往要坚持几个星期或一两个月后才能很显著。据统计，在所有刚开始Pair?Programming的程序员中，90%的人在两个月以后都很认为这种工作方式更加高效。? 项目开发中，每个人会不断地更换合作编程的伙伴。因此，Pair?Programming不但提高了软件质量，还增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解。这不但有利于个人，也有利于整个项目、开发队伍和公司。从这点看，Pair?Programming不仅仅适用于XP，也适用于所有其它的软件开发方法。? Collective ownership 在很多项目开发过程中，开发人员只维护自己的代码，而且很多人不喜欢其他人随意修改自己的代码。因此，即使可能有相应的比较详细的开发文档，但一个程序员却很少、也不太愿意去读其他程序员的代码；而且，因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代码。同时，因为是自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被发现或得到比较好的解决。 针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量是非常好。为了防止修改其他人的代码而引起系统崩溃，每个人在修改后都应该运行测试程序。 Continuous integration 在很多项目中，开发人员往往很迟才把各个模块整合在一起。在这些项目中，开发人员经常在整合过程中发现很多问题，但不能肯定到底是谁的程序出了问题；而且，只有整合完成后，开发人员才开始稍稍使用整个系统，然后就马上交付给客户验收。对于客户来说，即使这些系统能够通过终验收测试，因为使用时间短，客户门心里并没有多少把握。? 为了解决这些问题，XP提出，整个项目过程中，应该频繁地，尽可能地整合已经开发完的USER?STORY（每次整合一个新的USER?STORY）。每次整合，都要运行相应的单元测试和验收测试，保证符合客户和开发的要求。 Continuous integration Sustainable pace 是指项目开发需要持续稳定的工作效率，是马拉松式的长跑，而不能通过跑百米的方式奢望一蹴而就。 Kent Beck 说他希望“...每天早晨都感到有活力有激情，每天晚上都感到疲惫而满足。”一周 40 小时工作可以让您做到这一点。确切的小时数并不重要，重要的是原则。长时间地持续工作会扼杀工作绩效。疲劳的开发人员会犯更多错误，从长期来说，将比按“正常”时间表进行的开发慢得多。 On-site customer 要使功能最理想，XP 小组需要在现场有一位客户来明确素材，并做出重要的企业决策。开发人员是不允许单独做这些事情的。让客户随时在场可以消除开发人员等待决策时出现的瓶颈。 XP 不会假装素材卡是开发人员交付必要代码所需的唯一指示。素材是对以后在客户和开发人员之间填写细节的对话的一项承诺。与将所有要求写在一个静态文档中不同，其思想是进行面对面的交流，减少产生误解的机会。 我们发现让客户在现场是可能最好的一种情形，但这不是解决问题的唯一方案。底线是客户必须随时在需要回答问题和根据企业价值为团队提供指示时有空。如果客户并非在现场专职陪伴团队的情况下就能做到这些，那很好。如果能和团队待在一起，这会更方便，但只是建议而已。? Coding Standards 代码在XP中被看作一项非常重要的在开发人员之间沟通的工具。毕竟软件反映了开发者的心智，开发人员的思想变为一行行代码被写在程序中，这是一门艺术。但艺术也要有人去欣赏，如果每个人都看不懂其他人的艺术，那么怎么进行沟通呢？ XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是是实现Collective?Code?Ownership的重要前提之一。 Coding Standards 界面设计 流程设计 建模规范 编码规范 持久层设计 测试数据 Process models pr