《解析极限编程——拥抱变化》读书笔记二

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

　　行动及其反馈之间的间隔是学习的关键，两者的区别在于为了胜利而比赛和为了不输而比赛之间。我所见到的大多数开发都是为了不输而比赛，写了大量文章，开了很多会，每个人都尽量按“规章”开发，不是因为它特别有道理，而是因为他们想在最后能够说这不是他们的过错，他们是遵照过程进行工作的。那么，回到基本问题，我们想从代码中学到什么呢？最重要的事情是学习。代码还给了我们进行简洁明了交流的机会。如果你有一种想法并把它解释给我听，我可能很容易发生误解。但是，如果我们一起对这想法进行编程，我能在你编写的逻辑中精确地读到你的想法。（so，不要说话，和我一起敲键盘吧，一片沉寂是最好的氛围）当然，我了解的并不是你大脑中的想法，而是它们在外部世界中得到体现后的样子。

　　开发团队中还有一个重要的角色，测试。任何不能度量的事物都是不存在的。同样，不能使用自动化测试证实的软件也是不存在的。在测试前，我不相信任何自己编写的东西。测试提供了一个机会，使我可以不用考虑如何实现，只考虑我想要什么，然后测试会告诉我是否实现了我认为我实现的东西。有的测试出于责任感，有的是应别人要求。

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

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

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