读书小感，小议XP

/**

 * first post on 2006年03月05日

 */

最近看专业书（俺学物理的），略有小感。

有一章比较长，而且很难。我的方法是一节一节地看，每一节都努力去慢慢消化，俺称之为“XP式学习”。结果，第一节看了好几遍，似乎明白了，就去看第二节，看第二节时，觉得第一节又有新的问题，于是又去看第一节，好不容易看第二节看“明白”了，再去看第三节，又出现前面小节有新问题的现象…两个礼拜过去了，都没怎么学懂。

于是后面的章节我换了种方式：先把这一章内容大致看懂一遍，也就是说具体推导先不看，首先把它讲的什么，有什么用总体的了解一下，分析出里面的关键点和重点，并稍作意识地规划出学习例程和进度，再XP式学习。实践证明，我的学习效率大有提升。

<o:p> </o:p>

想起前阵子写代码，我总是草草规划就开始动手（项目还不是很小），结果老是持续重构，加入新功能时，前面好不容易重构好的代码又面临新一轮的重构甚至抛弃。最后虽然完成了，但十几个版本中，竟有好几套完全不同的代码，即几套不同的设计方案。

于我想对于小型的项目，较容易看出其架构和设计方案（甚至在写代码过程中也容易看出），于是XP工作得很好。但对于较大或复杂一点的项目，有必要先扔个曳光弹（即先完成个非常小型的版本），再对其作定量的分析和研究，并进行项目分解（这可能需要迭代好几次，时间也可能较长），然后再进行XP。这时XP与项目规划是相互补充的。虽然XP也声明要规划，但其给人感觉是规划和项目分解的重要性大大降低了。而我认为应根据项目的复杂性作灵活的搭配。

<o:p> </o:p>

其实XP中有很多东东也不总是好用，如：

集体所有权：可能导致平庸的改动，而且责任不明显。

教练：有几个这样勤奋和优秀的教练呢？

客户：不仅很累，做的都是程序员不愿做的事，而且很大程度就是项目失败的替罪羊。

结对编程：有时安静还是比较好一点，而且有些人不喜欢。

等等。<o:p></o:p>

<o:p> </o:p>

个人认为XP应该重构的几个方面：

1         做计划时按项目复杂性作一定量的设计（分成子项目），最好不要一开始就编码。

2         迭代周期不一定要每次都短，解决问题才是最重要的。

3         当你持续重构时，应该怀疑一下你的设计了。

4         避免过早的将项目推入维护模式，起码要等项目基本成型，这可能是XP一大软肋。

5         不要强求结对编程和大家同处一室。

6         教练、客户不是一定需要的，要的话，责任也不一定要分得太明确。

7         集体所有权也不是一定的，可以通过团队的设计、评论来补充。

8         程序员有各自的测试是好事，但当项目较大时，仍然应有独立的QA团队。

9         TDD和预先设计是相互补充的。（再强调一次）

<o:p> </o:p>

很多想法纯属个人见解，还望多PP　^_^v