| « | August 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | | |
|
公告 |
| 不得窥道门，不得悟佛门，不得入窄门，实乃破门。 |
| Blog信息 |
|
blog名称:破门点滴
日志总数:161
评论数量:404
留言数量:-2
访问次数:1419823
建立时间:2004年11月13日 |
| |
|  [XP 实践]摘录 XP － 消除业务／IT 团队的隔阂
随笔, 软件技术
破门 发表于 2006/11/17 11:40:54 | | 将企业需求转变成
它实际使用的软件是 IT
世界中最难的问题之一。让技术人员和业务人员进行持续且坦诚的交流是一个令人畏缩的挑战。尽管大多数公司在口头上夸夸其谈，但他们的行为表明他们实际不重
视交流。他们到处设置障碍。信息就无法流通。拉帮结派的斗争使他们偏离了需要完成的工作。人们对于其他组所做的工作一无所知。项目的启动遥遥无期，而为了
似乎永远也不可能达到的目标，这些项目艰难地前进着，而且它们会多次中途夭折。
从人们可以记起的那一刻起，情
况可能就是这样了。行为形成了习惯。业务人员已经习惯技术人员以种种方法向他们说“不”，所以他们开始新项目时，抛出每个可能的功能要求，并要求每件事都
要拥有高优先级，甚至是不需要的时候。技术人员以前也经历过这样的“游戏”。他们知道业务人员实际上并不需要所 |
|
| [XP 实践]测试驱动开发 by [Kent Beck]
文章收藏, 软件技术 破门 发表于 2005/11/17 10:32:17 | [Kent Beck] 2004-09-20
我希望在这里提出一些问题，供你们在将测试驱动开发(TDD) 集成到自己的开发实践过程中时思考。其中有一些是小问题，而有一些则是大问题。有的问题提供了答案，或者至少有相应的提示，而有些问题则是留经你自己去探讨的。
步伐应有多大？
这里暗指两个问题：
测试程序覆盖的方面有多大？
重构时中间步骤有多少？
你可以编写使每个都对应一行逻辑代码和少数重构的测试。你也可以编写每个都对应上百行逻辑代码和数小时重构的测试。你应当选择哪能一种方式呢？
回答这一问题的部分答案是不管哪能种方式，你都应该有能力做到。不过，经过一段时间，测试驱动开发人员都明显倾向于采用小步骤进行开发。然而有人正在单独利用应用级别的测试或者结合我们所编写的程序员级别的测试来驱动开发。
首先，当你重构时，你应当做好采用大量微小步骤的准备。手工重构很容易犯错，而犯的错误越多而且解决这些错误越靠后，你继续进行重构的可能性就越小。一旦你通过细致的步骤进行了20遍重构，那么就可以尝试着省去其中的一些步骤。
自动重构能够大大提高重构速度。曾经要手工花费20步才能完成的重构现在只要点击一个菜单就行了。当量变达到一定程序时通常 |
|
| [XP 实践]XP中的重要惯例和规则
网上资源, 软件技术 破门 发表于 2005/9/26 18:08:34 | XP中的重要惯例和规则
1 项目开发小组（Team）
在XP中，每个对项目做贡献的人都应该是项目开发小组中的一员。而且，这个小组中必须至少有一个人
对用户需求非常清晰，能够提出需求、决定各个需求的商业价值（优先级）、根据需求等的变化调整项
目计划等。这个人扮演的是“客户”这个角色，当然最好就是实际的最终用户，因为整个项目就是围绕
最终用户的需求而展开的。程序员是项目开发小组中必不可少的成员。小组中可以有测试员，他们帮助
客户制订验收测试；有分析员，帮助客户确定需求；通常还有个Coach（教练），负责跟踪开发进度、
解决开发中遇到的一些问题、推动项目进行；还可以又一个项目经理，负责调配资源、协助项目内外的
交流沟通等等。项目小组中有这么多角色，但并不是说，每个人做的工作是别人不能插手或干预的，XP
鼓励每个人尽可能地为项目多做贡献。平等相处，取长补短；这就是最好的XP开发小组。
2 计划项目（Planning Game）、验收测试、小规模发布 |
|
|
