- 论坛徽章:
- 0
|
[讨论]大家来讨论一下开发流程问题
[这个贴子最后由cinc在 2002/10/10 09:06pm 编辑]
再仔细看了下书。发现自己对 XP 的理解有些偏差。特别是对它对体系结构和设计的处理。
也感谢 mygod, taurus, socketstrem 指出了我认识有错误的地方。
代码固然重要，但只是从程序员角度看问题，如何使开发出的系统真正满足用户的需求，
才是最重要的。
从《Extreme Programming Explained : Embrace Change》中摘录了以下一段，来一起
看看 XP 是怎么处理变化着的需求，从中得出良好的设计的：
关于系统结构，XP中，体系结构和其他软件项目中一样重要。体系结构一部分使通过系
统隐喻来概括的。如果使用好的隐喻，团队中的每个人都能说出系统作为一个整体使如
何工作的。
关于故事怎么变为对象。“计划游戏”的规则规定，第一次迭代必须产生一个系统的整
体功能框架。对于第一次迭代，选择一套简单的，基本的，你认为能够创建整个体系结
构的故事。接下来，缩小范围，用可能有效的最简单的方法实现故事。这个过程结束时，
你就拥有了一个体系结构。可能它并拾你所期望的，但你会从中了解到一些东西。
如果找不到一套可以使你创建体系结构的故事，而且你很清楚将非常需要这个体系结构，
该怎么办？可以根据推测设计出整个体系结构，或者设计出能满足现在需求的那部分体
系结构，而相信将来能添加体系结构的更多部分。我提出现在需要的体系结构，并相信
自己有能力在以后对他进行修改。
XP的工作方式与许多程序员的本能相背离。程序员习惯预见问题。当问题晚些出现时，
我们会很高兴；如果这些问题部出现，我们就注意不到了。所以设计策略必须绕开这种
“推测未来”的行为。幸运的时，大多数人可以去掉这些“自找麻烦”的习惯。不幸的
是，越是聪明的人越难去掉这个习惯。
了解这个问题的另一种方法是提出这样的问题：“什么时候添加更多的设计？”，通常
的答案是应该为明天设计，如果再当前和将来这段时间内不会有任何变化发生，这种策
略是正确的。如果你完全了解将来要发生什么样的问题，并且知道怎样去解决它，一般
来讲，最好是把现在和将来需要的都添加进去。
此策略的问题是不确定性。特别是：
1.有时明天永远不会来临（也就是说，客户把你提前设计的功能取消了）。
2.有时你会在“明天”来临前学到更好的工作方法。
在每种情况下，都必须做出选择：要么支付用于出去额外设计的费用，要么负担使用一
个更复杂而不会带来效益的设计的成本。
我绝对打赌不会发生变化，当然，我也不会打赌我学不到东西。这样，我们就需要改变：
今天为今天的问题进行设计，明天为明天的问题进行设计。
这样就产生了以下的设计策略：
1.从一个测试开始，这样就知道何时完成。我们必须专门为编写测试来做一些设计：
对象和它的课件方法是什么。
2.设计并实现，只要能使该测试运行即可。钥匙这个测试和所有以前的测试都能运行，
你将不得不设计足够的实现。
3.重复。
4.如果有机会可以使设计更简单，就抓住机会去做。
关于什么使最简单的设计，有四种约束：
1)系统（代码和测试一起）必须能够沟通你希望沟通的内容。
2)系统不能包含重复代码。（1，2一起构成了“一次且只有一次”的规则）
3)系统拥有尽可能少的类
4)系统拥有尽可能少的方法
这个策略可能看起来简单得可笑。它确实简单，但并不可笑。它嗯那个创建大型得复杂系
统，当然这并不容易。在紧张得工作期内工作而且还要抽出时间来进行清理，没有比这更
难的事情了。
以这种方式进行设计，在第一次遇到问题时，你将以一种非常简单得方法实现它。第二次
使用这种方式时，它会变得更通用。第一次是为了付学费。第二次使用则是为了得到灵活
性。这样永远不用为你用不着得灵活性付出什么，而对于第三次，第四次，第五次得变化，
则可以根据需要可以使系统得相应部分更灵活。
：） |
|
免费注册
楼主: mygod
发表于 2002-10-09 10:32
