极限编程-拥抱变化阅读感想（二）

    接上文-------------------------

    针对开发团队，XP同样提出了四个准则：沟通、简单、反馈、勇气
    项目中出现的问题无一例外总是出自那些不愿与别人探讨重要问题的家伙身上。沟通不良并不是偶然发生的，有很多情况会导致不良沟通。程序员向管理人员报告了一个坏消息，而管理人员却迁怒于他。客户告诉了程序员一些重要的事情，而程序员却把它当作耳旁风。这些都会在项目中埋下不少的坑，so XP需要雇佣一位教练，他的工作就是观察大家什么时候没有进行沟通，然后提醒大家。

    行动及其反馈之间的间隔是学习的关键，两者的区别在于为了胜利而比赛和为了不输而比赛之间。我所见到的大多数开发都是为了不输而比赛，写了大量文章，开了很多会，每个人都尽量按“规章”开发，不是因为它特别有道理，而是因为他们想在最后能够说这不是他们的过错-他们是遵照过程进行工作的。

    那么，回到基本问题，我们想从代码中学到什么呢？最重要的事情是学习。代码还给了我们进行简洁明了交流的机会。如果你有一种想法并把它解释给我听，我可能很容易发生误解。但是，如果我们一起对这想法进行编程，我能在你编写的逻辑中精确地读到你的想法。（so，不要说话，和我一起敲键盘吧，一片沉寂是最好的氛围）当然，我了解的并不是你大脑中的想法，而是它们在外部世界中得到体现后的样子。

    开发团队中还有一个重要的角色，测试。任何不能度量的事物都是不存在的。同样，不能使用自动化测试证实的软件也是不存在的。在测试前，我不相信任何自己编写的东西。测试提供了一个机会，使我可以不用考虑如何实现，只考虑我想要什么，然后测试会告诉我是否实现了我认为我实现的东西。有的测试出于责任感，有的是应别人要求，所以，如果想顺应人的天性并想要进行测试，我们必须为测试找到一个短期和自私的理由。幸运的是，我找到了。有了测试，编程工作会变得有趣的多，而且编码时你会更加自信。

     编程和测试相结合也比只编程快。做测试能节省调试的时间，你不需要花费一个小时来查找错误，你可以在几分钟之内找到它，这就是生产率提高的来源。

     开发过程中还离不开设计，设计就是创建组织系统中的逻辑的结构。好设计的组织逻辑是，对系统中某一部分的更改是不需要对其他部分进行修改的。好的设计可以确保系统中的每一部分逻辑有且只有一个“家”，糟糕的设计：一个概念性的修改需要对系统中的很多部分进行更改，如果不破坏现有的功能就无法添加新的功能。

     因此，要编码是因为如果不编码，就什么也没做，要测试是因为不测试，就不知道编码何时结束；要倾听，是因为如果不倾听，就不知道为什么编码和测试什么。要设计，是为了能够不断进行编码、测试和倾听。

     好的项目，前期需要做大量的设计，有效的沟通，制定良好的计划，才可以开始开发，测试结束收尾，发布项目。

     特别提醒一下：集体所有权
     如果有任何人发现改进任何部分代码的机会，他应该立即执行改进。 在过去，没有人拥有任何特定的代码，如果有人想更改某些代码，他们那么做肯定只是为了满足个人目的，无论是否符合当时的实际情况。结果是造成混乱。特别是对于那些很难静态的确定一行代码与另一行代码的关系的对象来说。代码增长的很快，但它也迅速变得不稳定。
    为了控制这种情况，引出了个人代码所有权。只有代码的正式所有者才可以更改代码。其他人发现代码需要改动时，需要向代码所有者提交申请。

     我是一名软件开发工程师，深刻理解在项目中开发人员的困扰，希望大家尊重我们的工作，需求不要一改再改，推翻自己写的代码比打脸还不是滋味。

     ------------------------------------------------------------

     文章中的XP理论参考《解析极限编程：拥抱变化》，推荐给大家.
     写这篇文章，主要是学习一下书中的项目管理理论，同时还可以祭奠下我们糟心的项目。
     如果你对软件开发的现状不满意，可以评估下XP是否适用你的项目，决定权就掌握在你们手上。