XP与VS2010的结合

XP 与VS 2010的结合

 

VS2010 已经发布了正式版，在这个新的工具中，有很多地方可以与XP结合。

XP （Extreme Programming）是极限编程，是敏捷编程中的一种。

极限编程中的思路是：

计划游戏，小版本，隐喻，简单设计，测试，重构，结对编程，集体所有权，持续集成，每周工作40小时，现场客户，编码标准。

在极限编程中，强调的是人，强调的是灵活。然而极限编程中在VSTS中能有怎样的结合呢？在这里，我只想说说我浅薄的想法。

在极限编程中的这些思路中，并不是所有的思路点都能在VSTS中得以实现的，这里，我只列举出来我觉的相关的，如有不正确之处，请大家指正。

VS 提供了许多版本，架构师的，开发人员的，测试人员的，还有数据库设计人员的，当然，在VS中，没有极限编程团队中的客户成员（也可以说成业务分析师）的版本，我们知道，客户往往是不懂开发技术的，所以用不上相对应的开发工具，但在TFS中，可以支持word，Excel，客户更多标准化的东西可以用office工具来完成。当然，这里只是说能把一些量化的用word或Excel 来记录，而不是说团队成员之间不交流，交流的结果总是需要记录或量化的。所以用VS相应的工具并不影响极限编程提倡的人与人的交互，反而把大家聚到一个统一的开发平台上进行协作。还有一点是如果使用者觉的TFS2010提供的过程模板（是基于杂MSF5.0的）太复杂，完全可以定制自己的过程模板来适应极限开发，这是一个开发的平台。还有TFS2010的安装大大减化，也为在VS2010中做敏捷编程提供了很大便利。

在计划游戏中的结果，我们可以把讨论的结果记录在一些word文档中，通过VSTS去控制、分发、保存。当然在计划游戏中，每个角色都在积累着自己的资源。业务分析人员更多的是描述，模仿业务的真实场景，架构人员就要从场景中抽象出要实现业务的技术及实现的框架，开发人员思考实现的方法，测试人员思考测试的种种用例，这些在可能会从自己的角度提出很多问题，大家讨论，分析，解决然后流程再向前推进。

从技术的角度考虑小版本，VSTS也能做的很好，因为VSTS在版本控制上已经非常完善，只要各个开发与测试到位，很快会通过Team Build来构建一个新版本的，当然，这里的小版本是迭代交付的一种版本，把一个完整的大项目，通过分化依次分批把功能交付客户。

测试，特别是单元测试，在VS中提供了非常强大的功能，可以自动生成针对方法的单元测试，并且还可以批量测试用例。

集体所有权和持续集成分对应VSTS中的源代码管理和Team Build。在XP中提到的集体所有权是让大家都能看到和有权修改不是自己写的代码，当然在VSTS中如果权限放开的话，是允许这样做的。XP提倡的是所有人都了解整个系统，所以每个人员都能检查出系统的问题，所以都有权修改代码，但这种修改也会有问题，当后者理解有偏差时，就会出现修改错误，VSTS可以通过权限来做到集体所有权，VSTS2010有了自己的“控制面版”，可以方便的来设置。同时，VSTS中可以存储用户的改动及旧版源代码，可以很容易恢复原有代码，当然这些修改与恢复都建立在一定的沟通机制上。集体所有权意味着我们都改动别人写的代码，在VS2010中，提供了一个“导航”功能，能方便的导般到文件，类，方法等你一时找不到的元素。持续集成可以对应到VSTS中的Team Build，因为这样，可以方便快捷的完成一个阶段版本的生成。当然，要求当前迭代中的所有的开发测试工作项完成，才能生成一个新的版本，否则只是一次Build。

编码的标准，在VS中可以很好的做到，本身微软的类库提供了一系列标准，并且是通过代码分析来约定的，当然这个标准如果与自己的标准不符合，可以写代码来生成自己的编码规则，可以在生成代码时就提示开发人员。关于这点可参照我别一篇博客《用自定义代码分析来标准开发偏听则暗的开发》 。

当然上面说的全是XP与VSTS结合的使用，VSTS不是为XP定做的开发工具，所以不可以100%的适合，我觉得可以灵活的运用。还有，XP强调的是人，人的主动性在整个过程中发挥重要作用，但人有自身的缺点，比如存储性差，这点可以用工具补上，还有人之间的组织是感性的，可延迟的，用工具会标准化人的一些行为等等。我个人理解，在小的开发团队中，如果能更好的协调人与工具，将给团队带来更高的开发效率。