|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-11-12
比如我说你要写一个电影剧本，电影剧本需要的结构和基本的元素等等内容就不要我来给你介绍了，因为电影剧本就代表了一种Architecture。而RUP的概念过于细节化，根本就没有一种指引的作用。他只是告诉你要写一个东西，具体写什么，怎么写他并没有任何的提示。只是说你先写个简单的，然后我们再考虑怎么具体的写。这样的做法显然是一种非常荒谬的做法。
方法和方法模板的区别在很简单啊。就是衣服的图纸，和实际的衣服的区别。图纸没有办法穿，只有你裁减并且缝纫之后你裁可以。 |
| 返回顶楼 | |
|
发表时间：2004-11-12
RUP里面的东西太具体到需要一个特定的工具在支持起管理和过程的实施,也许这才是RUP推出来的本意.就好象想卖剑,得有剑谱搭配才行.而实际重要的却应该是其中的软件工程思想:迭代的，基于用例和软件架构的集成开发。注意别买椟还珠那。
|
| 返回顶楼 | |
|
发表时间：2004-11-12
RUP就是提供了一堆形式化的建模方法和文档模板，而“高层”构架描述对于不同的项目、不同的技术来讲千差万别，很难找到形式化的东西去概括它，或者说很难模板化，我想这大概也是XP管它叫隐喻的原因。
架构本身就是个很难描述的东西，RUP的架构文档模板的描述能力也确实也是很有限的。RUP强调原型的作用多过于架构文档，大概也是处于这方面的考虑。XP也没有提供隐喻的更多的参照方法，只是说可以通过一个典型的Story来表达隐喻(Kent Beck, XP Explained)，其实隐喻仍然存在于XPer的脑子里，而并没有真正的被表达出来。 |
| 返回顶楼 | |
|
发表时间：2004-11-12
ozzzzzz 写道 RUP绝对不是面对初学者的。即使是熟练的老手，对于RUP的掌握我看也不会很充分。实际上Rational自己说RUP需要在实施的时候针对具体的情况进行裁减，而这个裁减的方法我看只有Rational自己才能掌握。当然许多的人在RUP的基础上进行了某种改进，而不是完全在RUP的范围内进行的裁减，这样的难度要小得多，比如EUP和XUP。
我的观点还是如此，RUP更加适合那些希望建造自己方法过程的人。他们可以将自己的方法按照RUP的方式进行铺开，然后寻找RUP中核心工作流与其方法的为覆盖的部分，加以弥补。这样就可以得到一个自己的比较完整的方法系统。而对于初学者来说，他们很难有能力建立起自己的方法，而且基本上也不会有这样的愿望。而对于高级用户来说，很可能他们会面对非常多的不同的组织（比如他是一个顾问，或者在自己的组织中要不断地继续SPI），他们可以参照RUP做出针对性的过程。 o6z兄的这番话一语中的, 在我所经历的公司,没有是完全照搬RUP的,都是根据RUP进行裁减.我觉得最搞笑的就是编写敏捷建模这本书的人,把过程改进小组,缩写为PIG(Process Improvement Group),哈哈双关含义明显. |
| 返回顶楼 | |
|
发表时间：2004-11-12
yangzheng 写道 如果我们项目的时间跨度比较长，中间可能会有其他项目的开发（其他项目也会打上自己的分支），一般都会打上分支,命令如下：
cvs tag -b 合并我们有专门的测试工程师进行，合并脚本也算比较简单吧,主要就是下面的命令 cvs up -j 楼上把合并也理解得太简单些了吧(莫非以为都是代码才需要合并?), 我不清楚CVS到底有多强大, 但是,我可以说,就是Clearcase这样的SCMTool面对非文本性的merge都是无法做到,需要依靠人工的. |
| 返回顶楼 | |
|
发表时间：2004-11-13
dlee 写道 凤舞凰扬 写道 最后，就是代码＝设计这种理念了，至今我对它仍持有一丝怀疑的态度（不过也许正如dlee所讲，我的功力还不够，也没有完全领略XP的充分优势吧）
代码 = 设计 这个等式要成立是有条件的，不是说知道了这个等式就可以想都不想直接从事编程工作，也不是说任何代码（哪怕是写的乱七八糟惨不忍睹的代码）都等于设计。要做到代码 = 设计需要付出艰辛的努力。一般来说，我认为风格良好（要有一个编程规范）、进行过多次重构，消除了大部分臭味的代码才等于设计。 水平越是低的编程人员，经验丰富的设计人员越应该为他们多做一些预先设计。不过也不应该认为编程人员在编程过程中就完全不应该做与设计有关的工作。再伟大的设计师，在设计阶段也不可能想清楚所有的细节问题，这些问题在编程过程中存在着一个再设计的过程，而且这些设计由具体做这方面开发的编程人员来做是最恰当的（他们也可以在这些细小的设计工作中提高自己的能力，以后可以胜任一些更大的设计工作）。主要的设计人员以前必须从事过大量具体的编程工作，对于自己的设计的合理性和可行性完全有把握，确信自己有把握在编程人员遇到棘手问题的时候能够迅速帮助他们脱离难关，否则就很难控制项目的进度（不好意思，我这里把设计人员和 PM 的职责搞混了，因为在我们这里其实这两个角色都是由我来担任的）。设计人员和编程人员也不应该有一个完全明显的界限，设计人员也要参与编程，编程人员也要参与设计，唯一不同的是承担不同性质的工作的比例不同。一些重要的可以重用的代码应该由主要的设计人员来编写，而外围的相对简单的代码由级别较低的程序员来承担。这样的团队组织形式其实就是我一再提到的《人月神话》中说的那种外科手术式的团队。 其实现在大家都完全同意瀑布式的开发过程是一种错误的而且代价昂贵的开发过程，迭代开发的思想已经深入人心。是否需要做预先设计、做多少预先设计都不是非常大的问题，也不是原则问题。XP 的思想其实很朴素，就是把现在已经可以做的工作（根据以往的经验，如何做已经非常清楚了）尽快地做起来，转化为用户能够见的到的功能，让用户能够充分和及时地参与进来（你什么都不做出来，他们能提一些什么意见呢？）。用户及时而充分的参与是降低项目风险、保证项目成功的关键。能够做到这一点，并且确实能够迅速应对用户提出的需求变化，就是一个成熟的软件组织了。机械地照搬 CMM、RUP、XP 其实都是有问题的。一蓑烟雨任平生曾经对我说，他发现其实还是应该由过程来适应人，而不是人来被动地适应过程。这个观点是我们在实践各种开发过程时一定要牢记的，任何开发过程都应该根据你所在的团队成员的能力适当加以变化。以前 o6z 说实施过程改进前应该已经有了一个自己的行之有效的开发过程（就是我所说的野球拳），然后再参考某种标准的开发过程加以改进。如果自己连一个基本的做事方法都没有，对于什么适合自己、自己真正需要什么样的开发过程完全没有概念，那么 CMM、RUP、XP 都不可能成为你们的救 命稻草。我们最终的目的还是获得一种能够快速应对变化同时还能保证产品质量的能力（迅速交付让用户满意的产品的能力），而不是中规中矩地实施某种软件开发过程。XP 和各种敏捷方法其实是把这种主动性交到了我们自己手里，如果我们还是只能机械地照搬，就仍然不能达到理想的效果。最后只能怨天尤人，认为自己完全没有能力解决好这些问题，于是只能把张半仙李半仙之流的算命先生找来，给自己增加一点点的心理安慰。 dlee的这番话,印证了我心里的一个想法,那就是XP只是一个方法论, 而一个方法论的诞生总是有其所适应的环境和针对的对象的. 我总是戴着审慎或者有些批判的眼光看待新的事务,包括XP,至少,我认为在我的周围,或者我所见的周围, 结对编程, 非预留check out/in , 代码=设计,可行性并不是太高.(当然只是个人看法, 各人的情况也自有不同的) |
| 返回顶楼 | |
|
发表时间：2004-11-13
实际上结对编成很常见,至少在重型和敏捷的方法中都会存在。这个也是实践争议最大的不是可行性，而是其效率会有那么高，造成很多人的不理解。但是如果你在开始的时候说这个只是为了提高代码的质量，加强的代码评审的的一个强制手段，很多人还会接受。
而非预留check out/in实际上实施起来受到局限的唯一的一个环节并不是管理，而是你的硬件性能是不是够强劲。 代码=设计则是任何组织都应该遵守的一条铁的原则，其真实的意义在于任何的文档和非代码的手段，都不能真实地反映设计，也不能验证设计，更加不能无失真的体现设计。如果不严守这个底线，那些这个组织的开发过程注定就是一种混乱与糟糕的。这并不是危言耸听，而是对待设计的态度究竟是一种究竟把其看作只是一种头脑中的构想，还是一种现实中的设想。如果不能把持住这一点，那么任何的测试和修正bug都会显得无聊而可笑。这也是很多重型的方法在大型的开发应用中不断产生莫名其妙错误的一个思想根本。我们再也不要犯把英尺和厘米混淆的荒唐事故了。真实地看待设计的思想性和现实性，才会理解代码=设计的深刻内涵。当然代码=设计，并不是要排除设计的构想和准备，而是说必须对这些构想和准备进行实际的落实，并且用代码来体现，以使得其合理性和操作得当真正的认定。 对于非预留的checkin/out，实践中之所以可以成功，原因在于其实际上是在实时不断构建，而不是仅仅增量编译。这就是很多人认为MSF是每天一个迭代，而xp是每天多次的迭代的原因。这样的后果就是可以进行完全的编译，很多中间的产品就没有必要进行太多的管理。 |
| 返回顶楼 | |
|
发表时间：2004-11-13
大家都谈的都很专业，也很深入，其实即使老外谈这些问题也不过如此。我再说一些其它方面的考虑。
XP 是为积极求胜的开发人员准备的。Kent Beck 等人从来就不讳言 XP 确实不是适合所有的人，所以他们对于其它类型的敏捷方法都抱有非常友善的态度（例如 Kent Beck 还曾为质疑 XP 的《Questioning Extreme Programming》做序，证明他毫不担心 XP 所引发的争论）。现在很多带着有色眼镜看待 XP 的人提出的质疑在我看来都是没有多大价值的。他们更多地还是把 XP 看作类似于 CMM 一类的大方法论（普适的真理，千秋万代一统江湖... 之类的阿谀奉承不用我说了），需要在书斋里面研究若干年才能研究清楚的东西。我从来就不这样看待 XP，XP 的所有规则在我看来都是很清楚和具体的（而不是非常笼统的，需要找来某个算命先生才能搞清楚），XP 对于我来说象是某种玩具，我可以这样玩可以那样玩，最后积累的所有经验对于我都是有帮助的。正因为 XP 对于我不仅仅可以远观而且还可以亵玩（请原谅我的趣味比较低级），所以我才觉得 XP 确实是对我很有帮助的东西。而那些需要在书斋里面研究若干年的大方法论与我何干？只要这些 PIG 不要来干涉我的工作，我们就可以相安无事，我对他们敬鬼神而远之。但是一旦他们要来干涉我（来指教我应该如何做设计和开发），对不起，一定会遭到我很激烈的反对。不过幸运的是因为我这几年都在小公司，至今也没有遇到这种情况。 如果一个开发人员不是积极求胜的，他做开发工作只是为了饭碗（只是一种谋生的手段），或者他工作不是为了获得胜利（不是抱着一种无论如何必须要取胜的决心和信念）让用户感到满意，而是为了中规中矩不犯任何错误，他也不愿意承担更多的责任，那么这样的开发人员就是不适合 XP 的。当然有人会说这样的人留着做什么？直接开掉算了。但是非常遗憾，据我观察这样的开发人员还是占大多数的。如何对这样的开发人员加以适当的引导和激发，使得他们发现自己的潜力，并且对于工作产生真正的兴趣，通过改进工作质量逐渐获得信心，愿意承担更大的责任，是我现在非常关注的一个问题。所以我很佩服《七武士》里面的那七个人，居然可以把普通的农民训练成为优秀的战士。其实每个人都是有很大的潜力的，他并不知道自己究竟能做多少事情，只要适当加以引导和激发，就能发掘出他的潜力。这样做也是对他负责，比起不加任何培养发现不行就简单地开掉要好的多（那样会对他的信心造成毁灭性的打击，在我们看来是非常不负责任的做法）。实际上很多时候开掉一个人，这个人的直接主管是要负一半责任的。 |
| 返回顶楼 | |
|
发表时间：2004-11-13
ozzzzzz 写道 代码=设计则是任何组织都应该遵守的一条铁的原则，其真实的意义在于任何的文档和非代码的手段，都不能真实地反映设计，也不能验证设计，更加不能无失真的体现设计。如果不严守这个底线，那些这个组织的开发过程注定就是一种混乱与糟糕的。这并不是危言耸听，而是对待设计的态度究竟是一种究竟把其看作只是一种头脑中的构想，还是一种现实中的设想。如果不能把持住这一点，那么任何的测试和修正bug都会显得无聊而可笑。这也是很多重型的方法在大型的开发应用中不断产生莫名其妙错误的一个思想根本。我们再也不要犯把英尺和厘米混淆的荒唐事故了。真实地看待设计的思想性和现实性，才会理解代码=设计的深刻内涵。当然代码=设计，并不是要排除设计的构想和准备，而是说必须对这些构想和准备进行实际的落实，并且用代码来体现，以使得其合理性和操作得当真正的认定。
说得好！ 另外我不太明白非预留的checkin/checkout是个什么概念，哪位可以解释一下？谢谢！ |
| 返回顶楼 | |
|
发表时间：2004-11-13
要想明白非预留的checkin/checkout，其实只要理解了预留checkin/out就可以了。实际上这个概念很简单，预留的checkin/out是提前规定好的，粒度较大的。而持续集成显然是一种随机性的，粒度细小的。显然预留的，可以更好的控制二进制文件（编译的obj、图像等等）的版本控制。而非预留的，由于会产生无数的版本，对于二进制的文件就显得无能为力。但是由于集成是持续的，也就是最彻底的编译版本在不断的被建造，这个时候对于需要连接不同版本的obj和使用不同版本的图像的要求不存在了，也就是说持续集成部需要中间产品的支持。当然这个时候对于编译服务器的硬件要求就会很高。当然我认为可以实行先在本地编译通过，然后checkin和out的策略，以缓解编译服务器的压力。但是我认为现在硬件的成本已经很低了，考虑添加一台强劲的服务器，或者将编译服务器和SCM服务器分离并不会带来很多的成本支出，而其产生的效益会很快的收回这个支出。
|
| 返回顶楼 | |
