/**
* 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
分享到:
相关推荐
小议计量互感器故障分析与战略.doc
小议新形势下大额现金管理.doc
小议英语教学中小老师的作用.docx
小议中小城市零售业促销问题.doc
小议现行金融制度对农业的影响.doc
小议农村小学英语小班化教学方法.doc
小议羊首勺
小议外汇期权会计在新规则中应用.doc
小议经济型酒店消费者心理及消费方向.doc
2018年八年级语文下册小专题写作小议一位古代文学人物形象习题课件语文版
小议秦始皇焚书坑儒.doc
小议企业网络交易的税收问题-小规模企业税收问题.docx
私立幼儿园小议.pdf
小议初中政治趣味教学
小议怎么更好的培养小学生素质教育MicrosoftWord文档(2).doc
小议网页视觉设计.doc
小议嵌入式计算机技术.pdf
法治思想起源小议.docx
小议生命发展史.pptx