|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-10-29
XP 关于设计的看法历来有很多的讨论， 也引起相当大的争论。 在本质上， XP 对设计的看法与传统的软件开发有很大的差别。 下面谈一下我的理解。 欢迎大家讨论。
可以对软件开发和软件设计做一个比喻。 软件开发是从当前一无所有的状态出发， 向一个目的（解决客户问题）前进。 而软件设计是尽量寻找一条最直接的， 最短的路径 比喻： 把开发看作一个过程： 无（出发点） —》 目的地 设计是寻找尽量短的路径。 我们知道， 从一个地方到另一个地方， 总是有大量的岔路和分支。 那么开发过程就会可能不断走到错误的分支上， 偏离了目标。 开发过程不可能是直奔目的， 而是会形成很多岔道和分支。 那么我们可以将一个开发过程 的主线和岔路看作一棵树。 比喻： 开发过程 是 树。 设计： 尽量沿着主干走， 少走弯路。 对于这棵树的认识， 是 XP 与传统开发方法的分歧所在。 传统开发方法倾向于： 如果走到错误分支上， 得掉头往回走， 回到分岔处， 从新前进。 错误的代价很大， 要推倒从来。 相当于是回溯法。 XP方法倾向于： 如果走到错误分支上， 没关系，河水终究会汇集到大海， 而不是回到起点重新来过。 无非是一条路流的长一点， 一条短点。 通过 refactor, 河水就汇集了。 用kent beck 的话来说， 他对软件修改的成本的认识与传统认识不同。 传统方法认为修改代价是指数上升的， 他认为是平缓的。 也就是说，他认为 软件本身是柔性的， 易于修改的，尤其是在采用OO 方法之后。 到这里， 我们要改变上面所说的比喻， 软件开发过程不是树的生长， 更象水的流动， 百川终究归海。 水在老子的书中是反复提到。 所以可以说, kent beck 对软件开发的认识很有道家精神。 传统方法导致的结果是： 担心走错路，走错了要掉头， 所以迟迟不能开工， 预先的准备多。 XP： 走错没关系，不需掉头， 只需调整一下 就回到主路上。 所以 XP 强调勇气， 不要怕。 可以用两句老话来总结 kent beck 和其他人的差别： kent beck: 条条大路通罗马。 传统思想：多歧路，今安在。 就我个人来说， 我对于没有设计， 或不充分的设计， 我还是感到害怕。 勇气不足。 在martin fowler 的 design is dead 一文中， martin fowler 也表露勇气不足。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2004-10-30
看到邓辉（hoping) 翻译的一篇文章。
看来 软件开发既不是 “条条道路通罗马” 的乐观主义， 也不是“多歧路，今安在” 的悲观主义， 而是 权衡的艺术。 http://blog.csdn.net/hoping/archive/2004/05/24/16903.aspx 大家什么意见，来点反馈。 看贴不回贴， 良心大大坏了。 :-) |
| 返回顶楼 | |
|
发表时间：2004-10-30
hoping 翻译的文章。
引用 权衡的艺术
Hoping翻译 来自：www.pragmaticprogrammer.com 你是怎样开发软件的？ 在那些以编写软件为生的人们之间有一个常见的争执。有些人坚持认为在编写代码前必须先要有一个完整的模型，那些过早进行编码的人只不过是一些“在地狱中编码”的hacker。 然后，就会有另外一群人说，嗨！等一下。你无法从一个简单的预先模型中学到足够的知识。你必须得编写某些形式的代码。否则，你很可能会遗漏掉一些重要细节，甚至创建出一个无法构建的模型。 正确答案 那么哪一方正确呢？是整天侵淫在代码之中的那一方呢？还是坚持在思考代码前必须先完整地建立对世界感知的模型那一方呢？ 嗯，他们在某种程度上都是正确的。至少，他们在试图解决同样的问题－－获取正确实现一个系统的足够知识。 请注意，软件项目和其他工程学科中的项目不同。软件项目在本质上是以发现为中心的项目。随着时间的过去，你和你的团队会学到更多的知识。你对客户、应用、环境以及发起者的认识也会随着项目的进展而增加。 你必须得做好适应新发现的知识的准备。典型的瀑布方法的错误就在于根本没有任何反馈。在瀑布模型中，低层编码中的任何发现根本无法影响到需求和架构。然而，这些低层细节对于理解更高层的东西来说常常具有深远的影响。 降低风险 降低风险是传统工程的核心。当建造一座桥梁时，你不会考虑把它建造成一座永远不会倒塌的完美桥梁。相反，你只会考虑它能经受500年的风吹、200年的水淹、最大3倍于所期望的承重，等等。如果不做这些设计权衡，那么所有的桥梁都将是从桥面到地面的实心混凝土，都将有500英尺宽。工程的全部就是做这些折中，软件工程也是如此。 软件工程的困难在于：大部分的风险都存在于构建它的过程以及所完成的结构之中。原因就是其发现的本质。 知道了要在前进中不断地进行发现，那么问题的核心就在于要使所发现的东西使你已完成工作失效的风险最小化。 那些直接去拼凑产品代码的人在开始之前就已经陷入麻烦之中：（由增加的知识所导致的）方向上大的变化此时更改起来最为困难，也最为昂贵。 那些建议在做任何实现之前要先建立完整模型的人，同样也冒着在创建产品代码期间会出现重要发现的风险。作为现实抽象版本的模型，必然会失去一些细节。而恶魔很可能就潜伏在这些细节之中。 于是，就有一些人试图在这两个极端之间进行平衡，他们建立一点模型，就进行一些编码，他们使用一次性的原型或者代码曳光弹进行建模。Usenet中许多关于这个主题的讨论都集中在是宽度优先还是深度优先；何时建模以及何时编码等细节之上。针对这个问题，不同的方法会给出不同的建议。 方法就是我们自己 极限编程是基于降低风险的前提之上，当今所有其他流行设计方法在某种程度上亦是如此――不管它们是否承认这一点。 已公开的方法都在试图回答下面问题：“为了创建一个软件系统，我和我的团队如何才能以最为经济的方法获取最多的问题领域和解决方案领域知识。” 很明显，风险固有地存在于项目的发现过程之中。然而，该发现是一直在进行的，我们无法承受游戏后期的重大发现。在理想情况下，我们希望能够预先发现我们希望知道的一切，并且完全理解它们。现实肯定不会是这样的，所以每个方法都试图创建出一个环境，在其中你能够尽可能早地做出最重要的发现。一个特定方法最有价值之处就在于它是如何降低在晚期出现的关键发现的风险的。 不过，这些答案对每个人来说都是不同的。答案和你的团队、项目、经验、问题领域、工作环境等相关。如果你曾经发现一个方法很适合于一个项目，谁也无法保证它会适合于下一个项目。如果所列出的这些因素中的任何一个发生变化，很可能就要对过程进行修订。 它并不完美 你已经看到，和算法或者坚固的机器指令序列的质朴之美不同，它并不完美。过程和方法依赖于人去维持它们，去理解将被检查的要素。而人是很容易犯错误的。 所以在最后，我们再回到对管理权衡的想法。你可以在一个项目的对象模型上浪费6个月的时间，结果在实现期间却发现你错误的理解了客户的性能需求。你可以很早就开始实现，把自己锁定在一个无法支持一些你还不知道的重要需求的设计和架构上。 或者，你可以对权衡进行评估以最小化总的风险，接着分析一点、设计一点、编码一点。每个任务所占的相对比例、顺序、反馈的数量――所有这些对每个项目、每个实践者都是不同的。不存在在任何时间、任何场合都正确的答案。所以，一定要注重实效，作出最适合当前问题、当前团队、当前环境的选择。 所以，当你下次进行计算机是工程实践还是艺术的讨论时，请考虑一下权衡的艺术。其他的工程学科必须要建立在和物理世界有关的权衡之上；我们必须要面对和我们自己相关的权衡。 然后我们就可以开始开发软件了。 |
| 返回顶楼 | |
|
发表时间：2004-10-30
我现在还是把 XP 当作武林中一种高深的武功，掌握好这门武功就需要有足够高的内力（就象我以前说的虚竹可以练习逍遥派的上乘武功，因为他有 100 年的内力，而他手下的女弟子如果贸然练习就会走火入魔）。方法论有些象英语的语法，我们中国人学英语都是首先学习语法的，但是美国人不是这样，在他们进入学校学习语法的时候已经会讲英语了。我的意思是说，并不是有了一种尽善尽美的方法论（甚至是象 CMM 那样无所不包的大方法论），我们才可以做好事情。以前和一个朋友聊天时他说他们采用的开发方法其实是野球拳，但是他们自己用着感觉很舒服。同样的，我们采用的开发方法也是野球拳，我们总结出了一些适用于自己的开发套路（例如：做设计前先画界面图，后来我看了《面向使用的软件设计》发现其实就是可视化设计）。XP 在文档化之前其实也是野球拳，甚至直到今天仍然被某些正统人士认为是野球拳。实际上我认为很多时候文档化的方法论都是拿给别人看的，既然要拿给别人看，自然要加以包装，显得辉煌一些，而且最好是无所不包（上知天文下知地理，用来解决巴以冲突肯定也没有什么问题）。但是实际上真正的开发过程是很难如此光鲜的，越是无所不包的方法论越是没有用处的。XP 恰恰相反，并没有试图成为一个无所不包的大方法论，因此很容易找到 XP 的漏洞（例如：XP 不能有效地指导神舟 6 号软件的开发工作），尽管如此我仍然认为 XP 其实才是对于我们真正有用的方法论。我们一定要确立一个共识，即软件开发的最终目的是为了给用户提供满意的产品，而不是为了严格遵循某种开发方法。重要的是你今天有没有为你的用户（当然你的用户也有可能是其他程序员，当你在为他们写一些重用组件的时候）解决他们真正关心的问题，为他们提供新的价值（如果今天还不做些对于用户真正有价值的事情你就会很危险了）。如果没有这样的共识，那么就没有什么讨论的必要了。
现在国内的很多人对 XP 有非议主要的原因在我看来还是因为他们的内力不够，国内软件开发各个层次的人才都很缺，而实际上最缺的还是好的程序员。我在国外工作时见到的一些资深开发人员做开发做了 10 年以上仍然在孜孜不倦地写代码（当然由于其经验他还会做很多其它方面的工作，但是他不会抛弃编程这个基础），但是在国内拼命想跳出编程苦海的人何其多啊。UML 是他们达到这个目的（即：走向仕途）的捷径，但是我和这里的一些朋友一致认为 UML 最大的价值其实还是在于沟通，UML 仅仅在设计/建模阶段是有价值的，UML 不能代替编程，不能把 UML 的作用无限夸大。这样的人（不喜欢编程的人）遇到了 XP 这种以程序员为中心（或者是回归到软件开发的本原，以源代码为中心，不写代码你吃什么？）的开发方法肯定是无法适应的。TDD 这种开发方式对于这些习惯于舒舒服服地使用昂贵的建模工具（例如：ROSE）画出漂亮图形的人来说实在是过于 tough 了。但是根据我在国外工作的经验，我要说，这些人全部都错了。做好软件开发的出路根本就不是培养大量的“软件蓝领”（以至于很多人认为编程是非常低级的工作，30 岁以后就不应该做编程工作。提出这个概念的人的脑子是不是象 Readonly 说的那样被压路机压过了？）。在国外一个好的程序员在任何地方都受到欢迎，而且在公司内部非常受人尊敬，难道国外这些开公司的老板都是傻子？ 现在所有这些已经文档化（我的意思是说，从外表上看足够光鲜）的开发方法中，最符合我的实际开发经验的就是 XP。而方法论这些东西不象具体的技术，其实完全没有必要尽信书的（我看过的方法论方面的书要说也不少了）。我鄙视那些在方法论上捣浆糊的家伙（例如动辄就宣布：我找到了银弹！），显然我也不愿意成为这样的人，所以我现在也很少谈论这方面的问题。 说了这么多废话，说点正题。楼主 对 Martin Fowler 的观点完全理解错误。Martin Fowler 从来没有说过不需要设计，而是说很多时候不需要那种瀑布式的预先设计。请再仔细阅读《设计已死》，除了这个煽动性的标题以外找出任何一句不需要设计的话来。 |
| 返回顶楼 | |
|
发表时间：2004-10-30
对，应该是"设计已死?"(is Design Dead?)而不是设计已死
|
| 返回顶楼 | |
|
发表时间：2004-10-30
昨天在这刚写了两句，突然机器重启，郁闷S！今天回来再写！
早上刚刚看到Bob大叔的话，觉得用在这里再合适不过 引用 过渡依赖工具和过程以及低估智力和经验都是灾难的源泉
XP只不过是视图通过快速迭代、简单设计替代瀑布式的前期设计，从来不会说可以随便的设计。重构的目的不是单纯为了把坏的设计变成好的设计，而是为了需求变化导致的设计变化做好准备。 无论是XP还是RUP还是瀑布式，高水平的设计永远是积极的因素。设计水平差强人意的话，用什么过程、什么工具都白搭。 另一方面，在同等技术水平的前提下，相对于重型过程，使用敏捷过程无疑会降低风险，这一点是大家都承认的。 不知道Potian实际带领XP团队后会不会有这样的效果，我只是推测：习惯于重构的程序员可以更快的领悟OO的本质、原则，因为在频繁交换两顶帽子的过程中，程序员在不停的使用OO的方式进行思考，而不是像所谓的软件蓝领那样，别人怎么设计，他就怎么实现，几乎不用动脑子。这样的话，就不可以简单的说，XP只有高手才可以玩。因为在XP的过程中，菜鸟可以更快的成为高手。 |
| 返回顶楼 | |
|
发表时间：2004-10-30
to muziq：
是的，XP 并没有象 RUP 那样严格地划分设计人员和编程人员的界限，实际上在 XP 中编程人员也是设计人员，设计人员也是编程人员。我想了两年多也没有想清楚严格地划分设计人员和编程人员的界限究竟有什么重大的意义，最后的结论是这样做增加了沟通的成本，对于保证软件的概念完整性反而是弊大于利的。 软件的质量不是靠测试测出来的，良好的设计才是保证软件质量的根本。这种良好的设计可以由多种途径来达到。我不否认有能够完全通过瀑布式的预先设计得到完美设计的天才（达到这种境界需要靠以前大量的成功和失败的经验，缺乏经验的人是无法胜任这种工作的），但是很多时候对于我们这些普通人来说，把重构作为自己日常开发的习惯，通过坚持不懈的重构来获得一个良好的设计是更可行的途径。 我上面说的内力不够略微有一些偏颇，我也认为 XP 其实对于初学者也是可以适用的。但是象任何方法论一样，XP 的成功实施最重要的还是让大家都能够充分地理解 XP 的内涵，自觉地按照 XP 的要求来做开发。前期需要做的一些培训工作是非常必要的（因此我认为围绕 XP 开展的咨询是会有市场的），不能想当然地认为程序员会自动理解 XP 的理念。如果 XP 仅仅装在几个管理人员的头脑里面，其他开发人员只能被动地接受命令和执行命令，那么就是精英治国了，可以肯定无法取得成功。XP 最强调的是沟通，这样的做法显然违背了 XP 的原则。 XP 团队中最重要的是 XP 教练这样一个角色。这个人必须由资深的开发人员担任。他不必做什么具体的开发工作，但是他一定要做好监督和控制。对于程序员所做的设计做出判断，有问题就及时提出，只有这样才能有效地帮助程序员做好设计，迅速提高自己的能力。如果没有有足够能力担任这一角色的人就不要贸然采用 XP，还是应该多做一些前期设计的。完全没有控制等于是放任自流，这样是不可能取得什么好结果的。程序员会丧失方向感，浪费大量的时间去解决一些细枝末节的问题。或者只能完全依靠试错法来学习，走了太多的弯路，而我们知道试错法其实是一种很低效的学习方式。所以我的看法是 XP 和其它方法论一样，成功的关键在于有效的控制。因为 XP 更注重来自实际开发过程中的反馈（拥抱变化！），所以 XP 成功的可能性比起其它方法论要更大一些。 |
| 返回顶楼 | |
|
发表时间：2004-10-30
教练这个词用的好！在开发过程中，真正需要的是程序员的创造力，而不是机械式的模仿，随时都在思考的程序员才是好的程序员。而教练的作用正是激发人的创造力，同时也需要传授工作、学习的方法。
|
| 返回顶楼 | |
|
发表时间：2004-10-30
dlee 写道 我现在还是把 XP 当作武林中一种高深的武功，掌握好这门武功就需要有足够高的内力（就象我以前说的虚竹可以练习逍遥派的上乘武功，因为他有 100 年的内力，而他手下的女弟子如果贸然练习就会走火入魔）。
这点我比较同意。 至于说讨论方法论， 这里是软工版， 我理解应该就是用来讨论方法论的。 引用 说了这么多废话，说点正题。楼主 对 Martin Fowler 的观点完全理解错误。Martin Fowler 从来没有说过不需要设计，而是说很多时候不需要那种瀑布式的预先设计。请再仔细阅读《设计已死》，除了这个煽动性的标题以外找出任何一句不需要设计的话来 我理解martin 的意思是设计与重构的一种平衡。 同时， martin 觉得自己没有kent beck 激进， 还是会做预先设计， 只是做得少一些。 而kent 等更加激进， 尽可能的避免做预先设计。 下面是摘自 设计已死？ 一文。 引用 无疑地，最积极的 XP 专家－像 Kent Beck, Ron Jeffries, 及 Bob Martin－尽其所能地避免预先结构性的设计。在你知道真的要用到数据库之前，不要加入数据库，先用档案来代替，在之后的阶段再用重构加入数据库。
我常被认为是一个胆小的 XP 专家，这点我不同意。我认为一个概括性的初始架构有它的用处在。像是一开始要怎么将应用分层，如何与数据库互动 (如果你需要的话)，要使用哪种方式去处理网站服务器。 |
| 返回顶楼 | |
|
发表时间：2004-10-30
muziq 写道 昨天在这刚写了两句，突然机器重启，郁闷S！今天回来再写！
早上刚刚看到Bob大叔的话，觉得用在这里再合适不过 引用 过渡依赖工具和过程以及低估智力和经验都是灾难的源泉
XP只不过是视图通过快速迭代、简单设计替代瀑布式的前期设计，从来不会说可以随便的设计。重构的目的不是单纯为了把坏的设计变成好的设计，而是为了需求变化导致的设计变化做好准备。 重构一方面是应对需求的变化， 另一方面，也是应对简单设计没有考虑到在编码后发现的一些问题。 |
| 返回顶楼 | |
