| « | 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
访问次数:1420887
建立时间:2004年11月13日 |
| |
|  [XP 实践]谈XP四大宗旨－反馈篇
原创空间, 软件技术
破门 发表于 2005/9/24 17:15:39 | | 反馈
反馈宗旨看上去和交流宗旨似乎有些重复的嫌疑，因为我们常常把反馈看作交流的一种对应动作，比如领导交办的事项必须进行反馈等。而事实上在XP实践过程中，反馈更强调的是对交流得到的信息进行分析后的一种积极响应动作。
首先是XP对需求变化反馈的看法：积极地拥抱变化，积极地反馈是XP应用需求的策略。XP团队不会像传统团队那样执着地幻想需求能够在进入全面设计之前就明明白白地确定下来，而是认为需求变化是一种自然，是任何项目都需要面对的问题。唯一正确的解决办法就是通过积极地反馈来适应变化。
其次是XP对设计变化反馈的看法：积极地重构设计，“毫不留情”地重构是XP对设计的要求。因为XP为了快速适应需求和降低前置设计成本而提倡简单设计，所以系统架构和代码设计的质量就需要通过时时刻刻不断地重构来提升。只要发现系统有任何不满足需求或是设计代码问题，XP团队就会马上动手对系统进行足够程度上的重构，毫不留情地重写需要重写的任何部分，甚至是全部系统！
在这个问题上，绝大多数的传统团队都会认为重写全部系统是“疯狂”或者不可能的事情。事实上，如果不能痛下决心，系统后期的问题会更加致命！在我曾经进行过的XP实践项目中，也曾经遇到过需要重写整个系统的情况，在一个大型的项目中我没有能够下决心重构系统，结果就是不断地要为系统打补丁，而系统也因为设计问题一直无法达到稳定性的要求。而在另外一个开源项目中，我吸取教训，毫不犹豫地进行了整个系统重构，结果发现，重写那个花了一年多构建的系统，竟然仅仅用了两周时间就基本完成了！
接下来是XP对系统变化反馈的看法：通过不断迭代反馈，持续地集成，保持系统始终处于可运行状态。对系统的任何修改应该尽快地进行构建出一个新地发行版本，通过不断地迭代逐步完善系统。这个在谈简单宗旨的时候已经讨论过了，不过从反馈宗旨的角度来讲，持续集成依然是关键的实践规则。只有尽快地构建可运行系统，才能更好的从最终客户那里获得最真实和最准确的需求反馈。 |
|
|
