re: 对"UP是正楷，XP是草书"的反思 Justin 2007-08-20 16:10
其实对于人员素质之言，我觉得在这里谈高低好像也没有什么根据。软件行业不是建筑行业，就超过百年历史。软件行业实在是小弟，所以，既然是参与软件行业，必定需要有过人的智慧，浑水摸鱼的不在此列啊。
XP和UP，其实我觉得用主动和被动两个词分别形容，比较恰当。UP好像不关心你对项目，对软件有多大热情，按部就班。XP呢，如果你没有十足的热情，就是想拿份工钱，是干不下去的。
如果OO设计直接就可以将现实生活中的概念引用过来，那也就不需要什么软件工程师了！OO设计的关键概念是抽象。如果没有抽象，那所有的软件工程师的努力都是徒劳的。因为如果没有抽象，我们只能去构造世界中每一个对象。
太经典了，谢谢
re: 对"UP是正楷，XP是草书"的反思 mabo 2007-01-05 10:35
质疑一：为什么要从xp-->up?
质疑二：难道团队间的信任和尊重是靠文档建立起来的？笑话
质疑三：如果项目成员水平不行，能指望靠类似up的过程管理取得成功？作者口口声称“人是最重要的”，结论却是“过程可以弥补人的不行”。我老婆都说“自相矛盾”
楼上何必这么fq呢，每个人都有自己的理解，谁也不能完全保证正确
这样的文章拿出来讨论，不是更锻炼新手的判断能力么
尽信书则不如无书，我们要锻炼的是自己的独立思考能力呀
竟然有人称之为好文章！
读书笔记的作者明显歪曲原书作者的意思。正如楼上 charon@xxx 所说！真不清楚现在为什么老有人喜欢散发这样不负责任的东西。这样的读书笔记，别拿出来误人子弟！
现在去www.mylinux.com.cn网站趣味问答,做题目,奖积分.积分还能直接购物呢.提供给你一个学习的机会,对软件编程人员有很大的帮助哦
我觉得支持脚本的最大好处可以利用脚本的类库
使得java慢慢的平台化
还有我感觉像那天讲的那样的对脚本的支持，还是不很方便
re: 一个介绍Java开源项目及工具的网站 home 2006-06-27 21:49
真的么？
re: UP & XP之争，意义何在？(续) SpiderMan 2006-05-11 17:23
XP 与 UP之争的背后，体现着两种不同文化理念、价值观的差异
打个比方：
教育、培养人的道德观念，提高人们的素养，来降低犯罪。
还是
制定大量的法律条例，来打击、制止犯罪。
re: 对"UP是正楷，XP是草书"的反思 SpiderMan 2006-05-11 17:17
XP建立在对团队充分信任的基础之上，对团队成员的尊重信任是项目开展的基础。团队成员间的这种信任必须是相互的、平等的，这些信任又是基于团队成员都具备较丰富的项目经验、具有同等的知识广度与深度、接近的价值观理念而建立起来的。在这个基础之上，才能最大限度发挥团队的创造力和协作能力，进行高效率、高质量的开发。这就是以人文本的思想，鼓励发挥每个人、整个团队的主动能动性，激励进步。
而UP强调规范、约束、控制，重流程的管理，对于人员素质要求相对XP来说并不高，因此是建立在不充分信任团队的基础上的，各种措施，诸如：详尽的文档、大量的评审、各种度量 都是为了避免团队成员在项目过程中出现异常情况而带来的风险。因此UP和很多传统方法一样，是被动模式的，因此，团队成员在项目中很可能能力参差不齐、差别很大。由于在UP中，有规范的约束，一些成员造成的故障、缺陷能以其他方式、由其他成员来协助弥补。因此UP不是以人为本的。不能充分客观的 挖掘每个人的潜能、发挥每个人的特长、评价 每个人的价值。
re: UP & XP之争，意义何在？(续) joachim 2006-04-27 23:58
我想最重要的是需要有一份简单概要的指导原则性的规范，就像法律先要有宪法一样。
随着项目的进行和经验的积累，各种规范、文档会多得吓人，新人进来不大会去完整的读或者学习长达上百页甚至更多的文档。XP的交流应该是更有效。
文档固然可以积累和沉淀知识，但如何让这些沉淀的东西更好更广泛的传播，似乎UP也没有很好的解决办法。
re: UP & XP之争，意义何在？ jinfeng_wang 2006-04-26 16:32
德国人做汤倾向于UP;中国人做汤倾向于XP。
//你确认中国人倾向于XP？？
也许中国人的性格上喜欢XP，但是如果中国人用XP，以中国人的性格，产品的质量能保证么？
re: UP & XP之争，意义何在？(续) GHawk 2006-04-25 17:30
这就好比法规、制度，它存在，但是依然可以违反它。
文档提供了一个做事的准则和流程，声明了一些大家都应该知道和遵守的东西。如果一个人连明文规定的东西都无法理解和遵守。那怎么指望他能够仅仅通过沟通就能遵守团队的行动准则，成为团队的一员呢？应该是很有难度的吧。
文档是UP进行过程控制的手段，XP用来解决过程中采用的是“沟通”。文档的适用范围更普遍一些 ，“沟通”虽然便利，但是会受到很多条件的限制。从UP到XP，可以明确知道哪些文档从“文档”变成了“沟通”；从XP到UP，却很难把所有的“沟通”转化成“文档。”这是因为文档的成本通常比沟通来得高。
re: UP & XP之争，意义何在？(续) yuxie 2006-04-25 16:02
引用“反过来，如果一开始就没有详尽的文档，很多活动（比如设计、版本控制）往往会脱离控制，进入一种无序的、混乱的状态。没有文档可参考，就意味着很多问题只能问人，而不同人的回答可能各异，同一个人对同一个问题的两次回答也可能不同！当然，如果整个团队的工程素养和个体的职业习惯都比较好的情况下可能不会发生类似的情况。但是这种工程素养和职业习惯从哪里来，可能单靠的XP是不足以培养出来的。”
如果你的团队没有足够的经验和工程素养，却又不想组织足够的培训和交流，那么即使文档再多、再详尽也无济于事！
re: UP & XP之争，意义何在？ 读书、思考、生活 2006-04-24 22:53
你这个比方，简直就是......
汤的味道，不需要什么过程控制，如果他味道不对，那是因为做汤的人，写的测试用例不够稳定。
如果能够使用代码化的测试用例，而不是仅仅依靠自己的舌头，或者盲目的遵循所谓的菜谱文档。
这样才能确保每一次做出来的汤，都是一种味道。
老兄，听说过TDD吗？XP运用TDD，以保证代码质量，而不是用量杯，也不是写菜谱。
再说一句，XP不仅仅是一种软件开发过程，而是一种思想，如果你有机会，听听最近一次BEA上海User Group中的Charls的演讲录音就好了。
re: UP & XP之争，意义何在？ Harryson 2006-04-24 08:47
实践中去体会,学习中,,,,
re: UP & XP之争，意义何在？ renyfox 2006-04-23 22:17
我觉得楼猪的阐述还有欠缺的地方。
争论UP和XP的孰优孰劣，实在是……有点想在讨论牛肉好还是羊肉好的感觉，呵呵。
我也同意林德章老师的“UP是正楷，XP是草书”的说法。正楷在可看性的角度上，的确是跟草书相差甚远。但是，无论是哪位书法家，一定都是先学正楷的。学过书法的人都会明白，正楷，它对于掌握字的结构，以及之后行书、草书的学习的重要性。所以真正懂得书法的人，是不会说出“草书比正楷好看”或者“正楷比草书好看”这种话的。它们只是两种书写形式，有各自适用的场合。
软件也是一样。显然，UP更适用于团队实力比较弱、队员层次比较低或者参差不齐的项目。即使它繁复的文档能把人弄疯，但是跟会使项目变得更糟的XP相比，UP的使用不失为一种妥协的方法。哪个作程序的不希望自己的项目过程简单化、优雅化，但是如果仅仅为了简单和优雅，而不顾自身实际条件就盲目地选择XP，结果将是灾难性的。
UP与XP之于软件，刀叉与筷子之于饮食，跑步与跳操之于运动，都只是个方式方法的问题，仅此而已。
实际上,Robert C.Martin的意思是,一个实在的Modem类和分离职责的Modem类到底哪个更好,取决于应用的实际情况.
只有在碰到那种"连接方式有差异"的情形时,再抽象出这两个接口才是正常的.
.
re: 对"UP是正楷，XP是草书"的反思 leolife 2006-03-01 17:08
感觉上很有道理！
的确有投机之嫌，说敏捷过程的东西太少了，就几章而已。^_^
诚然.感觉Interface的引入是对OO的很大的补充,使人们不用再对"继承"的概念含糊不清了
比如AbstractRaceCar需要的是一个能够提供动了的东东,暂时叫他为"IEngeer",只要大小合适,能够提供动力即可.V10可知胜任,如果V8能够符合这个要求的话也行,甚至是舒马赫的双腿--只要他能把他的腿伸进去,我们就不用违心的用多继承说舒马赫也是从"IEngeer"派生而来的,呵呵
To Samuel Cai,
说的有道理。
写的时候一直在斟酌哪样的例子比较合适，因为OCP相当抽象，所以选出好的例子很难，要说明一定要以某种模式实现OCP很困难，我的这个例子有点类似书中OCP那章一开始那个Client/Server的例子。不过，要举出违反OCP的例子倒是不少。最典型的就是通过RTTI（运行时类型鉴别）+ switch 或是 if-else 来进行设计。这样的用法越多，封闭性就越差，模块的刚性也就越强。OCP主张在设计中采用多态等动态机制取代静态机制。当然，通过配置文件的方式进行模块的动态配置也是实现OCP的一种手段。
《敏捷软件开发》我也有一本、影印版的。
发现自己E文够烂、看不明白啊~~~
不知道楼主看的是不是 Martin C 的那本~~
re: 敏捷软件开发 读书笔记 （1）——设计的目标 Programmer's Life 2006-01-06 21:24
恩，OO系列的文章是很有必要写写的，OO说起来简单，但我觉得现在大部分的仍然停留在面向过程
re: 过程的代价 GHawk 2006-01-06 09:48
现在的越来越像是用面向过程的方式开发的了，OO的踪迹越来越浅了。也许是因为我没系统地用过C,或是我用不好面向过程方法，我觉得非OO的设计正在把这个系统变得越来越丑陋。（我没有贬低面向过程方法的意思，好的面向过程设计应该也有它优美之处吧^_^）大家花费时间和精力写出来的代码没有什么重用性可言。大家在设计上下的工夫太少了……
re: 敏捷软件开发 读书笔记 （序——废话） GHawk 2006-01-06 09:38
读书笔记一直没开始写。究其原因，这本书实在写得太贯通了，OO的五大原则都是相互牵扯的，设计模式也是综合运用的。读书心得颇多，而整理归纳需要花些时间。既然决定要做，就该认真去做，不会敷衍了事的。
re: 过程的代价 拉 2006-01-06 00:46
敏捷要求的是一个团队中大多数的人起码都是OO的高手,不会写出一些很垃圾的代码来,机械的使用agile的过程可能适得其反
如果是团队的问题的话,那也没有办法啦,再加班也是枉然
确实,不过呀,后面的两个例子看着看着就有点小不耐烦了.....
呵呵
re: 安装图形界面(X11)中鼠标主题 (转) luffy520 2005-12-14 20:05
＾＿＾
re: 过程的代价 luffy520 2005-12-14 19:59
会用心记得＾＿＾
re: 过程的代价 GHawk 2005-12-14 11:19
在Agile的实施方面有没有比较好的Guide？
请高手多多赐教！
re: 过程的代价 Agile 2005-12-14 10:56
双方没有约定迭代周期？ 没有对每次迭代确定feature？ 日方要走Agile，而你们不是，管理上的问题