XP方法学习总结及对小组开发的思考
类别: ASP.NET教程 
XP方法的许多特点都能在目前公司的开发过程中找到影子，在阅读了相关资料后，可以从中得到很多的收获，下面将扼要的列出一些我所认为很有帮助的关键点。
XP中强调每个人对代码都有权利修改，这样的方式其实在小组内部已经被默许了，在小组中以后应该贯彻这样的原则，鼓励每个成员对整个系统的代码进行合理的修改，根据个人体会，这样的修改一般都是有利的，即使会导致一些小的影响，但一般都能很快克服。
强调时间的利用，实际上在XP方法中反复强调的是，一些正规化的讨论和大量的文档某种意义上来说是一种无用功，想一想，我们有多少的时间被这样的无用功所吞噬？当然这样的原则并非提倡无文档化，文档的产生要根据具体环境来定，我的观点是，很难确定一种文档固定的模式，文档的作用是解决一些信息沟通中的差异，例如目前为了解决同用户的交流，就很有必要提供一个简单的几页纸的系统说明，这一点不在这里展开。
另外XP强调贯穿在开发过程中的简单原则，强调“轻装上阵”，因此在我们的项目中也要在每个成员的思想中牢牢的贯彻这样的思想，一段时间用来编码、写注释、设计、测试都是有效的，这也是印证XP中一个基本的原则：代码能够传递所有的信息，为代码工作是最直接也是与产品联系最紧密的工作，由此引发的思考是，设计是为了更好的编码、注释是为了提高代码的可阅读性、测试是为了提高代码的正确性，所有这一切都是直接或间接的为代码工作，在实际中，很多人都发现，一些不实用的文档重复使用频率是相当低的，因此，这一点原则对我的启发相当大，也更能让我把重点放在编码、设计和测试上，也能打消我以前存在的一些疑惑：如果不编写漂亮和规范化的文档就说明了我们小组的开发效率是低下的，进而也说明我们的产品质量是不能保证的，进而也说明我们公司的竞争力是低下的？比如对一些关键的编程任务抽取一段时间同小组成员成对编写，在一个人编写代码的过程中，另一个人利用纸、笔或其他工具进行设计和构思、或者一个人编码、另一个人查找一些相关的资料，设计测试用例子等，至于对测试用例子的规范化、对设计的文档化等等问题其实是相当耗费时间的，可以将其份量减轻。XP中提倡开发人员的尊重及某种程度上的自由化，其实这样的思想也是符合软件开发行业的特点的，软件开发是一个脑力密集的工作，开发人员的个人因素相当大程度上影响着软件产品的质量，尽可能根据开发人员的爱好兴趣营造舒适的工作环境其实也是间接的在提高软件产品的质量，况且还有XP中如此强调的严格测试在进行监督，管理人员完全可以放心的等待合格和健壮的软件产品。记得看过一篇文章介绍，有了Word之后发现有时候工作效率反倒降低了，以为使用者把大量的时间花在如何做出一份漂亮的文档。我个人认为文档的作用是对某种约定或结论的文字记录，以便可以随时查阅、提醒。比如开发规范、需求分析等等。这一点和作者的“文档的作用是解决一些信息沟通中的差异”有一些差异。有很多东西我们在得到一致的结论后如果没有文档作为记录的话很容易遗忘，这一点和程序中的注释是一样的。但文档是否要严格的按照程序规范去做就可以灵活掌握了。正规化的讨论我认为很有必要，我理解的正规化的讨论是有明确的议题，参与讨论的人也应该对议题有一个事先的了解，在得出结论后需要有相关的文档既要进行记录。最重要的问题是正规化的讨论可以解决一些重要的问题。一般性的讨论如技术、设计等方面的讨论可以随时进行，但也应该视情况对结论进行记录。
2.“一段时间用来编码、写注释、设计、测试都是有效的”。我个人认为这句话更适合用在基本框架已经确定，只是个体部分具体如何实现的时候才使用。如果客观条件许可最好还是将整个结构、框架等大的东西事先确定，否则很难保证边做边想的情况下不会出现问题。
3.“至于XP中反复强调的成对编程，我也深深的被其中所体现的优点所打动”。成对编程的好处是可以用两个人考虑同样的问题来尽量减少思维的盲点，同时两个人对同样的问题达成共识后可以并行进行多项工作，“或者一个人编码、另一个人查找一些相关的资料，设计测试用例子等”，实际上是通过增加人员配置来缩短开发周期。而“在一个人编写代码的过程中，另一个人利用纸、笔或其他工具进行设计和构思”，如果两个人不能达成共识并衔接得当的话，成对编程的作用将要大打折扣。
4.“至于对测试用例子的规范化、对设计的文档化等等问题其实是相当耗费时间的，可以将其份量减轻”，这我认为是必要的。如果系统复杂程度比较小，那么做这些工作也花不了多少时间。如果系统复杂程度高不这样做是死路一条。但这些工作的成果是体现在其实际效用上，而不是形式上的规范化、标准化上。这方面的掌握上就需要丰富的经验了。
5.“XP中提倡开发人员的尊重及某种程度上的自由化，其实这样的思想也是符合软件开发行业的特点的”。这种观点还是赞同的，但协作开发必须要有规章制度，否则项目将进入到混乱的状态，也就无法实现对开发人员的尊重.
欢迎经
XP中强调每个人对代码都有权利修改，这样的方式其实在小组内部已经被默许了，在小组中以后应该贯彻这样的原则，鼓励每个成员对整个系统的代码进行合理的修改，根据个人体会，这样的修改一般都是有利的，即使会导致一些小的影响，但一般都能很快克服。
强调时间的利用，实际上在XP方法中反复强调的是，一些正规化的讨论和大量的文档某种意义上来说是一种无用功，想一想，我们有多少的时间被这样的无用功所吞噬？当然这样的原则并非提倡无文档化，文档的产生要根据具体环境来定，我的观点是，很难确定一种文档固定的模式，文档的作用是解决一些信息沟通中的差异，例如目前为了解决同用户的交流，就很有必要提供一个简单的几页纸的系统说明，这一点不在这里展开。
另外XP强调贯穿在开发过程中的简单原则，强调“轻装上阵”，因此在我们的项目中也要在每个成员的思想中牢牢的贯彻这样的思想，一段时间用来编码、写注释、设计、测试都是有效的，这也是印证XP中一个基本的原则：代码能够传递所有的信息，为代码工作是最直接也是与产品联系最紧密的工作，由此引发的思考是，设计是为了更好的编码、注释是为了提高代码的可阅读性、测试是为了提高代码的正确性，所有这一切都是直接或间接的为代码工作，在实际中，很多人都发现，一些不实用的文档重复使用频率是相当低的，因此，这一点原则对我的启发相当大，也更能让我把重点放在编码、设计和测试上，也能打消我以前存在的一些疑惑：如果不编写漂亮和规范化的文档就说明了我们小组的开发效率是低下的，进而也说明我们的产品质量是不能保证的，进而也说明我们公司的竞争力是低下的？比如对一些关键的编程任务抽取一段时间同小组成员成对编写，在一个人编写代码的过程中，另一个人利用纸、笔或其他工具进行设计和构思、或者一个人编码、另一个人查找一些相关的资料，设计测试用例子等，至于对测试用例子的规范化、对设计的文档化等等问题其实是相当耗费时间的，可以将其份量减轻。XP中提倡开发人员的尊重及某种程度上的自由化，其实这样的思想也是符合软件开发行业的特点的，软件开发是一个脑力密集的工作，开发人员的个人因素相当大程度上影响着软件产品的质量，尽可能根据开发人员的爱好兴趣营造舒适的工作环境其实也是间接的在提高软件产品的质量，况且还有XP中如此强调的严格测试在进行监督，管理人员完全可以放心的等待合格和健壮的软件产品。记得看过一篇文章介绍，有了Word之后发现有时候工作效率反倒降低了，以为使用者把大量的时间花在如何做出一份漂亮的文档。我个人认为文档的作用是对某种约定或结论的文字记录，以便可以随时查阅、提醒。比如开发规范、需求分析等等。这一点和作者的“文档的作用是解决一些信息沟通中的差异”有一些差异。有很多东西我们在得到一致的结论后如果没有文档作为记录的话很容易遗忘，这一点和程序中的注释是一样的。但文档是否要严格的按照程序规范去做就可以灵活掌握了。正规化的讨论我认为很有必要，我理解的正规化的讨论是有明确的议题，参与讨论的人也应该对议题有一个事先的了解，在得出结论后需要有相关的文档既要进行记录。最重要的问题是正规化的讨论可以解决一些重要的问题。一般性的讨论如技术、设计等方面的讨论可以随时进行，但也应该视情况对结论进行记录。
2.“一段时间用来编码、写注释、设计、测试都是有效的”。我个人认为这句话更适合用在基本框架已经确定，只是个体部分具体如何实现的时候才使用。如果客观条件许可最好还是将整个结构、框架等大的东西事先确定，否则很难保证边做边想的情况下不会出现问题。
3.“至于XP中反复强调的成对编程，我也深深的被其中所体现的优点所打动”。成对编程的好处是可以用两个人考虑同样的问题来尽量减少思维的盲点，同时两个人对同样的问题达成共识后可以并行进行多项工作，“或者一个人编码、另一个人查找一些相关的资料，设计测试用例子等”，实际上是通过增加人员配置来缩短开发周期。而“在一个人编写代码的过程中，另一个人利用纸、笔或其他工具进行设计和构思”，如果两个人不能达成共识并衔接得当的话，成对编程的作用将要大打折扣。
4.“至于对测试用例子的规范化、对设计的文档化等等问题其实是相当耗费时间的，可以将其份量减轻”，这我认为是必要的。如果系统复杂程度比较小，那么做这些工作也花不了多少时间。如果系统复杂程度高不这样做是死路一条。但这些工作的成果是体现在其实际效用上，而不是形式上的规范化、标准化上。这方面的掌握上就需要丰富的经验了。
5.“XP中提倡开发人员的尊重及某种程度上的自由化，其实这样的思想也是符合软件开发行业的特点的”。这种观点还是赞同的，但协作开发必须要有规章制度，否则项目将进入到混乱的状态，也就无法实现对开发人员的尊重.
欢迎经
- 上一篇: 程序员的.NET时代(二）
- 下一篇: 以武?的?角??蛘f.NET程序?的倚天之?
