6.4.1 极致是否会导致“偏离正道”？

[GreyZeng]

原文地址

所谓极限编程，就是把一些认为重要和有效的做法发挥到极致。（《构建之法》6.4.1）

我对于表格中部分发挥到极致的做法有些困惑。左栏中的做法看起来都是重要且有效的，但是到了极致似乎就有些“偏离正道”。

每时每刻都有客户在身边——首先这条件似乎比较难以实现，其次虽然客户需求在实时变化但如果事先不尽量细致了解客户总体要求就可能会需要连续重构，放在课程中可以锻炼我们的编程能力，放在工作中恐怕就不太合适了，会增加大量的时间和人力成本。
别做详细的设计，做频繁的增量开发、重构和频繁地发布——与上文类似，即使计划没有变化快，但这是否就意味着我们可以没有计划呢？频繁地发布所耗的资源与做详细的设计耗费的资源哪一个更多呢？

[GreyZeng]

本学期关于极限编程有两种实践方式：结对编程和团队开发。

在结对编程阶段我们体验了频繁修改需求的 “极限编程”，虽然编程体验不是太友好，但是也感受到了之后顾客需求变动的常态性。虽然没有从测试开始写程序，但是最后的测试也是基本覆盖了全部功能，也在测试中发现了不少问题，这也进一步体现了测试的重要性。关于代码复审我在之前的结对总结中也有类似的感悟，这里就不再赘述。
在团队开发阶段，由于我们对于测试的疏忽，并没有使用测试驱动开发的模式，导致最后测试没能发挥应有的作用，这也是我们在团队开发中得到的深刻教训，TDD模式的确可以帮助提高产品质量，并且需要从开发开始就严格落实。关于团队开发中提高用户体验是最重要的目标我也深有感触，在我们组的团队博客中可以看到对于比赛系统大家进行了深入的讨论和频繁的改动，即使开发进度很赶还是希望能带给用户最好的使用体验。
总之，通过这两种实践方式本人对于极限编程有了更加深入的认识和体会，相信这些经历和体验也会给我之后的学习和工作带来深远的影响。
原文地址