/**
* 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