软件工程作业一.docVIP

小论文：关于极限编程 作为敏捷软件开发领域主流的开发方法，极限编程与其说是一种系统的方法学，倒更像是一系列最佳实践的有机结合。在这些最佳实践中，有些是已经广为人们所接受的（如编码标准）。目前，极限编程已经成为一个典型的开发方法广泛的应用于需求模糊且经常改变的场合，而更多的则极具颠覆性，初看之下让人似乎难以接受。 本文中，我将针对这些看似怪异的最佳实践阐述我的观点，并简述我对实施这些最佳实践的一些思考。 一、 在XP中，人们经常会使用隐喻来代替传统开发过程中的体系结构设计。从指导开发的角度来说，隐喻似乎不够精确，容易让人误解。但是，对于具有类似背景的同一个项目组中的开发人员来说，隐喻则更便于理解和交流。很难想象两个程序员面对着一张庞大的体系结构图时能够真正有效的沟通，而隐喻很好的解决了这个问题。 二、 在XP中，小版本发行的方法使得变化并不那么可怕，而重构的广泛采用，使得代码总是可以在需要时变得更加灵活。此外，由于你的代码总是会被别人审查（代码集体所有权和结对编程），因此也可以避免过于追求简单而忽视了重要的细节。 三、 没有代码要测试程序有什么用？这是测试优先最容易让人误解的地方。测试优先能够让软件开发人员更清楚的认识到，程序将会如何被使用。通过对不同的测试用例的思考，开发人员也能够更清晰的认识到程序的功能外延。而更多的其他的开发人员，则通过测试用例就可以获得一份精确的使用手册，在这份使用手册中，描述了作者考虑到的所有输入和输出结果，这样不仅便于人们了解程序，更增加了发现程序错误的机会（缺失的测试用例往往体现出作者忽视的某些使用情况）。 四、 两个程序员坐在一起，能够提高开发效率吗？程序员难道不是一群高傲的猫，习惯于离群索居，把头抬得高高吗？ 事实并非如此。在一个正确的、合理的、能够实现的大目标下，程序员们不仅能够和平共处，更可以相互合作，创造出优秀的、高质量的程序。沟通一直是软件项目管理中的一个重要议题，而结对编程提供了一个十分有效的沟通渠道。此外，结对编程也更容易让新人融入团体。在几个高级程序员的指引下，他会更容易找出程序的脉络，把握程序的思想。较之正规的培训，这种方式更轻松也更有效。对于团队中的所有程序员来说，结对编程都是一个了解其他人设计思想的机会，通过结对编程，能够更好的实现代码集体所有权，也能够降低因为人员流动造成的风险。 结对编程最大的好处在于，能够极大的减少程序中潜在变化的可能性。两个人通过交流互相交换自己对程序的不同理解，更容易找出程序中可能出现的变化或错误，从而使程序更加可靠和健壮。 五、 集成一直是最费力的工作之一，本来工作的好好的代码，放在一起就不能运转，更糟糕的是成百上千条不知所云的错误码，没有人知道这些错误码来自何处。这是每个项目几乎都会遇到的最困难的阶段，程序员们必须集合在一起，翻阅数量巨大的接口定义文件，反复查看代码，同时还要不断的做出承诺。 持续集成正是解决上述问题的方法。通过多次、小增量的集成，我们总是能够以最快的速度定位错误出现的位置（因为增加的代码很少），结合大量测试用例，我们也可以确保每一个集成版本都尽可能的可靠。 此外，持续集成几乎可以在任何时间向我们提供一个可以工作的版本，我们可以将这个版本用于内部讨论和测试、客户展示、客户测试、小版本发布等等，这使得我们不需要花费太多的时间对现有的程序修修补补，以生成一个demo。 上文简单叙述了XP中常会引起争议的六个最佳实践的优点。下面本文将结合实际谈谈实施XP中需要注意的一些问题。 一、 XP理论在提出时，明确的说明：XP是适用于中小型团队在需求不明确或者迅速变化的情况下进行软件开发的轻量级方法。这就意味着，XP并不适用于所有情况。在准备实施XP前，你也许需要仔细评估项目的具体情况，以决定是否真的需要采用XP。 二、 XP的一个特点是，它所推崇的最佳实践几乎总是和其它实践关联紧密，在实施一项最佳实践时，如果不同时实施其它实践，往往难以达到最初的目的。因此，在实施XP时，需要仔细研究各项实践间的关联，以确定最佳的实施方案。 三、 XP是一种追求自然的工作方法。它所倡导的是，程序员们以最自然开发的方式完成他们的工作。对于习惯了传统开发方法严格管理制度的管理人员来说，这往往是很难接受的。于是就出现了，虽然最高决策人决定实施XP，但管理层却无法（或不愿）给开发人员提供宽松的环境。在一个古板僵化的方框里，开发人员不会真正的回复自然，他们会装作正在实践XP，但事实上，他们依然在老路上行走（可以见到很多这样的例子，比如一些虚张声势的测试用例等等）。 四、 XP对于传统软件项目管理思想的冲击，可能会使很多管理人员感到不舒服。也许XP一经实施，就会给项目组带来翻天覆地的变化。如果这样的变化让你感到恐惧，那么请暂时忍耐，你不能肯定这种变化不好，除非你亲眼看到。到