1,265
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
scalene 2004-01-15
- 打赏
- 举报
zengpan_panpan() :
什么是“稍微的变化”？每个模式，都有其固有的前提，解决目标，优/缺点。其形式的确不是最重要的，最简单的如聚合/关联，形式很可能是相同的，但因其前提/目标不同，在OO中就是两个完全不同的术语。我为什么说你的只能说是“属性链”而非“Decorator”？因为两者在试图解决完全不同的问题，应用的环境也是完全不同的。而不是你理解了中文含义的“修饰”的语义，也就说明你理解了“Decorator”模式的语义，如果那样的话，大家背背名词解释就可以了，设计模式也太好理解了。
关于第二个问题，我不想理会你哪些无聊的攻击。什么“我不当项目经理，但是我决定谁可以当项目经理。”，什么“OO，敏捷开发之类的叫个不停了”之类的话，和讨论无关，我完全无须回答。这些问题，不是读几本书的问题，只有你有了多年的设计/管理经验才可能领会。我建议你多读些敏捷和OO的东西，现在看来还要加上设计模式，因为我发现你对模式的理解实在是一知半解。
什么是“稍微的变化”？每个模式，都有其固有的前提，解决目标，优/缺点。其形式的确不是最重要的，最简单的如聚合/关联，形式很可能是相同的，但因其前提/目标不同，在OO中就是两个完全不同的术语。我为什么说你的只能说是“属性链”而非“Decorator”？因为两者在试图解决完全不同的问题，应用的环境也是完全不同的。而不是你理解了中文含义的“修饰”的语义，也就说明你理解了“Decorator”模式的语义，如果那样的话，大家背背名词解释就可以了，设计模式也太好理解了。
关于第二个问题，我不想理会你哪些无聊的攻击。什么“我不当项目经理，但是我决定谁可以当项目经理。”，什么“OO，敏捷开发之类的叫个不停了”之类的话，和讨论无关，我完全无须回答。这些问题，不是读几本书的问题，只有你有了多年的设计/管理经验才可能领会。我建议你多读些敏捷和OO的东西，现在看来还要加上设计模式，因为我发现你对模式的理解实在是一知半解。
zengpan_panpan 2004-01-15
- 打赏
- 举报
与缺乏计算机基础知识的人空谈什么方法，看来只能是对牛弹琴了。其实中国IT行业水平的低下就是因为绣花枕头太多，不能不说是种悲哀了。
scalene 2004-01-15
- 打赏
- 举报
zengpan_panpan() :
Decorator是什么，我没兴趣和你解释了，何况它本身就是和这个贴子无关的问题。
其它的话，我没兴趣讨论。很高兴你每天读书的时间比我上班的时间长，我能得到的结论是，要么你不上班，要么你的工作是图书管理员。
不过这样博览群书的人，会把抽象和面向对象，重用和敏捷的概念混为一谈，那可真是滑天下之大稽了。
另外，不要说那么多如果，也不要一直拿一些弱智的问题到处考人，会被人笑话的。
Decorator是什么，我没兴趣和你解释了，何况它本身就是和这个贴子无关的问题。
其它的话，我没兴趣讨论。很高兴你每天读书的时间比我上班的时间长，我能得到的结论是，要么你不上班，要么你的工作是图书管理员。
不过这样博览群书的人，会把抽象和面向对象，重用和敏捷的概念混为一谈，那可真是滑天下之大稽了。
另外，不要说那么多如果，也不要一直拿一些弱智的问题到处考人，会被人笑话的。
zengpan_panpan 2004-01-15
- 打赏
- 举报
至于"Decorator"是不是修饰，这个道理很简单。如果能具体实现，名词解释也就说给一知半解的人听了。
我不知道你到底搞了多少年，怎样看你那些所谓应用开发的。5年以前我就搞过一个银行系统项目。那个时候大家全都用C，所有应用逻辑全部使用脚本驱动。用这个系统给下一个银行搞开发根本不需要更多改变，分析设计完成后，多数问题的解决都通过改变脚本实现。针对具体行业的脚本引擎，你有没有？如果说你在同种行业搞了3个项目，还总结不出应用逻辑的脚本引擎的话，实在不敢恭维。我想，这种东西应该比你的OO更抽象，比你的敏捷方法更敏捷吧？编码，测试，维护的代价都可以大大降低。只有游戏行业竞争最激烈，现在的游戏公司哪一个不要自己的游戏引擎，即使自己做不出来，也会去买。而现在那些应用开发种，java把前面的jsp/servlet，后面的数据库连接，分布模型都完成了，唯一不能完成的就是具体应用逻辑。设计应用逻辑的时候，各种方法都在闹，没见谁真正设计了自己的脚本引擎，结果事实上都还在低水平发展，这才是现在最大的问题。如何设计脚本引擎，需要哪些知识？
不管面向过程也好，OO也好，GP也好，事实上最终的目的都是在于描述概念。力求简洁，对概念要求内涵精确，外延适当。对于书的问题，前面我已经说了，你要不去读那些论文，读了书也只是作者的fans，我一天读书的时间比你上班的时间还长。
不管设计模式也好，现在的UML也好，到处都在提一个状态的概念，这个状态到底是个什么东西，你清楚么？和自动机理论有什么关系？能够解决哪一类的问题？可不可以使用更高级的自动机，达到更强的描述能力？
如果这些问题你解释不了，我还是建议你先去把计算机的基础知识补习一下。再来谈什么方法论，否则就成了绣花枕头。
我不知道你到底搞了多少年，怎样看你那些所谓应用开发的。5年以前我就搞过一个银行系统项目。那个时候大家全都用C，所有应用逻辑全部使用脚本驱动。用这个系统给下一个银行搞开发根本不需要更多改变，分析设计完成后，多数问题的解决都通过改变脚本实现。针对具体行业的脚本引擎，你有没有？如果说你在同种行业搞了3个项目，还总结不出应用逻辑的脚本引擎的话，实在不敢恭维。我想，这种东西应该比你的OO更抽象，比你的敏捷方法更敏捷吧？编码，测试，维护的代价都可以大大降低。只有游戏行业竞争最激烈，现在的游戏公司哪一个不要自己的游戏引擎，即使自己做不出来，也会去买。而现在那些应用开发种，java把前面的jsp/servlet，后面的数据库连接，分布模型都完成了，唯一不能完成的就是具体应用逻辑。设计应用逻辑的时候，各种方法都在闹，没见谁真正设计了自己的脚本引擎，结果事实上都还在低水平发展，这才是现在最大的问题。如何设计脚本引擎，需要哪些知识？
不管面向过程也好，OO也好，GP也好，事实上最终的目的都是在于描述概念。力求简洁，对概念要求内涵精确，外延适当。对于书的问题，前面我已经说了，你要不去读那些论文，读了书也只是作者的fans，我一天读书的时间比你上班的时间还长。
不管设计模式也好，现在的UML也好，到处都在提一个状态的概念，这个状态到底是个什么东西，你清楚么？和自动机理论有什么关系？能够解决哪一类的问题？可不可以使用更高级的自动机，达到更强的描述能力？
如果这些问题你解释不了，我还是建议你先去把计算机的基础知识补习一下。再来谈什么方法论，否则就成了绣花枕头。
zengpan_panpan 2004-01-14
- 打赏
- 举报
当然是交流术语，但是如果连稍微的变化都不能理解的话，这只能说明能力太差。
这不是幻想，这是一个方法论研究者应有的想法。我不知道你到底看了多少书，一个简单的道理明不明白，书上的东西明显带有倾向性。不要以为看懂了什么经典著作就能叫精通了，很多负责任的作者，都会在每一章的最后提到很多参考书籍，以及论文。那些东西看过没有？很多精华的东西，很多不同的意见都在那些论文上。如果没有看过，就不要什么OO，敏捷开发之类的叫个不停了。最多只能算个作者的fans.
这不是幻想，这是一个方法论研究者应有的想法。我不知道你到底看了多少书，一个简单的道理明不明白，书上的东西明显带有倾向性。不要以为看懂了什么经典著作就能叫精通了，很多负责任的作者，都会在每一章的最后提到很多参考书籍，以及论文。那些东西看过没有？很多精华的东西，很多不同的意见都在那些论文上。如果没有看过，就不要什么OO，敏捷开发之类的叫个不停了。最多只能算个作者的fans.
scalene 2004-01-14
- 打赏
- 举报
zengpan_panpan():
所以应该去学的是它的思想方法，而不是生搬硬套它的结构
-----------------------------------------------------
这句话说的原本没错。但是并不是说我们可以把八戒说成唐僧。模式的用途之一就是提供一些帮助设计人员交流的术语。创新和因地制宜无疑是必须的，但是请不要张冠李戴，否则必然会导致交流的障碍。
任何一个思想方法的倡导者都会尽可能扩大它的应用范围，决不会武断地认为实现什么东西在思路上会有完全的不同；而是尽可能地调和，抽象出共性
-----------------------------------------------------
我拒绝对这句话做什么评论。我能说的只是：那是你的幻想。多学习一些OO的思想和敏捷开发的思想吧，对你会有好处的。
所以应该去学的是它的思想方法，而不是生搬硬套它的结构
-----------------------------------------------------
这句话说的原本没错。但是并不是说我们可以把八戒说成唐僧。模式的用途之一就是提供一些帮助设计人员交流的术语。创新和因地制宜无疑是必须的，但是请不要张冠李戴，否则必然会导致交流的障碍。
任何一个思想方法的倡导者都会尽可能扩大它的应用范围，决不会武断地认为实现什么东西在思路上会有完全的不同；而是尽可能地调和，抽象出共性
-----------------------------------------------------
我拒绝对这句话做什么评论。我能说的只是：那是你的幻想。多学习一些OO的思想和敏捷开发的思想吧，对你会有好处的。
zengpan_panpan 2004-01-14
- 打赏
- 举报
模式不能简单等同于一种形式，设计模式本身是一种思想方法，用java也好c++也好，书本给出的东西事实上仅仅是作者使用具体语言对于他的思想方法的具体描述而已。所以应该去学的是它的思想方法，而不是生搬硬套它的结构。你说的其实是典型的买椟还珠的思想。
各种需求，都是相互联系的，任何一个思想方法的倡导者都会尽可能扩大它的应用范围，决不会武断地认为实现什么东西在思路上会有完全的不同；而是尽可能地调和，抽象出共性。至于你只能做应用系统那是你的事情。我考虑的是整个系统构架，从设备性能分析，语言选择，基础库，到具体应用，所有关系的协调。如果你是项目经理的话，估计就只能到此为止了。我不当项目经理，但是我决定谁可以当项目经理。
各种需求，都是相互联系的，任何一个思想方法的倡导者都会尽可能扩大它的应用范围，决不会武断地认为实现什么东西在思路上会有完全的不同；而是尽可能地调和，抽象出共性。至于你只能做应用系统那是你的事情。我考虑的是整个系统构架，从设备性能分析，语言选择，基础库，到具体应用，所有关系的协调。如果你是项目经理的话，估计就只能到此为止了。我不当项目经理，但是我决定谁可以当项目经理。
scalene 2004-01-14
- 打赏
- 举报
zengpan_panpan() :
“它的本意就是修饰，而不一定要满足什么固定形式”，那我就要问你，“模式”这两个字的含义是什么了。究竟什么是Decorator应该是有定论的东西，而不是你说什么是什么就是。肤浅不肤浅，大家来评定吧。
并不是什么设计都可以或者都有必要称为jdk或者中间件。这无疑又是你对基本需求理解的偏差。设计一个应用系统，一个中间件，或者一个通用类库，其思路是完全不同的。而我们要做的工作无疑是第一种。如果理解这种问题都有障碍的人，而奢谈什么“构造高度可扩展性的系统”，原本就是可笑的。
“它的本意就是修饰，而不一定要满足什么固定形式”，那我就要问你，“模式”这两个字的含义是什么了。究竟什么是Decorator应该是有定论的东西，而不是你说什么是什么就是。肤浅不肤浅，大家来评定吧。
并不是什么设计都可以或者都有必要称为jdk或者中间件。这无疑又是你对基本需求理解的偏差。设计一个应用系统，一个中间件，或者一个通用类库，其思路是完全不同的。而我们要做的工作无疑是第一种。如果理解这种问题都有障碍的人，而奢谈什么“构造高度可扩展性的系统”，原本就是可笑的。
zengpan_panpan 2004-01-14
- 打赏
- 举报
这只能说明你对Decorator的理解太过肤浅，它的本意就是修饰，而不一定要满足什么固定形式，如果使用java或者c++，你可能在书上能够找到它的形式化描述，但是你不能保证其它语言能够提供同种形式的描述。
对于属性的理解，你认为它是个抽象概念，然而你在上面的分析过程中实际上把它们具体化了；而我的分析中，并没有真正具体化它们，只不过用“色狼”，“秃头”两词取代“属性1”，“属性2”...“属性n”这样死板的概念。至于要不要“比较色，比较秃”这样的东西，取决于对“色狼”“秃头”这种属性对象的最终需求。但这并不影响对人这种对象本身的描述，也就是说整个问题考虑的就是人对象及其属性的剥离。
至于有没有滥用模式，这很容易解释，因为按照你的思想，什么jdk，什么中间件都是多余的。或者说你只能设计面向最终用户的东西；而缺乏设计一些库，设计中间件之类提供给具体开发人员使用的工具的能力。
另外，如果理解这种问题都有障碍的人，成不了我的组员。
对于属性的理解，你认为它是个抽象概念，然而你在上面的分析过程中实际上把它们具体化了；而我的分析中，并没有真正具体化它们，只不过用“色狼”，“秃头”两词取代“属性1”，“属性2”...“属性n”这样死板的概念。至于要不要“比较色，比较秃”这样的东西，取决于对“色狼”“秃头”这种属性对象的最终需求。但这并不影响对人这种对象本身的描述，也就是说整个问题考虑的就是人对象及其属性的剥离。
至于有没有滥用模式，这很容易解释，因为按照你的思想，什么jdk，什么中间件都是多余的。或者说你只能设计面向最终用户的东西；而缺乏设计一些库，设计中间件之类提供给具体开发人员使用的工具的能力。
另外，如果理解这种问题都有障碍的人，成不了我的组员。
scalene 2004-01-14
- 打赏
- 举报
zengpan_panpan():
从设计角度来说，你的"Decorator"我并不认为它是一个Decorator，因为它缺乏Decorator的基本特征，即修饰类只是重载基类接口的方法，给予一个修饰性的实现，而不是定义新的接口，这两者本身是有原则性区别的，因为你所给出的模式本质，实质是提供一些辅助类，而非提供原有接口的实现，以及修改接口一个已有类的的行为表现（注意是接口所定义的范畴）。这虽然也是一个原则性的错误，不过这并不是你所犯错误的根本所在。
当我讨论这个问题时，一直是针对系统分析过程的。如果你对需求的分析本身有问题，无论你的设计技术或再高超，也只能是南辕北辙。
当你做这个设计时，虽然也可以满足提出的要求，但是你无形中增加了许多假定：
1. 人这个对象有若干（不定）的属性，这些属性可以动态给予或删除，并且能够为对象增加新的方法；
2. “色狼”和“秃头”属于这样的属性范畴；
3. “色狼”和“秃头”属于静态属性（或有或无，二值逻辑）；
4. 人这个对象只有一种属性接口，“色狼”和“秃头”是这同一个属性接口的派生类；
5. 处理人这个对象时需要了解其所有属性；处理一个属性时也必须有“人”对象的所有权（否则无法通过getProp()之类的方法获得）
......
但是显然这些都不是必须的。按照你的思路分析下去：
首先，“色狼”，“秃头”，这些人的属性很可能只需要你能够查询得到就可以了，它有主动方法吗？或是有被动的消息响应？这我不能确定。所以是否需要你的属性链表，我也不能确定。
其次，“色狼”，“秃头”一定是人的某种属性而非状态吗？是否有可能，需要小王行凶的时候，称其为“色狼”，而平时称为“正常人”；当戴上发套时称为“不秃”，脱下发套称为“秃头”呢？
再其次，“属性”是很泛泛的一个概念，在处理“人”对象时，秃头和色狼是否需要相同方式处理？很值得可疑。
再次，“色狼”和“秃头”一定是二值逻辑吗？是否应该有“比较色”和“比较秃”的概念存在呢？
再次，“色狼”，“秃头”和人，从实际生活中描述的虽然是同一个对象，但是在软件系统中并不一定非要保存在同一个对象之中。这由你的系统如何划分，所关心的是人的那些属性而定。很有可能是完全无关的类，只要通过某种方式（如ID）能够保持其一致性就可以了。
......
总之一句话，没有需求的模式应用就是模式滥用，没有需求的冗余设计就是过度设计。
它的代价必然是不必要的开销。对于代码量的评估，请不要忘记测试的开销。原本一个简单设计，无需几行测试代码。变成你的属性链之后，要保证逻辑正确，Unit Test就会变得非常复杂。并且给系统引入了无意义的所谓“修饰”类。根据现有的需求，你的“修饰”类链表中实际上只有“色狼”一个属性，想想吧，你的组员会怎么看待这个莫名其妙的怪胎设计？
从设计角度来说，你的"Decorator"我并不认为它是一个Decorator，因为它缺乏Decorator的基本特征，即修饰类只是重载基类接口的方法，给予一个修饰性的实现，而不是定义新的接口，这两者本身是有原则性区别的，因为你所给出的模式本质，实质是提供一些辅助类，而非提供原有接口的实现，以及修改接口一个已有类的的行为表现（注意是接口所定义的范畴）。这虽然也是一个原则性的错误，不过这并不是你所犯错误的根本所在。
当我讨论这个问题时，一直是针对系统分析过程的。如果你对需求的分析本身有问题，无论你的设计技术或再高超，也只能是南辕北辙。
当你做这个设计时，虽然也可以满足提出的要求，但是你无形中增加了许多假定：
1. 人这个对象有若干（不定）的属性，这些属性可以动态给予或删除，并且能够为对象增加新的方法；
2. “色狼”和“秃头”属于这样的属性范畴；
3. “色狼”和“秃头”属于静态属性（或有或无，二值逻辑）；
4. 人这个对象只有一种属性接口，“色狼”和“秃头”是这同一个属性接口的派生类；
5. 处理人这个对象时需要了解其所有属性；处理一个属性时也必须有“人”对象的所有权（否则无法通过getProp()之类的方法获得）
......
但是显然这些都不是必须的。按照你的思路分析下去：
首先，“色狼”，“秃头”，这些人的属性很可能只需要你能够查询得到就可以了，它有主动方法吗？或是有被动的消息响应？这我不能确定。所以是否需要你的属性链表，我也不能确定。
其次，“色狼”，“秃头”一定是人的某种属性而非状态吗？是否有可能，需要小王行凶的时候，称其为“色狼”，而平时称为“正常人”；当戴上发套时称为“不秃”，脱下发套称为“秃头”呢？
再其次，“属性”是很泛泛的一个概念，在处理“人”对象时，秃头和色狼是否需要相同方式处理？很值得可疑。
再次，“色狼”和“秃头”一定是二值逻辑吗？是否应该有“比较色”和“比较秃”的概念存在呢？
再次，“色狼”，“秃头”和人，从实际生活中描述的虽然是同一个对象，但是在软件系统中并不一定非要保存在同一个对象之中。这由你的系统如何划分，所关心的是人的那些属性而定。很有可能是完全无关的类，只要通过某种方式（如ID）能够保持其一致性就可以了。
......
总之一句话，没有需求的模式应用就是模式滥用，没有需求的冗余设计就是过度设计。
它的代价必然是不必要的开销。对于代码量的评估，请不要忘记测试的开销。原本一个简单设计，无需几行测试代码。变成你的属性链之后，要保证逻辑正确，Unit Test就会变得非常复杂。并且给系统引入了无意义的所谓“修饰”类。根据现有的需求，你的“修饰”类链表中实际上只有“色狼”一个属性，想想吧，你的组员会怎么看待这个莫名其妙的怪胎设计？
zengpan_panpan 2004-01-14
- 打赏
- 举报
你当然没有提到过容器，我仅仅是说上面的问题可以用容器很简单的就实现。而且通过容器强化Decorator可以取到比普通Decorator更强的能力。容器和Decorator是可以关联起来的，这就在于你对Decorator本身的理解。设计模式要和具体语言环境结合起来才能发挥作用，没有单纯的设计模式。而且设计模式也不是万能的。一个简单问题，有没有哪种语言能够执行过程中创造函数，并执行？这是设计模式书上决不会提到的方法。但是这对于解决相当多的问题有积极意义。什么语言？
我也不会去把敏捷当成个口号。问题在于代码量的评估，你对代码量的预期太大，要不了多少行就可以实现的东西，你居然以为要几百行，这个是严重问题。一个员工1小时能完成的工作，你以为10小时才能完成，如果这样管理项目，公司迟早要被你拖死的。
我也不会去把敏捷当成个口号。问题在于代码量的评估，你对代码量的预期太大，要不了多少行就可以实现的东西，你居然以为要几百行，这个是严重问题。一个员工1小时能完成的工作，你以为10小时才能完成，如果这样管理项目，公司迟早要被你拖死的。
scalene 2004-01-14
- 打赏
- 举报
zengpan_panpan() :
容器和Decorator有关吗？我有提到过容器类吗？针对这个问题，和容器类有一点点关系吗？
你的逻辑我真是看不懂。或者这就是你所理解的“敏捷”？
容器和Decorator有关吗？我有提到过容器类吗？针对这个问题，和容器类有一点点关系吗？
你的逻辑我真是看不懂。或者这就是你所理解的“敏捷”？
zengpan_panpan 2004-01-14
- 打赏
- 举报
只能说明一点，你的软件工程相当于从烧砖头开始盖楼房。
容器相关的实现，常用的语言都有现成的，而不是你想象的需要从头开始什么都必须自己实现。这就恰恰证明了空谈软件工程，对于具体开发环境根本不了解的危害性。自以为敏捷，实际上笨拙，创建敏捷的方法的家伙会被气死的。
容器相关的实现，常用的语言都有现成的，而不是你想象的需要从头开始什么都必须自己实现。这就恰恰证明了空谈软件工程，对于具体开发环境根本不了解的危害性。自以为敏捷，实际上笨拙，创建敏捷的方法的家伙会被气死的。
swinging 2004-01-13
- 打赏
- 举报
scalene(南瓜汤) 的观点很不赞同，
而且我认为scalene(南瓜汤) 本身所举论据"对于需求变化的预测应该基于领域的专家知识，而不是软件工程方法学或OO方法学。"等我其实赞同，
但是这个和现在的讨论基本关系不大，
讨论对一个简单需求的OO设计，一方面可能是为了应对需求变化，不过即使是这样，
我想其主要还是要构造高度可扩展性的系统，这个本身也许必须基于领域的专家知识但是大多数还是不需要太多某个领域的专家知识的（我没说不需要），
简单地说，就拿“色狼”是否作为属性还是接口或者就是人的一个子类，一个适当的选择
可以很大限度提高系统的扩展性，以应对将来可能的需求变更（当然本身还有其它的方面），
而且，另一方面来说，没有这种讨论，有相关领域的专家知识做什么？
因为单就人、小王、色狼这么几个角色来说，大多数人还是这个领域（倒，姑且就算吧）有相应理解的共识的，讨论起来很方便，这都讨论不开？
而且我认为scalene(南瓜汤) 本身所举论据"对于需求变化的预测应该基于领域的专家知识，而不是软件工程方法学或OO方法学。"等我其实赞同，
但是这个和现在的讨论基本关系不大，
讨论对一个简单需求的OO设计，一方面可能是为了应对需求变化，不过即使是这样，
我想其主要还是要构造高度可扩展性的系统，这个本身也许必须基于领域的专家知识但是大多数还是不需要太多某个领域的专家知识的（我没说不需要），
简单地说，就拿“色狼”是否作为属性还是接口或者就是人的一个子类，一个适当的选择
可以很大限度提高系统的扩展性，以应对将来可能的需求变更（当然本身还有其它的方面），
而且，另一方面来说，没有这种讨论，有相关领域的专家知识做什么？
因为单就人、小王、色狼这么几个角色来说，大多数人还是这个领域（倒，姑且就算吧）有相应理解的共识的，讨论起来很方便，这都讨论不开？
zengpan_panpan 2004-01-13
- 打赏
- 举报
你说的，其实就是现在软件工程应用上普遍存在的问题。之所以方法学家能够创造出各种个样的方法，就在于他研究了现有开发中的很多现象，同时对未来的方向作出预测。
我不知道你到底是学理科的还是学文科的。懂不懂得什么叫作科学的态度？科学的态度要求人们敢于打破对问题的旧有的认识，预见未来。如果爱因斯坦不去怀疑牛顿力学，怎么搞得出相对论。数学是如何研究的，那就是先对问题作出假设，然后尽量想办法去证明它的对错；要不然如何会有歌德巴赫猜想？经济学家年年都在预测未来走势。统计学干什么的？就是用来评估现有的采样数据，预测未来。就算你要开发一个财务系统，功能需求稍微多一点，都要让你提供预测能力。再说得近一点，数据仓库拿来干什么的？还不是为了预测。如果没有预测模式识别系统如何做得出来。
需求预测应该是一门重要的学科，只不过现在没有书本的东西而已。也许正在研究没有成型，抓住一些书上的条条框框不放，这才是最大的问题，知识只是书本上的，永远成不了你自己的。
同时作为一个软件开发者，不会去发现问题，研究问题，解决问题，如何可能有提高？经验的积累就在于不断的批评和自我批评。
也不要去照搬什么敏捷方法的概念。敏捷方法决没有告诉你，如果用较小的代价可以得到更好的实现，而不要去做。书上的教条往往成为做不好东西推卸责任的理由。
我不知道你到底是学理科的还是学文科的。懂不懂得什么叫作科学的态度？科学的态度要求人们敢于打破对问题的旧有的认识，预见未来。如果爱因斯坦不去怀疑牛顿力学，怎么搞得出相对论。数学是如何研究的，那就是先对问题作出假设，然后尽量想办法去证明它的对错；要不然如何会有歌德巴赫猜想？经济学家年年都在预测未来走势。统计学干什么的？就是用来评估现有的采样数据，预测未来。就算你要开发一个财务系统，功能需求稍微多一点，都要让你提供预测能力。再说得近一点，数据仓库拿来干什么的？还不是为了预测。如果没有预测模式识别系统如何做得出来。
需求预测应该是一门重要的学科，只不过现在没有书本的东西而已。也许正在研究没有成型，抓住一些书上的条条框框不放，这才是最大的问题，知识只是书本上的，永远成不了你自己的。
同时作为一个软件开发者，不会去发现问题，研究问题，解决问题，如何可能有提高？经验的积累就在于不断的批评和自我批评。
也不要去照搬什么敏捷方法的概念。敏捷方法决没有告诉你，如果用较小的代价可以得到更好的实现，而不要去做。书上的教条往往成为做不好东西推卸责任的理由。
scalene 2004-01-13
- 打赏
- 举报
1、需求的变化往往是市场变化产生的，不是某个人所能预测的。
2、开发人员毕竟绝大多数不是领域专家，不是愿不愿意去学的问题，而是你愿不愿意承认的问题。
3、不预测需求变化并不一定意味着我没有领域专家知识，而恰恰可能说明我运用领域专家知识得到结论：这里没有变化的需要，或者这里的变化是不可预测的。
敏捷方法的精髓就在于不去妄图创造一个“完美”的系统，而是根据实际情况去开发一个“适当”的系统。
2、开发人员毕竟绝大多数不是领域专家，不是愿不愿意去学的问题，而是你愿不愿意承认的问题。
3、不预测需求变化并不一定意味着我没有领域专家知识，而恰恰可能说明我运用领域专家知识得到结论：这里没有变化的需要，或者这里的变化是不可预测的。
敏捷方法的精髓就在于不去妄图创造一个“完美”的系统，而是根据实际情况去开发一个“适当”的系统。
zengpan_panpan 2004-01-13
- 打赏
- 举报
这个问题就在于你自己了，不懂的东西你可以学嘛，这一次参加这一类的项目，你没有专家知识；下一次参加同类项目的时候，你是不是也没有？关键问题在于你愿不愿意去学。如果你总认为，我只要精通计算机就够了；其它的东西我都不管，反正我不是研究这个的，那就完了。
scalene 2004-01-13
- 打赏
- 举报
程序要有一定的灵活性。但对于需求变化的预测应该基于领域的专家知识，而不是软件工程方法学或OO方法学。如果你不了解该领域，最好的方式就是不要预测。因为这种预测==妄想。
zengpan_panpan 2004-01-13
- 打赏
- 举报
不要这么想，我要是你的客户你就完了。需求变动是很自然的事情，软件设计就需要尽量想办法适应需求变化。如果你事事都能想到你的客户前面去，那就是最好的事情，虽然这几乎不可能，但这应该是个努力的方向。
scalene 2004-01-13
- 打赏
- 举报
一群无聊的人。
简单的多态就能解决问题，非要自己臆造出一堆需求。
faint...
简单的多态就能解决问题，非要自己臆造出一堆需求。
faint...
加载更多回复（27）
