[quote]呆板的是人不是软件工程。你灵活一个先概要设计后需求分析看看？不靠规章制度是管理学教你的？[/quote]
软件工程有根据言语和代码分析应该补什么的内容吗

软件工程其实是技术和管理的结合体,只不过技术方面不及计算机科学,管理方面又不及管理学,让管理学解决方向问题,让计算机科学解决技术问题,软工似乎不是在计算机科学和管理学基础产生的

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 01:58 发表

软件工程有根据言语和代码分析应该补什么的内容吗 [/quote]
你就算读一下二十年前的软件工程书籍也该知道有没有啊。针对个人的、针对团队的直到针对公司的各个层次的都有。你到底是读过软件工程才说软件工程浅的还是没读过就说的啊？


:hz1025:突然想起个问题来，你既然说软件工程太浅，又拿三册书问我看得懂不，你这鄙视我呢？

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 02:12 发表

你就算读一下二十年前的软件工程书籍也该知道有没有啊。针对个人的、针对团队的直到针对公司的各个层次的都有。你到底是读过软件工程才说软件工程浅的还是没读过就说的啊？


:hz1025:突然想起个问题来，你 ... [/quote]
我以前读的二十年前的软件工程书,针对个人的、针对团队的直到针对公司的几乎没有,有也只是一带而过
倒是有本IT项目管理花了一章的篇幅讲了,但深度和人力资源管理差远了

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 02:23 发表

我以前读的二十年前的软件工程书,针对个人的、针对团队的直到针对公司的几乎没有,有也只是一带而过
倒是有本IT项目管理花了一章的篇幅讲了,但深度和人力资源管理差远了 [/quote]
我倒是好奇人力资源管理里面的深度到软件开发上还剩多少，它不会在实践中遇到问题吗？在人力资源管理的指导下，你现在是如何做的？

我拿三册书是说明软件工程的方向应该是那本书那样,而不是目前的UML,设计模式之类的东西

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 02:31 发表
我拿三册书是说明软件工程的方向应该是那本书那样,而不是目前的UML,设计模式之类的东西 [/quote]
我不说了吗，软件工程范围大得很，软件工程大概产生于上世纪70年代，目标是利用有限的资源做出尽量高质量的软件，有助于达成目标的领域软件工程应该基本都涉及到了。UML和设计模式怎么不该研究了？这两样都是经过实践考验的。不是每个项目都该用上是没错，可也不至于说方向不对。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 02:29 发表

我倒是好奇人力资源管理里面的深度到软件开发上还剩多少，它不会在实践中遇到问题吗？在人力资源管理的指导下，你现在是如何做的？ [/quote]
这本
[url]http://www.china-pub.com/801323&ref=xilie#ml[/url]
它每章涉及一个课题,这些课题都是会遇到的,即使在软件开发也是如此(业余开发也只有薪酬管理用不到)
它肯定在实践中会遇到问题,但能解决的比软工要多

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-25 02:39 发表

我不说了吗，软件工程范围大得很，软件工程大概产生于上世纪70年代，目标是利用有限的资源做出尽量高质量的软件，有助于达成目标的领域软件工程应该基本都涉及到了。UML和设计模式怎么不该研究了？这两样都是 ... [/quote]

你说的是它的目标,但从现有软件工程成果看,方向差得很远,开发软件的主体是人,心理学肯定必要,然后需要用哲学和数学指导计算机资源的应用,最后用管理学来指导怎么合作,那三卷书在用哲学和数学指导计算机资源的应用做的很好
而UML和设计模式之类完全不是根本的东西,软件工程缺乏的正是地基,同样性质的数据库设计就好很多

火贴留名:emot12:

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 02:50 发表


你说的是它的目标,但从现有软件工程成果看,方向差得很远,开发软件的主体是人,心理学肯定必要,然后需要用哲学和数学指导计算机资源的应用,最后用管理学来指导怎么合作,那三卷书在用哲学和数学指导计算机资源 ... [/quote]
这说明你还是只知道“理论要与实践结合”，连软件工程是什么都没搞清楚就开始否定软件工程，无非还是一个XXX无用论而已。等你实际使用某种软件工程方法做一个三五人团队的项目之后再看软件工程效率高还是你搞一堆其它学科效率高。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-25 02:40 发表

这本
[url]http://www.china-pub.com/801323&ref=xilie#ml[/url]
它每章涉及一个课题,这些课题都是会遇到的,即使在软件开发也是如此(业余开发也只有薪酬管理用不到)
它肯定在实践中会遇到问题,但能解决的比软工要多 [/quote]

软件开发中除了人的管理以外的问题谁来解决？

而且对人的管理，在理论上软件工程可能不如专门研究人的学科深入，在实践上可是更贴近软件开发的。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-26 09:35 发表

这说明你还是只知道“理论要与实践结合”，连软件工程是什么都没搞清楚就开始否定软件工程，无非还是一个XXX无用论而已。等你实际使用某种软件工程方法做一个三五人团队的项目之后再看软件工程效率高还是你搞 ... [/quote]
你倒是说说我哪没搞清楚软件工程了
我也可以说三国开发工程比软件工程更贴近实际

[quote]原帖由 [i]陈珺[/i] 于 2010-5-26 22:55 发表

你倒是说说我哪没搞清楚软件工程了
我也可以说三国开发工程比软件工程更贴近实际 [/quote]
:hz1015:我支持你继续持有此观点。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-26 10:08 发表


软件开发中除了人的管理以外的问题谁来解决？

而且对人的管理，在理论上软件工程可能不如专门研究人的学科深入，在实践上可是更贴近软件开发的。 [/quote]
按你的意思,数据结构在理论上可能不如离散数学深入,但在实践上可是更贴近实际编程的?

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-26 22:58 发表

:hz1015:我支持你继续持有此观点。 [/quote]
嗯,支持一门有表无实的学科

[quote]原帖由 [i]陈珺[/i] 于 2010-5-26 22:59 发表

按你的意思,数据结构在理论上可能不如离散数学深入,但在实践上可是更贴近实际编程的? [/quote]
数据结构理论不够深入吗？数据结构有一部分内容是离散数学在计算机上的应用，一个理论一个应用，怎么比较？关公战秦琼？

[quote]原帖由 [i]陈珺[/i] 于 2010-5-26 23:04 发表

嗯,支持一门有表无实的学科 [/quote]

那你敢不敢回避一切软件工程方法？我前面帖子说了，你费劲学习其它学科学习的好的话，会遇到重复发明软件工程轮子的问题，如果你认为软件工程无用，那么就彻底回避吧。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-26 23:11 发表

数据结构理论不够深入吗？数据结构有一部分内容是离散数学在计算机上的应用，一个理论一个应用，怎么比较？关公战秦琼？ [/quote]
可是你把管理学,心理学与软件工程比了,然后说软件工程好用,如果这样,离散数学就不用学了,数据结构已经足够解决编程问题了,不需要自创一套把离散数学与编程问题结合了

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-26 23:15 发表


那你敢不敢回避一切软件工程方法？我前面帖子说了，你费劲学习其它学科学习的好的话，会遇到重复发明软件工程轮子的问题，如果你认为软件工程无用，那么就彻底回避吧。 [/quote]
我一直说借鉴,你说是不是回避一切软件工程方法
至于重复发明轮子,肯定无法避免,但更多的是改造轮子,创造轮子,更何况目前的轮子在行驶中还是磕磕碰碰的,如果要有编译原理里面形式语法学那么成熟,那直接用完全可以

[quote]原帖由 [i]陈珺[/i] 于 2010-5-26 23:19 发表

可是你把管理学,心理学与软件工程比了,然后说软件工程好用,如果这样,离散数学就不用学了,数据结构已经足够解决编程问题了,不需要自创一套把离散数学与编程问题结合了 [/quote]

你愿意从这个角度比较一下的话，那么你就给出一个大致比例，有多少项目中用到了数据结构，又有多少项目只靠数据结构不够用要专门学习离散数学的？

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-26 23:35 发表


你愿意从这个角度比较一下的话，那么你就给出一个大致比例，有多少项目中用到了数据结构，又有多少项目只靠数据结构不够用要专门学习离散数学的？ [/quote]
似乎都不是很多,当然用离散数学的比只靠数据结构要少些,但是现在很多只学过数据结构去设计算法,头疼得很,跟离散数学没学有很大关系

[quote]原帖由 [i]陈珺[/i] 于 2010-5-26 23:46 发表

似乎都不是很多,当然用离散数学的比只靠数据结构要少些,但是现在很多只学过数据结构去设计算法,头疼得很,跟离散数学没学有很大关系 [/quote]

我很难想象如何做到写一个超过100行的程序而不用到数据结构，但是还没遇到过非得去翻离散数学的情况。只学过数据结构去设计算法确实很头疼，但是应该去学算法课而不是离散数学。确实，我见过不少绞尽脑汁设计算法的情况，但是很可惜实际上都已经存在现成的算法了。你貌似是无视各种实践中容易用到的计算机学科，没有困难创造困难也要上吗？

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-27 00:02 发表


我很难想象如何做到写一个超过100行的程序而不用到数据结构，但是还没遇到过非得去翻离散数学的情况。只学过数据结构去设计算法确实很头疼，但是应该去学算法课而不是离散数学。确实，我见过不少绞尽脑汁设 ... [/quote]
有些程序,调用就几百行了
关键问题是没有离散数学基础,学算法课学得也累,反正都逃不过这一劫,何苦非去逃呢?软件工程实践多遇到问题怎么办,最后还是得回归管理学和心理学

[quote]你貌似是无视各种实践中容易用到的计算机学科，没有困难创造困难也要上吗？[/quote]
似乎你无视我借鉴二字,如果只是凑合下直接学各种实践中容易用到的计算机学科也不是不行,但如果想专门做,这些理论迟早逃不过的.
而且,我只说把基础理论与实际结合,没有说非要创造一套,学习实践中容易用到的计算机学科也是一种方式,只不过学习时侯要用基础理论为指导看,不要太信它,能批判就行了,对于实在没有的,那也不得不创造

[quote]原帖由 [i]陈珺[/i] 于 2010-5-27 00:12 发表

有些程序,调用就几百行了
关键问题是没有离散数学基础,学算法课学得也累,反正都逃不过这一劫,何苦非去逃呢?软件工程实践多遇到问题怎么办,最后还是得回归管理学和心理学 [/quote]

看你前面的讨论，应该是很有实际开发经验的吧，那么要不你找个用不到数据结构的程序的例子来给我长长见识。要是没系统学过计算机科学，学学离散数学倒是有益的，不过说非得先学离散数学再学算法倒是不一定。要是非得说算法课里的离散数学相关知识只能在系统学习离散数学时才能学会，那就只能说学习能力不强了。
应用软件工程方法时遇到书里没教的问题又不能灵活运用的，还能学会管理学和心理学再应用到实践中解决问题？这得偏科到什么程度才行啊:hz1005:

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-27 00:35 发表


看你前面的讨论，应该是很有实际开发经验的吧，那么要不你找个用不到数据结构的程序的例子来给我长长见识。要是没系统学过计算机科学，学学离散数学倒是有益的，不过说非得先学离散数学再学算法倒是不一定。 ... [/quote]
看你怎么定义数据结构了,如果基本数据类型,结构体,数组都算的话,那还真拿不出(不过用这些不需要学数据结构)
没有讨论过的话题怎么灵活运用,离散不学平面图,你倒是灵活运用下去判断一个图是不是平面图

[quote]原帖由 [i]陈珺[/i] 于 2010-5-27 00:25 发表

似乎你无视我借鉴二字,如果只是凑合下直接学各种实践中容易用到的计算机学科也不是不行,但如果想专门做,这些理论迟早逃不过的.
而且,我只说把基础理论与实际结合,没有说非要创造一套,学习实践中容易用到的计算机学科也是一种方式,只不过学习时侯要用基础理论为指导看,不要太信它,能批判就行了,对于实在没有的,那也不得不创造[/quote]
我倒是奇怪了，抽象的管理学和具体软件工程学，你实际使用的方法会更贴近哪一个？是应用抽象的借鉴具体的还是应用具体的借鉴抽象的？管理学你能结合实际应用到实践中，软件工程学就不会灵活运用了？这还是我说的理论与实践脱节的问题啊。这似乎更应该考虑你的应用能力问题而不是软件工程深浅的问题。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-27 00:42 发表

我倒是奇怪了，抽象的管理学和具体软件工程学，你实际使用的方法会更贴近哪一个？是应用抽象的借鉴具体的还是应用具体的借鉴抽象的？管理学你能结合实际应用到实践中，软件工程学就不会灵活运用了？这还是我说 ... [/quote]
你说基础数学容易出问题,还是应用数学容易出问题?如果用一个有问题的理论出了问题怎么办,关键问题不是用,而是用的后果.我发现现在很多敷衍了事的做法也被称为灵活运用了.

一个学科适不适合用,还是看学科本身发展的怎么样,如果很成熟,直接用还可以.对于软工这种还在萌芽期的理论,如果去用,恐怕很容易出问题.而不是因为它实际就用它.软工几十年后可能跟现在完全两样,而数学恐怕变不到哪去.

[quote]原帖由 [i]陈珺[/i] 于 2010-5-27 00:42 发表

看你怎么定义数据结构了,如果基本数据类型,结构体,数组都算的话,那还真拿不出(不过用这些不需要学数据结构)
没有讨论过的话题怎么灵活运用,离散不学平面图,你倒是灵活运用下去判断一个图是不是平面图 [/quote]
为什么数据结构里有别处也有的东西可以不学数据结构就能学会，离散数学里有数据结构里也有的就非得学离散数学、软件工程里有其它学科也有的就得学其它学科？你的逻辑不混乱吗？
另外，你上次用到平面图或者你预期下次用到平面图是什么时候？你要不要为了使用堆、栈、树就把图论、群论、集合论……全部学完？学离散数学还要有前置课程，照你这样要学到什么时候才能开始学习大部分时候真正需要的数据结构？感觉你在度的把握上偏差太大了。


[quote]原帖由 [i]陈珺[/i] 于 2010-5-27 00:49 发表

你说基础数学容易出问题,还是应用数学容易出问题?如果用一个有问题的理论出了问题怎么办,关键问题不是用,而是用的后果.我发现现在很多敷衍了事的做法也被称为灵活运用了. [/quote]
你学离散数学的时候自己证明过相关的定理吗？要是出了问题怎么办？后果多严重啊，不光离散数学是错的了，连数据结构也白学了，你学离散数学的时候没有这样的担心吗？如果没有，是不是敷衍了事呢？


[quote]原帖由 [i]陈珺[/i] 于 2010-5-27 00:59 发表
一个学科适不适合用,还是看学科本身发展的怎么样,如果很成熟,直接用还可以.对于软工这种还在萌芽期的理论,如果去用,恐怕很容易出问题.而不是因为它实际就用它.软工几十年后可能跟现在完全两样,而数学恐怕变不到哪去. [/quote]
可能变和可能不变是你判断成熟不成熟的依据吗？应不应该应用软件工程应该看应用后是否比应用前更容易使软件项目成功，而不是一个空口说的成熟还是稚嫩。另外，也许你需要考虑一下为什么在软件开发中很多项目都使用了或者声称使用了各种软件工程方法，而甚少使用或者声称使用了你所谓的成熟的理论呢？全球IT民工皆醉你独醒吗？当然，如果你的目标是创立一门更能提高软件开发的学科你的观点也许没有问题，但是如果你的目标只是提高项目成功率，我实在不看好你仅“借鉴”软件工程的观点。

[quote]为什么数据结构里有别处也有的东西可以不学数据结构就能学会，离散数学里有数据结构里也有的就非得学离散数学、软件工程里有其它学科也有的就得学其它学科？你的逻辑不混乱吗？
另外，你上次用到平面图或者你预期下次用到平面图是什么时候？你要不要为了使用堆、栈、树就把图论、群论、集合论……全部学完？学离散数学还要有前置课程，照你这样要学到什么时候才能开始学习大部分时候真正需要的数据结构？感觉你在度的把握上偏差太大了。[/quote]
事实上,我是先学数据结构后学离散数学的
说平面图,是因为曾经有个人就为生成一个线不交叉的地图头疼,你觉得光靠算法学灵活运用能解决问题吗
软件工程也同理,沟通问题总得面对吧,而软件工程又讲了多少?灵活运用能解决吗,估计到时赤手空拳就成灵活运用了
如果数据结构把最短路径算法也解释通,那直接学也可以.关键是它就放个代码简单解释下,其结果是很多人理解不了.同理如果软件工程把原理学很清楚直接看也可以,问题是事实不是如此

[quote]原帖由 [i]陈珺[/i] 于 2010-5-27 23:35 发表

事实上,我是先学数据结构后学离散数学的
说平面图,是因为曾经有个人就为生成一个线不交叉的地图头疼,你觉得光靠算法学灵活运用能解决问题吗
软件工程也同理,沟通问题总得面对吧,而软件工程又讲了多少?灵活运 ... [/quote]

笑话，软件工程提供了多少手段来进行沟通的，还有算法，根据你的描述，恐怕在你眼里的软件工程和算法的范围就限于你看过的那几本书了，那也难怪得出这种结论来了。那我不反对你持有这种观点了。

[quote]你学离散数学的时候自己证明过相关的定理吗？要是出了问题怎么办？后果多严重啊，不光离散数学是错的了，连数据结构也白学了，你学离散数学的时候没有这样的担心吗？如果没有，是不是敷衍了事呢？
[/quote]
我主贴就说了,学东西学到可以解决实际问题就可以收手,关键是软件工程根本不足以解决实际问题,用软件工程做的项目BUG还是巨多.
总不能解决不了实际问题,还死抱着软件工程去灵活运用吧,那和自创一套理论有何区别?倒是解决效果更差了.

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-27 23:40 发表


笑话，软件工程提供了多少手段来进行沟通的，还有算法，根据你的描述，恐怕在你眼里的软件工程和算法的范围就限于你看过的那几本书了，那也难怪得出这种结论来了。那我不反对你持有这种观点了。 [/quote]

软件工程是很宽,但是专业到从心理学的角度我是没见过,倒是说些表达要通俗,认真倾听之类的废话很多,你是可以说专业到从心理学的角度也属软件工程范围,但是现在没这种书啊,那你怎么学?

[quote]可能变和可能不变是你判断成熟不成熟的依据吗？应不应该应用软件工程应该看应用后是否比应用前更容易使软件项目成功，而不是一个空口说的成熟还是稚嫩。另外，也许你需要考虑一下为什么在软件开发中很多项目都使用了或者声称使用了各种软件工程方法，而甚少使用或者声称使用了你所谓的成熟的理论呢？全球IT民工皆醉你独醒吗？当然，如果你的目标是创立一门更能提高软件开发的学科你的观点也许没有问题，但是如果你的目标只是提高项目成功率，我实在不看好你仅“借鉴”软件工程的观点。[/quote]
我前面就说了,IT业项目失败率很高,或者说成功也是以高成本,低质量,低效率为代价的,算不上真正成功.
先不说我的理论,就是那三册书也没什么人用,那是不是说那三册书的理论也不实用呢?
软工解决不了很多实际问题,所以才会导致项目失败率很高,而实际问题总得解决怎么办?赤手空拳?
借鉴的含义你还是不明白,原理讲清楚并且能解决实际问题的都可以去接受,但软件工程有几个理论做到了?

[quote]原帖由 [i]陈珺[/i] 于 2010-5-27 23:42 发表

我主贴就说了,学东西学到可以解决实际问题就可以收手,关键是软件工程根本不足以解决实际问题,用软件工程做的项目BUG还是巨多.
总不能解决不了实际问题,还死抱着软件工程去灵活运用吧,那和自创一套理论有何区 ... [/quote]
你就凭着看过的软件工程的只言片语当然不足以解决问题。别人能用软件工程提高项目质量你却不行，你应该找自己的原因。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-27 23:47 发表
软件工程是很宽,但是专业到从心理学的角度我是没见过,倒是说些表达要通俗,认真倾听之类的废话很多,你是可以说专业到从心理学的角度也属软件工程范围,但是现在没这种书啊,那你怎么学? [/quote]
那看来你要组织一个团队得需要一群心理专家才行，要不然沟通居然会有问题。:hz1028:
你看到很多表达要通俗认真倾听之类的废话多是你选的书不行，如果缺乏基本的判断能力，恐怕学什么学都白搭。
但是在软件工程里面，沟通是通过文档、规范、UML、CRC卡片等各种手段来保证沟通的，对心理专家来说，这些可能都太难理解了，毕竟这都是针对软件开发人员设计的。

[quote]先从程序员的思想定位开始.程序员是什么,其实我们不是什么高深摸测的数学家,能使用多少种算法,能把计算机玩得那么厉害,其实程序的本质就是一个翻译者,是一个将人类的行为描述成计算机语言的翻译者.在这个解释里面,有一个根本的定位,就是计算机从属于人类思想!而现在的程序员,大部分习惯使用计算机思想去思考一个问题,当这些程序员看到需求的时候,他们脑子里面第一反映出来的是各种算法,比如说一看到寻路，脑子里面就出现A*两个字,然后就是"可靠" "消耗资源巨大"等一系列字眼,然后就会在这些字眼里面苦苦最求最完美的方案.
     
     但是,第一,我们只是人类的行为的计算机翻译者;第二,从以上观点出发,计算机的算法首先来自于人类的思想;所以,在我们面对需求的时候,为什么不先把自己代入实际环境中,问问人是怎么完成的,当你在各种算法之中苦苦追求完美的时候,为什么不问问自己,如果你在当时的环境下,是否能做到如此完美,如果连人都做不到,为什么要求计算机能完成呢?[/quote]
这是一个搞AI的说的,我发现这种遇到问题不是从它本质去分析而是直接用XX理论然后冥思苦想半天的人多的是,你就是想单靠软件工程和灵活应用解决所有开发问题吧

[quote]你就凭着看过的软件工程的只言片语当然不足以解决问题。别人能用软件工程提高项目质量你却不行，你应该找自己的原因。
[/quote]
的确可以提高项目质量,可是提高项目质量是以大量劳动为代价的,明明别的理论效果更好,何苦要抱着软件工程不放?
不是说不可以提高项目质量,而是(1)提高的太有限,根本满足不了要求;(2)不讲原理,容易产生教条主义,用一个提高的太有限而容易产生教条主义的理论,可行吗?

[quote]那看来你要组织一个团队得需要一群心理专家才行，要不然沟通居然会有问题。
你看到很多表达要通俗认真倾听之类的废话多是你选的书不行，如果缺乏基本的判断能力，恐怕学什么学都白搭。
但是在软件工程里面，沟通是通过文档、规范、UML、CRC卡片等各种手段来保证沟通的，对心理专家来说，这些可能都太难理解了，毕竟这都是针对软件开发人员设计的。[/quote]
我记得有本书就批评UML越来越乱了,现在的关键问题是文档、规范、UML、CRC都只是形式,怎么用呢,我看过一本讲怎么用的书,它说找对象就是把它上面的几类都以"宁可错杀,不可漏网"的方式网罗进来,然后再根据需要筛选掉,问题是上面的几类就全吗,而且怎么筛选掉才合理?这个恐怕又要你所说的灵活运用.讲白了还是治标不治本.

[quote]原帖由 [i]陈珺[/i] 于 2010-5-27 23:58 发表

我前面就说了,IT业项目失败率很高,或者说成功也是以高成本,低质量,低效率为代价的,算不上真正成功.
先不说我的理论,[color=Red]就是那三册书也没什么人用[/color],那是不是说那三册书的理论也不实用呢?
软工解决不了很多实际问题,所以才会导致项目失败率很高,而实际问题总得解决怎么办?赤手空拳?
借鉴的含义你还是不明白,原理讲清楚并且能解决实际问题的都可以去接受,但软件工程有几个理论做到了?[/quote]
你妄下的论断太多了。
通过你对软件工程的描述，你的借鉴的含义就是说软件工程不是彻底的无用而已。我跟你讨论这些，无非是想告诉你软件工程里的学问已经够你学一阵的了，暂时不看好你能发明出什么比现有方法更有效的方法来。大部分人的创新都是站在前人成果的基础上的，只有民科们才能凭空创造各种“更好”的理论。当然，我也无非就是随便说说，你也就随便听听而已。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-28 00:08 发表
这是一个搞AI的说的,我发现这种遇到问题不是从它本质去分析而是直接用XX理论然后冥思苦想半天的人多的是,你就是想单靠软件工程和灵活应用解决所有开发问题吧 [/quote]
我只是告诉你软件工程有用，至于我怎么用那是我的问题。
你对工程的理解还是有问题，软件工程的目标我前面回帖说过，不再多说。在既定目标下使用成熟算法或者复用代码一点问题都没有，有限的资源要有重点地使用，只有菜鸟才会想着处处创新。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-28 00:16 发表
的确可以提高项目质量,可是提高项目质量是以大量劳动为代价的,明明别的理论效果更好,何苦要抱着软件工程不放?
不是说不可以提高项目质量,而是(1)提高的太有限,根本满足不了要求;(2)不讲原理,容易产生教条主义 ... [/quote]
当然，每个人都要选择自己看来最可行的方法，如果你已经创造了更有效的方法，自然可以视软件工程为无物。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-28 00:24 发表
我记得有本书就批评UML越来越乱了,现在的关键问题是文档、规范、UML、CRC都只是形式,怎么用呢,我看过一本讲怎么用的书,它说找对象就是把它上面的几类都以"宁可错杀,不可漏网"的方式网罗进来,然后再 ... [/quote]
哪种理论跟实践没有差距？你那些非软件工程学科手把手教你面对什么问题时要怎么解决了？那得多厚一本，国家图书馆放得下不？软件工程中有些方法就是很呆板的，那是有它的道理的，等你以后做项目慢慢体会吧。


另：其实我认为你更应该先补补逻辑。

[color=Silver][[i] 本帖最后由 Maxwell 于 2010-5-28 00:36 编辑 [/i]][/color]

[quote]你妄下的论断太多了。
[/quote]
那你的意思是应用很广泛了?
[quote]通过你对软件工程的描述，你的借鉴的含义就是说软件工程不是彻底的无用而已。我跟你讨论这些，无非是想告诉你软件工程里的学问已经够你学一阵的了，暂时不看好你能发明出什么比现有方法更有效的方法来。大部分人的创新都是站在前人成果的基础上的，只有民科们才能凭空创造各种“更好”的理论。当然，我也无非就是随便说说，你也就随便听听而已。[/quote]
说了这么多,你还认为我完全独创,从谈话中可以看出,你对我的认识还处于前几年的水平,实际上,我现在大部分时间在看书,而不是冥思苦想,只不过不能完全看软件工程的书,从我的体会看,软件工程很多种理论根本就不是具体教人怎么用,比如什么时侯用那些设计模式,软工的书顶多提些启发思路而已,能不能把有哪些情形分析出来?然后指明?这就是软件工程,一门靠悟的学科.而数据库的范式,那是判断和分解算法都很明确了,看懂就能实际操作.

[quote]哪种理论跟实践没有差距？你那些非软件工程学科手把手教你面对什么问题时要怎么解决了？那得多厚一本，国家图书馆放得下不？软件工程中有些方法就是很呆板的，那是有它的道理的，等你以后做项目慢慢体会吧。[/quote]
那些非软件工程学科,的确理论跟实践有差距,比如图论,线和点的判定就需要悟,但除此之外没有了,而软件工程是大面积的如此,问题就在于它看问题的粒度太大,自然要悟的东西多,而成熟的学科能用基本概念解释复杂问题
呆板是有它的道理的,死去活来的道理大家都明白,但关键就在于已经有现成的理论可以突破呆板,为什么不用

[quote]原帖由 [i]陈珺[/i] 于 2010-5-28 00:43 发表

那你的意思是应用很广泛了?

说了这么多,你还认为我完全独创,从谈话中可以看出,你对我的认识还处于前几年的水平,实际上,我现在大部分时间在看书,而不是冥思苦想,只不过不能完全看软件工程的书,从我的体会看 ... [/quote]
我没有认为你几年前水平低，也没有认为你现在水平高，我的判断只是依据你说软件工程讲得太浅不足以指导开发、要借鉴软件工程等言论。每种理论都是理解之后根据实际情况灵活应用，数据库也不例外，拿个常用的例子来说吧，学号、姓名、身份证号、班级、课程号、课程、成绩等字段，你按第三范式规范一下试试，这是数据库里最简单的东西，一样需要你灵活运用。你感觉数据库讲得具体是因为你熟悉了，在我看来软件工程和数据库都是差不多的情况。可能我看数据库感觉比你对数据库的感觉抽象，如果你设计一个大的数据库系统的时候就会发现数据库课程里面原则性的东西多而具体的东西少了，甚至于几乎每个数据库都会出现打破数据库设计原则的事情。

[quote]我只是告诉你软件工程有用，至于我怎么用那是我的问题。
你对工程的理解还是有问题，软件工程的目标我前面回帖说过，不再多说。在既定目标下使用成熟算法或者复用代码一点问题都没有，有限的资源要有重点地使用，只有菜鸟才会想着处处创新[/quote]
也许我得到的成果的确属于软件工程范畴,但这些成果是参考了大量学科(可能也借鉴过软件工程),那这是不是也牵强附会成是用软件工程呢?
我知道几个世纪前有大成的科学家都懂哲学,钱学森也懂哲学,所以他们视野开阔,容易有成就,倒是现在实用主义多了,把这些基础抛弃了,结果项目出了问题.项目开发本身就是创造过程,一个应用者的思路,能解决的问题终究有限

[quote]原帖由 [i]陈珺[/i] 于 2010-5-28 00:52 发表
那些非软件工程学科,的确理论跟实践有差距,比如图论,线和点的判定就需要悟,但除此之外没有了,而软件工程是大面积的如此,问题就在于它看问题的粒度太大,自然要悟的东西多,而成熟的学科能用基本概念解释复杂问题
呆板是有它的道理的,死去活来的道理大家都明白,但关键就在于已经有现成的理论可以突破呆板,为什么不用[/quote]

你把图论也看得太简单了吧，那也就刚入门。
我前面不说了吗，你要是能做得比现有方法好，那就去做，哪怕是你认为比现有方法好就可以，这事没人拦着你。我只是试图告诉你软件工程里有很多方法可用，既然你确认你的方法比那些都好，那就无视我的话就好了。

[quote]原帖由 [i]陈珺[/i] 于 2010-5-28 01:02 发表
也许我得到的成果的确属于软件工程范畴,但这些成果是参考了大量学科(可能也借鉴过软件工程),那这是不是也牵强附会成是用软件工程呢?
我知道几个世纪前有大成的科学家都懂哲学,钱学森也懂哲学,所以他们视野开阔,容易有成就,倒是现在实用主义多了,把这些基础抛弃了,结果项目出了问题. 项目开发本身就是创造过程,一个应用者的思路,能解决的问题终究有限[/quote]
要是所有人都像科学家一样工作，呵呵。。。科学家和工程师应该用相同的方法工作？但是你的志向要是在理论突破上，那就没有问题了。

[color=Silver][[i] 本帖最后由 Maxwell 于 2010-5-28 01:07 编辑 [/i]][/color]

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-28 00:59 发表

我没有认为你几年前水平低，也没有认为你现在水平高，我的判断只是依据你说软件工程讲得太浅不足以指导开发、要借鉴软件工程等言论。每种理论都是理解之后根据实际情况灵活应用，数据库也不例外，拿个常用的例 ... [/quote]
起码比软件工程要具体,有算法就是一个重要体现,一个理论定量往往比定性要成熟
你有没想过为什么软工无用论的人比数据结构无用论的人要多

[quote]你把图论也看得太简单了吧，那也就刚入门。
我前面不说了吗，你要是能做得比现有方法好，那就去做，哪怕是你认为比现有方法好就可以，这事没人拦着你。我只是试图告诉你软件工程里有很多方法可用，既然你确认你的方法比那些都好，那就无视我的话就好了。[/quote]
图论只是举例,没说很简单,但人家简单化的思想的确值得软工学习
我也只是说明那个观点:软工太浅,不足以指导开发

[quote]原帖由 [i]陈珺[/i] 于 2010-5-28 01:08 发表

起码比软件工程要具体,有算法就是一个重要体现,一个理论定量往往比定性要成熟
你有没想过为什么软工无用论的人比数据结构无用论的人要多 [/quote]

软件工程里算法也不少。软件工程一度认为是只有管理者才需要的、软件工程不直接针对代码、软件工程范畴广泛等等有很多原因。当年相对论也普遍认为是错的，地心说也普遍认为是对的，这又能说明什么？

[quote]要是所有人都像科学家一样工作，呵呵。。。科学家和工程师应该用相同的方法工作？但是你的志向要是在理论突破上，那就没有问题了。
[/quote]
很遗憾,软件开发不是盖房子,盖房子不需要动太多大脑,关键是动手,所以总结怎么动手就够了,而软件工程主要是动脑,总结怎么动手远远不够,需要总结怎么动脑,所以需要哲学数学的基础,岳飞传和原创的区别恰恰在动手和动脑的区别

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-28 01:16 发表


软件工程里算法也不少。软件工程一度认为是只有管理者才需要的、软件工程不直接针对代码、软件工程范畴广泛等等有很多原因。当年相对论也普遍认为是错的，地心说也普遍认为是对的，这又能说明什么？ [/quote]

软件工程里算法的比例肯定比数据库里算法的比例少
这和相对论,地心说有很大区别,很多大师级的著作都有类似看法,我见过不止一本书说当今IT发展越来越偏离它的本,矛头就是UML,设计模式这种软工的东西.

就说个很简单的例子,去让一群不懂网络的人去开发对战平台,就算用软工的敏捷开发,能怎么样?代码都写不出,这才是最大问题.
还有,就算能写出代码,需要开发个十年,而又坚持不了十年怎么办?
如果既能写出代码又不需要太久,才有可能让一群人用软工的方法开发,而这两个恰恰是目前最严重的问题.

[quote]原帖由 [i]陈珺[/i] 于 2010-5-28 01:42 发表
就说个很简单的例子,去让一群不懂网络的人去开发对战平台,就算用软工的敏捷开发,能怎么样?代码都写不出,这才是最大问题.
还有,就算能写出代码,需要开发个十年,而又坚持不了十年怎么办?
如果既能写出代码又不需 ... [/quote]

不懂就去学啊，软件工程又不解决你非不肯学的问题。回去看软件工程的目标再来说话。有几个菜鸟会抱着一本软件工程指望从编程都不会到软件开发高手的？我该说的已经都说了，而且软件工程本来就鼓励在实践中创新的，你既然已经创造或者改进出了更好的方法，那就用呗。你要愿意分享，就说出来给大家看，让大家也跟着你提高，要是不愿意分享，就用在你自己的项目中，老这么空对空的没意思。

[quote]原帖由 [i]Maxwell[/i] 于 2010-5-28 08:15 发表


不懂就去学啊，软件工程又不解决你非不肯学的问题。回去看软件工程的目标再来说话。有几个菜鸟会抱着一本软件工程指望从编程都不会到软件开发高手的？我该说的已经都说了，而且软件工程本来就鼓励在实践中创 ... [/quote]
我只是说明,软件工程解决不了很多实际问题,软件工程使用的前提是团队成员的能力达到要求,可是目前前提不满足,倒是心理学和人力资源管理可以解决团队成员的能力达不到要求,但你又说软件工程在实践中比心理学和人力资源管理更有用,但在这方面我实在看不出怎么更有用了

发个实际问题

[quote]
[b]业余开发失败核心原因探究 [/b]

在三国开发思路(续)已经对这问题有所提及,业余开发失败的原因是能力满足不了所做游戏的要求,也就是说能力是瓶颈.不解决这个问题而采用其它的办法都是治标不治本.用系统科学来看,人之所以能开发是因为知识可以作用于行为,而行为可以作用于物理设备.开发的失败具体原因就在这两个方面,知识可以作用于行为,行为不可以作用于物理设备属于有能力没时间,而知识不可以作用于行为,行为可以作用于物理设备,属于有时间没能力.这是个人开发的情形,对于团队开发,一个成员意图不能被另一个成员理解,即沟通困难,是核心问题.而团队开发的其它问题可以通过有效管理解决.
解决方案是:
对有能力没时间,让其承担交流的角色
对有时间没能力,对其进行培养(培养包括主动接受和被动接受)
对沟通困难,应该培养成员接受统一语言并且尽量通俗易懂,哲学由于其无二义性(前提是学会)最适合作为统一语言并且有实用价值,思维科学由于其面向人脑,最适合为人所理解.
带来的问题是培养问题,包括:
培养需要花费很多时间,可以通过加强沟通能力解决.
培养需要培养者,可以通过选用有能力的作为培养者并且强化其能力
接下来的的问题是被培养者不愿意被培养,原因有
精力不足.这还不算最大的问题
缺乏系统观念,急功近利.这是直接原因.
观念固执,缺乏包容的心态.这是才是根本原因,很多人判断一事物是否有道理是通过说话的人的情况判断,而不是通过内容本身,比如以是否做出游戏判断,这种做法导致很多好的观念无法接受.而缺乏包容导致不能从别人处去长补短,限制了自己的提高.因为观念固执,缺乏包容的心态,才导致了缺乏系统观念,急功近利(因为看问题局部化是通病),根据自身以往的经验解决问题.(但过了三五年,往往又会明白一点,缺没精力了)
懒于思考,这个是性格和习惯问题,要改变非常困难.
经过分析,可以发现观念固执,缺乏包容的心态这个问题非常难解决,因为改变一个人非常困难,这正是业余开发失败的核心原因.那么是什么因素导致呢?
第一,社会风气和环境的影响,现在社会由于压力大,迫使很多人急功近利,而好的观念的接受需要一个过程,因此缺乏基础.
第二,固有观念的影响,很多人长期所受教育学到的是一些局部的分析问题方法,已经形成思维定式,而且由于现在不可靠的东西太多,养成通过说话的人的情况来判断的习惯.
第三,西化的影响.很多人学技术时受到技术背后思想的潜移默化的影响,比如看见的才是对的,而丢掉中国优秀文化,比如系统看问题.很多人工程思想浓厚而忽视思维的作用,片面强调实践,而导致进步缓慢.很多人忽略了学思并重的道理,以重复造车轮为由忽略思考,片面强调学习,结果导致与实践脱节(因为没有和实践联系起来思考),学习能力受制约(因为没有想清问题本质).其实研究自己的思路,正是为了具备能正确运用先人的理论(因为能评价是非,而且不容易陷入教条主义,真正面对实际问题)
[/quote]
这个问题之复杂,恐怕就是用心理学和人力资源管理都难解决

[quote]原帖由 [i]陈珺[/i] 于 2010-5-29 09:34 发表

我只是说明,软件工程解决不了很多实际问题,软件工程使用的前提是团队成员的能力达到要求,可是目前前提不满足,倒是心理学和人力资源管理可以解决团队成员的能力达不到要求,但你又说软件工程在实践中比心理学和 ... [/quote]

你说的话是正确的，你把你说的话里的软件工程换成心理学、人力资源管理等等都是成立的，你的问题在于你没有意识到这一点。软件工程不是用来解决所有问题的，但是软件工程的作用却比着“借鉴”要有用得多。


[quote]原帖由 [i]陈珺[/i] 于 2010-5-29 09:42 发表
业余开发失败核心原因探究

在三国开发思路(续)已经对这问题有所提及,业余开发失败的原因是能力满足不了所做游戏的要求,也就是说能力是瓶颈.不解决这个问题而采用其它的办法都是治标不治本.用系统科学来看,人之所以能开发是因为知识可以作用于行为,而行为可以作用于物理设备.开发的失败具体原因就在这两个方面,知识可以作用于行为,行为不可以作用于物理设备属于有能力没时间,而知识不可以作用于行为,行为可以作用于物理设备,属于有时间没能力.这是个人开发的情形,对于团队开发,一个成员意图不能被另一个成员理解,即沟通困难,是核心问题.而团队开发的其它问题可以通过有效管理解决.
解决方案是:
对有能力没时间,让其承担交流的角色
对有时间没能力,对其进行培养(培养包括主动接受和被动接受)
对沟通困难,应该培养成员接受统一语言并且尽量通俗易懂,哲学由于其无二义性(前提是学会)最适合作为统一语言并且有实用价值,思维科学由于其面向人脑, 最适合为人所理解.
带来的问题是培养问题,包括:
培养需要花费很多时间,可以通过加强沟通能力解决.
培养需要培养者,可以通过选用有能力的作为培养者并且强化其能力
接下来的的问题是被培养者不愿意被培养,原因有
精力不足.这还不算最大的问题
缺乏系统观念,急功近利.这是直接原因.
观念固执,缺乏包容的心态.这是才是根本原因,很多人判断一事物是否有道理是通过说话的人的情况判断,而不是通过内容本身,比如以是否做出游戏判断,这种做法导致很多好的观念无法接受.而缺乏包容导致不能从别人处去长补短,限制了自己的提高.因为观念固执,缺乏包容的心态,才导致了缺乏系统观念,急功近利 (因为看问题局部化是通病),根据自身以往的经验解决问题.(但过了三五年,往往又会明白一点,缺没精力了)
懒于思考,这个是性格和习惯问题,要改变非常困难.
经过分析,可以发现观念固执,缺乏包容的心态这个问题非常难解决,因为改变一个人非常困难,这正是业余开发失败的核心原因.那么是什么因素导致呢?
第一,社会风气和环境的影响,现在社会由于压力大,迫使很多人急功近利,而好的观念的接受需要一个过程,因此缺乏基础.
第二,固有观念的影响,很多人长期所受教育学到的是一些局部的分析问题方法,已经形成思维定式,而且由于现在不可靠的东西太多,养成通过说话的人的情况来判断的习惯.
第三,西化的影响.很多人学技术时受到技术背后思想的潜移默化的影响,比如看见的才是对的,而丢掉中国优秀文化,比如系统看问题.很多人工程思想浓厚而忽视思维的作用,片面强调实践,而导致进步缓慢.很多人忽略了学思并重的道理,以重复造车轮为由忽略思考,片面强调学习,结果导致与实践脱节(因为没有和实践联系起来思考),学习能力受制约(因为没有想清问题本质).其实研究自己的思路,正是为了具备能正确运用先人的理论(因为能评价是非,而且不容易陷入教条主义,真正面对实际问题)[/quote]
我可以替你问个软件工程更没法解决的问题：团队中有个成员不会做饭，快要饿死了，该如何解决？
:lol:跟你开个玩笑。
需要强调的一件事情就是每种学科都有每种学科要解决的问题，你这个问题并不是仅靠软件工程就能解决的，软件工程只能解决其中一部分问题。另外你要清楚我反对的是你软件工程“讲的太浅”、“借鉴”软件工程的思想，而不是反对你使用其它学科。
你讲的解决方案里面虚的东西不少，思路是好的，只是实践起来别人未必按照你的想法去做，就算按照你的想法去做，他需要学习的东西也过多（哲学、转变性格的要求），这样会在解决问题的时候面对更多的问题。
关于业余开发团队，我没有太多经验，只简单说几点跟你提到的问题有关的解决方法，具体的也不展开写了，今天没多少时间，以后会专门有一篇写业余开发团队开发模式的。

1. 控制合理节奏，适应团队的时间安排
2. 通过代码复审进行指导
3. 需求细分，保持持续的成就感
4. 用问题管理系统记录关键信息
5. 有能力时间少的让其负责不紧急的高难度算法
6. 强力领导对关键成员保持联系
7. 编码规范
8. 架构、协议、算法要有文档

至于你所说的培训，我认为我不会明确开展这么一个活动。

[quote]你说的话是正确的，你把你说的话里的软件工程换成心理学、人力资源管理等等都是成立的，你的问题在于你没有意识到这一点。软件工程不是用来解决所有问题的，但是软件工程的作用却比着“借鉴”要有用得多。[/quote]
似乎我从来没说过心理学、人力资源管理用来解决所有问题.
你说软件工程的作用却比着“借鉴”要有用得多,我就不太明白了,其实很多软件工程的书都说了,它也仅仅是提供参考,指导,难道不是借鉴的同义词?

[quote]原帖由 [i]陈珺[/i] 于 2010-5-29 19:45 发表

似乎我从来没说过心理学、人力资源管理用来解决所有问题.
你说软件工程的作用却比着“借鉴”要有用得多,我就不太明白了,其实很多软件工程的书都说了,它也仅仅是提供参考,指导,难道不是借鉴的同义词? [/quote]

呵呵，看看你开始几个回复比你现在说什么都反映你当时的意思。你想怎么说就怎么说了。

[quote]我可以替你问个软件工程更没法解决的问题：团队中有个成员不会做饭，快要饿死了，该如何解决？
跟你开个玩笑。
需要强调的一件事情就是每种学科都有每种学科要解决的问题，你这个问题并不是仅靠软件工程就能解决的，软件工程只能解决其中一部分问题。另外你要清楚我反对的是你软件工程“讲的太浅”、“借鉴”软件工程的思想，而不是反对你使用其它学科。
你讲的解决方案里面虚的东西不少，思路是好的，只是实践起来别人未必按照你的想法去做，就算按照你的想法去做，他需要学习的东西也过多（哲学、转变性格的要求），这样会在解决问题的时候面对更多的问题。
关于业余开发团队，我没有太多经验，只简单说几点跟你提到的问题有关的解决方法，具体的也不展开写了，今天没多少时间，以后会专门有一篇写业余开发团队开发模式的。[/quote]
我当然知道在解决问题的时候面对更多的问题,所以我长期不搞团队而是单干,问题就在前提不具备
我说的核心问题是普遍存在,微软的操作系统老延期都跟这个原因有一定关系,只不过商业开发持续时间更长在一定程度缓解这个问题而已
所以我更倾向用技术方法来解决开发问题就在此,关键就在于目前的实际情况不适合搞团队