 |
|
|
 首页 |
名片设计 CorelDRAW Illustrator AuotoCAD Painter 其他软件 Photoshop Fireworks Flash |
|
极限编程的核心有四个，交流、简朴、反馈和勇气，这四个原则大家在平时做项目的过程中一定也注重到了。但是两位大师Kent Beck 和 Martin Fowler能够把这四点归结在一起，使他们能够共同组成极限编程这架四轮马车，却是一个不小的创造的。 下面仅就自己的学习和简朴的实践过程中碰到的问题来谈谈自己对这四个核心的一些理解。 一、交流 1) 开发人员与客户的交流 这一点与传统的软件工程中有些类似，在平时开发软件的过程中也异常注意与客户的交流，特殊是在需求分析、概要设计以及验收测试的时候，开发人员与客户有效的交流是必不可少的，那将直接影响到一个项目是否能够符合客户的要求。 然而，在极限编程中客户所处的开发阶段有些不同，传统的项目开发过程中，客户只在最初的时候和最后的时候需要和开发人员在一起，他们的责任也就是在于业务功能上的帮助，但是这样就不可避免的导致了这样的一个状况：在项目最初的时候客户提出了错误的或者不正确的需求，然后项目组开始开发，客户很长一段时间不介入项目，而在项目验收的时候发现有些地方有错误或者需要修改，此时项目组不得不付出很多的时间和精力来适应客户的需求。这是时间和资金上很大的浪费。在极限编程中，需要一个异常精通业务的现场客户，他们不仅随时提供业务上的信息，而且要编写业务验收测试的测试代码，这样就可以在很大的程度上保证项目的方向不会错误。 极限编程的过程是“瞄准－》射击－》调整－》调整”的过程，并不强求在项目开始的时候就正确掌握项目的方向，由于有现场客户的存在，项目的方向是不断的调整中的，这样就可以极大程度上避免项目走弯路。 2) 开发人员之间的交流 当前在招聘开发人员以及其他一切的工作人员的时候，我们都会强调团队精神，但是在实际的工作过程中，我们除了在出现问题，而且自己解决出现很大困难的时候才会去请教别人（我以前是这样的，可能每个人都会不同），再就是大家能够一起聚在一起闲聊、吃饭、唱歌等等开发过程以外的活动。以上的这些的确可以使团队之中产生一定的凝结力，可以让大家和睦相处，但是离真正意义上的团队还有一定的差距。 我们所受到的教育一直培养的是一种独立解决问题的能力，所以，再碰到问题的时候我们想到的大多是自己来就解决，而不是和其他人一起来完成。 极限编程的实践中有一个异常重要的原则就是结对编程，这个原则看起来好像有些希奇。因为我们第一个想到的问题就是让两个人来同时做一件事情，那么不就是浪费了一个人的生产力了吗？但实际上并非如此，这里所谓的结对编程并非是一个人在编程，另一个在看着，另外一个人也同样起着异常重要的作用，他的大脑也在不停地运转，他需要帮助编码的人找到低级的失误，防止其编码出现方向性的错误，特殊是在出现一个正在编码的人不擅长解决的问题的时候，他会直接拿过键盘，与其交换角色，直接来进行编码。 这样做的好处也许只有在实践了之后才能够体会到，它不仅可以避免一些错误的发生，而且可以通过直接的讨论来解决一些轻易产生歧义的问题。而且两个人的思路碰撞出来的火花，能够更加迅速的解决问题。而且，在交流的过程中，大家的水平也会有很快的提高。结对编程的过程也是一起学习的过程。（只可惜我这里只有一个人，没有办法长期实践，但只要有机会我就会努力的） 3) 开发人员与治理人员的交流 在一个项目组里面，治理人员和开发人员之间的关系是影响项目的一个异常重要的因素，假如处理不好的化，可能会直接导致一个项目的失败。而治理人员所具备的素质更是要求很高的。假如是一个从技术人员转型的治理者，那么他的治理能力需要很大的提高，否则就会因为治理能力的缺乏而导致项目的混乱。而对于一个单纯的具备治理技能的人来说，如何能够得到技术人员的佩服是十分重要的，否则根本就无法使开发人员服从治理，那么他的位置也就岌岌可危了。 而且，假如开发人员能够和治理人员进行好的交流，那么他们的工作环境就会得到很大的改善，并不一定要异常豪华的房间和高级的家具，只需要一个可以异常舒适工作的环境，就可以让一个团队的战斗力得到很大的提升。而且，对于一个项目的计划和预算，假如开发人员能够提出自己的想法，就会避免最后争取到了项目却最终得不到利润的情况的出现。 治理人员也应该主动的听取开发人员的意见，很多的开发人员都是一些比较内向的人，假如不向他们询问，他们只会将自己心中的不满埋在心中，最后的结果是忽然的爆发，然后辞职离去，造成重大的损失。 二、简朴 1) 设计的简朴 在极限编程的过程中，提倡一种简朴设计的实践。这样做的原因是由于过多的设计文档会使我们浪费太多的时间在上面，而且设计文档没有不修改的，可能在项目结束的时候，我们会发现当初的设计文档早已经使面目全非了。 所以，我们在最初的设计工作中要做的是明确我们要实现的最重要的功能，然后设计出总体的框架和核心的技术，这些文档从头到尾不会超过十页纸，那样即使有了一些改变，我们也不需要花费太多的时间来进行修改了。特殊是在有了修改之后，我们不需要费很大的力气去让代码和文档完全一致了。 但是，简朴的设计并不意味着这些设计是可有可无的，相反，那简朴的几页纸更加重要，因为一个项目的核心内容都在上面，所以在编写的过程中一定要慎重。 2) 编码的简朴 编码的简朴表现在迭代的过程中，在极限编程的过程，并非要一下子实现所有需要的功能，也不需要一下子就完成以后不再改变，相反，变化在极限编程中是被提倡的。我们可以先简朴的实现一点功能，然后添加具体的内容，再后对程序进行重构，最终的代码将是异常简朴的，因为依照重构的原则进行修改了之后，所有的类和函数、过程都是异常简短而非冗长的，每一个模块完成的功能是异常明确的。 但是，不要把简朴和随意等同起来。尽管我们要实现简朴的编码，依然要有编码的标准，使得所有的人都能够很轻易的看懂我们编写的程序。其它象属性要使用名词来定义，过程要使用动词来开头的标准也是异常有用的，我们应该遵循。 3) 注释的简朴 在某些项目中，注释要求是异常严格的，甚至于规定在一个程序中注释量必须要达到一个百分比。这个初一看起来很有道理，因为注释能够让我们更好的理解程序的功能，但是细想一下，却完全不是那么一回事。 曾经有人说过“一般的程序员能够编写出计算机能看懂的程序，而一个真正的高手能够编写出普通人也能够看懂的程序”。的确是那样，与其让注释来解释程序，不如在给变量和过程、函数起名的时候用大家都能够理解的，那样即使没有太多的注释，另外的一个程序员想要读懂你写的程序也不是一件异常困难的事情了。 所以，在编写代码的过程中应该尽可能的使用代码本身来说明问题，而非借助注释的帮助，我们要编写的是代码，假如里面带有太多的无关轻重的代码，一方面会浪费我们的时间，还可能引起歧义；另一方面向微软的Windows源代码里面布满的发牢骚的注释就更不应该了。那些注释只是会给阅读代码的人带来分散注重力的效果了。 4) 测试的简朴 通常我们的项目假如是按照瀑布式开发的化，测试会全部放在编码完成之后，其中包括单体测试，集成测试，功能测试以及验收测试等等，而且大多数的测试是通过手工来完成的。所以依据经验来说，假如编码使用了20％的时间，测试至少要用掉40％以上的时间。而且在测试的过程中，还有好多问题需要修改，这也是导致测试耗费了大量时间的原因。 而在极限编程中，测试是通过编写测试代码来自动化完成的。特殊是在一些面向对象的编程环境中，我们可以使用xUnit工具来迅速、有效的进行单体测试。而且编写这些单体测试代码甚至可以是在正式编码之前。每一次修改了程序之后，都要运行测试代码来看程序是否有问题。而且对于程序的集成，极限编程提倡的是持续集成，也就是不断的将编写好的通过了单体测试的代码模块集成到编写完毕的系统中，在那里可以直接进行Test Suit的集成测试，从而保证代码不会影响到整个系统。 我们可以看到，极限编程中的编码和测试都是一小步一小步的进行的，这样就方便我们及时的发现并修改出现的错误。而自动化测试工具保证了我们的工作的效率，使我们避免了过多重复的工作。 返回类别: 教程 上一教程: 《Effective Java》学习笔记(3) 下一教程: java资料站点(添加几个中文的) 您可以阅读与"对极限编程四个核心的理解（一）"相关的教程: · 《Java极限编程》（Java Tool for Extreme Programming）读书笔记 （2） · 《Java极限编程》（Java Tool for Extreme Programming）读书笔记 （4） · 什么是Extreme Programming（极限编程，简称XP） · 对代理模式与Java动态代理类的理解 · JAVA中几个易混淆要害词的理解 |
  |
| 快精灵印艺坊 版权所有 |
首页 会员中心在线印刷在线编辑付款方式索取样品设计指南连锁门店
|
||
