原帖由 Maxwell 于 2010-5-23 10:54 发表
通过适当的组织，可以将大工作量的项目在尽量不影响个人生活的情况下通过增加团队人数和拉长制作周期的方式完成。轩辕春秋版的岳飞传在业余团队的组织上是一个成功的例子，但是我个人认为它的成功不可复制到正向 ...

原帖由 numdisp 于 2010-5-23 09:12 发表
看了一下楼主的开发史，值得学习。不过楼主三国之家里的“思维科学”看起来好玄乎，太哲学了，有些难以理解

原帖由 陈珺 于 2010-5-23 11:32 发表

管理也是技术之一,同样需要研究和学习,而且难度不亚于技术

还有软件工程讲的太浅,不足以指导开发,倒是心理学得好好学,否则协调人的问题很难解决

原帖由 Maxwell 于 2010-5-23 11:49 发表


讲得太浅是指。。。？软件工程的发展虽然没有解决所有问题，但是对于提高国内开发团队的开发水平还是绰绰有余的。

原帖由 陈珺 于 2010-5-23 12:09 发表

就我上面说的,人协调的问题就没解决好,毕竟软件工程一本装不下那么多心理学

原帖由 Maxwell 于 2010-5-23 12:15 发表


没解决好也比没解决要好得多，一本书装不下可以有多本，软件工程这些年的发展并不是简单重复多年前的观点。其实软件工程无用论在国内还是挺流行的，结果就是自己在低水平徘徊。

原帖由 陈珺 于 2010-5-23 12:36 发表

软工还是有好书,只不过能读懂的恐怕没几个
http://www.china-pub.com/49090
http://www.china-pub.com/49263&ref=xilie
http://www.china-pub.com/49264&ref=xilie
这些是比较新的发展了

原帖由 Maxwell 于 2010-5-23 12:44 发表



有研究编程的劲头何愁看不懂软件工程？近年来各种轻量级软件工程方法也有较大的发展，比如各种敏捷方法，这些方法都很注重实践且易于执行。

原帖由 陈珺 于 2010-5-23 12:49 发表

你试试读懂上面那三本

原帖由 Maxwell 于 2010-5-23 13:31 发表


我读懂问题不大，但是我读懂了对你基本没有什么用处吧。这三本就代表软件工程的全部了？那么多轻量级方法就被你无视了？
你非要造出太空堡垒来才会打仗吗？跟前有AK47就看不上眼？非得赤手空拳到太空堡垒造 ...

原帖由 陈珺 于 2010-5-23 20:28 发表

软件工程跟孙子兵法一个性质,兵书而已,但真正上战场光靠孙子兵法远远不够,实际的战争要比孙子兵法上复杂的多

实际上,即使是公司,团队合作失败率同样很高,合作成功的往往有很大的运气成份

原帖由 Maxwell 于 2010-5-23 20:42 发表


且当软件工程跟孙子兵法一个性质吧，那么懂兵法的人和不懂兵法的人上战场哪个打胜仗的机会更大呢？

软件项目失败率高正是软件工程试图解决的问题，虽说现在还看不到完全解决问题的希望，可是你是在坚持造 ...

原帖由 陈珺 于 2010-5-23 20:59 发表

关键是比软件工程更好的兵书已经很多了,为什么不选更好的兵书呢

原帖由 numdisp 于 2010-5-24 03:58 发表
我看上面两位不必为了上面“兵书”的问题太过执着。理论与实践本来就是相辅相成，相互促进的东西。两者其实并无先后顺序与孰轻孰重的关系，也不存在“最好的理论”这样的问题。

不过看到楼主的一些历程，我倒 ...

原帖由 Maxwell 于 2010-5-23 21:03 发表


比如说？

原帖由 陈珺 于 2010-5-24 20:32 发表

既然你提团队合作,那么更直接针对这个问题的应该是心理学和人力资源管理.
软件工程包括软件开发方法学和软件项目管理,软件开发方法学不管是否需要团队合作都是需要掌握的,与团队合作关系不大,而软件项目管理 ...

原帖由 Maxwell 于 2010-5-24 09:17 发表
你说的是一部分研究机构做的事情，实际上更影响IT业发展的是无视理论。种种XXX无用论的论调比着一定要把XXX研究透的想法可是流行得多。看看现在中小企业的开发水平还有业余开发社区的水平就知道了。现在还真是缺 ...

原帖由 陈珺 于 2010-5-24 20:38 发表
虽然不一定需要太空堡垒来打仗,但是拿个破枪打仗,打败的概率很高
所以关键还是先要判断所拥有的枪是否适合打仗,网络合作的背后是现实的社会环境,没有些基本的了解,在计划,沟通,协调都是非常困难的

原帖由 陈珺 于 2010-5-24 20:45 发表

这个其实跟国家环境有很大关系,很多人温饱都成问题,所以没有必要精力去关注理论,而认识理论的重要性本身就需要静下心去慢慢体会,而现在连静下心的前题都没有

原帖由 Maxwell 于 2010-5-24 20:42 发表


照你这么讲所有叫作XX工程的学科都可以不要了，只需要开技术课程外加心理学和人力资源管理就可以了？软件工程里面很大一部分内容就是讲如何协作的，而且大部分流行的软件工程方法都是经过实践检验的，不知道 ...

原帖由 Maxwell 于 2010-5-24 20:51 发表


软件工程理论是指导实践的，非要放着前人积累的经验不用，自己去摸索一套，岂不是更增加满足温饱的难度？软件工程中纯理论研究少之又少，轻量级的方法论倒是有很多，很难想象连轻量级方法论都没有精力去学习 ...

原帖由 陈珺 于 2010-5-24 20:57 发表

从现代管理学的角度,工程这种做法的确有很多问题,工程的思路其实已经是几十年前的,现代管理理念的是流程再造,工作轮换等等
不过也不是说软件工程的学科都可以不要,关键问题是软件工程理论研究者思路出了问题 ...

原帖由 Maxwell 于 2010-5-24 21:03 发表


终于明白了，合着你一句话就把软件工程最近几十年的发展给否定了，那就难怪你得出这种结论了。

原帖由 陈珺 于 2010-5-24 21:15 发表

人工智能也发展几十年了,但它的确有很大毛病,难道不该否定?
我既然说借鉴就不是完全否定.

原帖由 陈珺 于 2010-5-24 21:11 发表
我可没说赤手空拳去打仗,而是说换个好点的兵器
至于纯理论,离散数学应该就是纯理论,但它的作用不需要质疑吧,很多时侯纯理论往往能开阔思路,而应用理论只不过是教你怎么把纯理论与实际问题结合起来,比如数据结构 ...

原帖由 Maxwell 于 2010-5-24 22:14 发表


我记得我前几年发过一个帖子是说学与用脱节的事情，从你的描述还是看到了这个现象，可能也是因为这个原因，会让你看不上软件工程。

原帖由 Maxwell 于 2010-5-24 22:02 发表


我说你否定了软件工程最近几十年的发展，也就是说你观念中的软件工程是几十年前的软件工程，不是现在的软件工程。

原帖由 陈珺 于 2010-5-24 22:37 发表

那你就是很大的误解,事实上恰好相反,我能用操作系统解释日常生活中各种管理问题,能用生产管理学解释软件工程的思想,这种学以致用如果还是学与用脱节,那别的更是脱节
要知道,高级语言设计的再好最终都要转成机 ...

原帖由 陈珺 于 2010-5-24 22:41 发表

那你说说有什么重大成果,据我了解敏捷开发之类的还是从生产管理学里弄过来的,还有很多思想,比如流程再造,内部客户,还没来得及弄

原帖由 陈珺 于 2010-5-24 22:49 发表
再说一句,很多人只是简单的说理论要与实践结合,那么怎么结合?为什么不会深入思考这个问题,而往往满足"理论要与实践结合",对于深入思考这个问题的观点,往往又以浅显的"理论要与实践结合"观点去评价它,那不就是喜欢浅显的观点而排斥深入的观点?

你能不能用软件工程方法指导软件开发才是主要的。能用管理学指导日常生活的管理，能用操作系统原理指导操作系统开发，能用生产管理学指导生产才算学以致用，当然只是能解释也已经不易了，保守估计最近一级的本科毕业生至少一半做不到这一点。

那看来在你眼里软件工程就是一门阐述“理论要与实践结合”的学科而不是一个指导实践的学科了？

原帖由 陈珺 于 2010-5-24 23:58 发表
测试驱动、持续集成基本是从全面质量保证弄来的
快速迭代是从并行工程弄来的
集体代码所有权也是从全面质量保证弄来的

原帖由 陈珺 于 2010-5-25 00:06 发表

指导实践不难,关键是难处理兵书上没提到的问题

心理学和人力资源管理已经覆盖了实践中所有问题？

原帖由 陈珺 于 2010-5-25 00:11 发表

可以指导实践,但指导的程度不够,而且一些方法存在问题
更关键的是有点呆板,缺乏应变能力
还有对人的培养这方面比较欠缺,似乎停留在利用现有能力的层面

原帖由 Maxwell 于 2010-5-25 00:26 发表

软件工程中哪些方法是指导的程度不如心理学和人力资源管理的？
在各种项目中恐怕很少有像软件项目这样需求变化迅速多样的了，为了解决软件项目的开发问题而生的软件工程学的应变能力也不会次于其它工程学，尤 ...

原帖由 陈珺 于 2010-5-25 00:19 发表
全面质量管理的基本思想:
全面的质量概念
全过程质量管理
全员参与的质量管理
全企业质量管理
运用一切现代管理技术和管理方法
1、顾客至上
            以顾客为中心，明确顾客的需求，并贯穿于整个管理 ...

原帖由 陈珺 于 2010-5-25 00:22 发表
产品设计的新方法——并行工程
       并行工程是对产品设计及其相关过程包括制造过程和支持过程进行并行、一体化设计的一种系统化的工作模式。

       这种工作模式力图使开发者从设计一开始就考虑产品在生 ...

原帖由 陈珺 于 2010-5-25 00:35 发表

呆板是指它只能知其然,而不知所以然,而管理学是能知所以然,这样才不会生搬硬套,软工实践最大问题恰恰是生搬硬套.
软工的确有关注人的心理,但还是不知所以然
比如说知觉的选择性,注意的浮动,性格的影响,还有 ...

原帖由 Maxwell 于 2010-5-25 00:38 发表




你不如再抽象一点说一切都是从哲学来的。就算这几个实践牵强附会能够从管理学理论而来，这又能说明什么？说明这些实践实际上不可行？还是说明这些实践不如根据非软件工程理论自创的实践？

原帖由 Maxwell 于 2010-5-25 00:51 发表

那请问你了解了“知觉的选择性,注意的浮动,性格的影响”的所以然之后对软件项目开发实践产生了哪些影响？产生的这些影响对生产率的提高是否超过了或者有潜力超过现有软件工程方法对软件项目生产率的提高？

原帖由 陈珺 于 2010-5-25 00:52 发表

就说预防为主,软工提倡这么多测试,为什么不从预防下功夫,生产管理学甚至提倡产品免检,而到软工里变成测试与设计并重
还有并行工程讲究价值分析,一个个分析是否创造价值,没有的舍掉,甚至还有通过排序来提高效率,软工有这么细致分析吗

原帖由 陈珺 于 2010-5-25 01:00 发表

比如为什么长时间劳动以后生产率下降就可以用注意的浮动解释,实践就要注重安排休息,或者安排提高注意力的项目
还有引发低级错误,就可以分析是语言的哪个特性引发的,然后可以通过改变编码习惯避免
知觉的选择性就影响学习和沟通,比如某些信息不容易引起注意,所以沟通时就需要强化

原帖由 Maxwell 于 2010-5-25 01:02 发表

那请问你在心理学和人力资源管理的指导下，会采用何种方法来做到预防为主并且有效减少测试的？
软件工程中哪种方法不是分析需求并优先实现最有价值的需求的？进一步说有哪一门神经正常的学科不是这么做事的？ ...

原帖由 Maxwell 于 2010-5-25 01:13 发表

你这还是理论啊，怎么算注重安排休息？几个小时休息一次？一次多久？哪些是提高注意力的项目？如何在实践中避免低级错误重复出现？哪些信息是不容易引起注意的？如何强化？
你这不过还是在强调“理论要与实践 ...

原帖由 陈珺 于 2010-5-25 01:16 发表

做到预防为主就不是纯心理学和人力资源管理问题了,跟计算机技术关系很密切,心理学所能解决的是把握人的思维规律,真正做到预防为主靠的是系统设计阶段把问题分析清,生产管理学毕竟对象范围广,只是说到往免检方 ...

原帖由 陈珺 于 2010-5-25 01:23 发表

只是说明对实践有影响,如果要系统的实施,那得有计算机方面的知识,我说的心理学这些都是在有计算机方面的知识基础上才能落到实处

原帖由 Maxwell 于 2010-5-25 01:24 发表


那么心理学和人力资源管理对软件开发的具体指导在什么地方？指导系统设计阶段的又是什么理论？

原帖由 Maxwell 于 2010-5-25 01:30 发表

那么对实践的影响又在何处？这些影响与单纯应用软件工程产生了哪些差别？

原帖由 陈珺 于 2010-5-25 01:37 发表

就说分工问题吧,有的人擅长算法,有的人擅长优化,这些需要计算机知识的参与
有的人认真,有的人三心二意,有的人喜欢广度,有的人喜欢深度,这些需要心理学的参与
然后以此安排任务,缺人时按心理学规律培养,出错 ...

原帖由 陈珺 于 2010-5-25 01:46 发表

最大的差别,就是不会那么呆板,可以根据具体项目和组织情况设计流程,安排人事,而不像软工那么死的需求分析,概要设计等等,还有就是通过沟通发现知识欠缺,及时弥补,注重开发成员的思维规律,而不是靠一堆规章制度 ...

原帖由 Maxwell 于 2010-5-25 01:50 发表


软件工程中不讲分工问题吗？软件工程中对资源的调配还包括了更广泛的内容，恐怕是心理学覆盖不到的吧？软件工程所覆盖的内容是远超你想象的，即使你能够从管理学、心理学、人力资源管理等等学科中总结出一些 ...

呆板的是人不是软件工程。你灵活一个先概要设计后需求分析看看？不靠规章制度是管理学教你的？

原帖由 陈珺 于 2010-5-25 01:58 发表

软件工程有根据言语和代码分析应该补什么的内容吗

原帖由 Maxwell 于 2010-5-25 02:12 发表

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


突然想起个问题来，你 ...

原帖由 陈珺 于 2010-5-25 02:23 发表

我以前读的二十年前的软件工程书,针对个人的、针对团队的直到针对公司的几乎没有,有也只是一带而过
倒是有本IT项目管理花了一章的篇幅讲了,但深度和人力资源管理差远了

原帖由 陈珺 于 2010-5-25 02:31 发表
我拿三册书是说明软件工程的方向应该是那本书那样,而不是目前的UML,设计模式之类的东西

原帖由 Maxwell 于 2010-5-25 02:29 发表

我倒是好奇人力资源管理里面的深度到软件开发上还剩多少，它不会在实践中遇到问题吗？在人力资源管理的指导下，你现在是如何做的？

原帖由 Maxwell 于 2010-5-25 02:39 发表

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

原帖由 陈珺 于 2010-5-25 02:50 发表


你说的是它的目标,但从现有软件工程成果看,方向差得很远,开发软件的主体是人,心理学肯定必要,然后需要用哲学和数学指导计算机资源的应用,最后用管理学来指导怎么合作,那三卷书在用哲学和数学指导计算机资源 ...

原帖由 陈珺 于 2010-5-25 02:40 发表

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

原帖由 Maxwell 于 2010-5-26 09:35 发表

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

原帖由 陈珺 于 2010-5-26 22:55 发表

你倒是说说我哪没搞清楚软件工程了
我也可以说三国开发工程比软件工程更贴近实际

原帖由 Maxwell 于 2010-5-26 10:08 发表


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

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

原帖由 Maxwell 于 2010-5-26 22:58 发表

我支持你继续持有此观点。

原帖由 陈珺 于 2010-5-26 22:59 发表

按你的意思,数据结构在理论上可能不如离散数学深入,但在实践上可是更贴近实际编程的?

原帖由 陈珺 于 2010-5-26 23:04 发表

嗯,支持一门有表无实的学科

原帖由 Maxwell 于 2010-5-26 23:11 发表

数据结构理论不够深入吗？数据结构有一部分内容是离散数学在计算机上的应用，一个理论一个应用，怎么比较？关公战秦琼？

原帖由 Maxwell 于 2010-5-26 23:15 发表


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

原帖由 陈珺 于 2010-5-26 23:19 发表

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

原帖由 Maxwell 于 2010-5-26 23:35 发表


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

原帖由 陈珺 于 2010-5-26 23:46 发表

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

原帖由 Maxwell 于 2010-5-27 00:02 发表


我很难想象如何做到写一个超过100行的程序而不用到数据结构，但是还没遇到过非得去翻离散数学的情况。只学过数据结构去设计算法确实很头疼，但是应该去学算法课而不是离散数学。确实，我见过不少绞尽脑汁设 ...

你貌似是无视各种实践中容易用到的计算机学科，没有困难创造困难也要上吗？

原帖由 陈珺 于 2010-5-27 00:12 发表

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

原帖由 Maxwell 于 2010-5-27 00:35 发表


看你前面的讨论，应该是很有实际开发经验的吧，那么要不你找个用不到数据结构的程序的例子来给我长长见识。要是没系统学过计算机科学，学学离散数学倒是有益的，不过说非得先学离散数学再学算法倒是不一定。 ...

原帖由 陈珺 于 2010-5-27 00:25 发表

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

原帖由 Maxwell 于 2010-5-27 00:42 发表

我倒是奇怪了，抽象的管理学和具体软件工程学，你实际使用的方法会更贴近哪一个？是应用抽象的借鉴具体的还是应用具体的借鉴抽象的？管理学你能结合实际应用到实践中，软件工程学就不会灵活运用了？这还是我说 ...

原帖由 陈珺 于 2010-5-27 00:42 发表

看你怎么定义数据结构了,如果基本数据类型,结构体,数组都算的话,那还真拿不出(不过用这些不需要学数据结构)
没有讨论过的话题怎么灵活运用,离散不学平面图,你倒是灵活运用下去判断一个图是不是平面图

原帖由 陈珺 于 2010-5-27 00:49 发表

你说基础数学容易出问题,还是应用数学容易出问题?如果用一个有问题的理论出了问题怎么办,关键问题不是用,而是用的后果.我发现现在很多敷衍了事的做法也被称为灵活运用了.

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

为什么数据结构里有别处也有的东西可以不学数据结构就能学会，离散数学里有数据结构里也有的就非得学离散数学、软件工程里有其它学科也有的就得学其它学科？你的逻辑不混乱吗？
另外，你上次用到平面图或者你预期下次用到平面图是什么时候？你要不要为了使用堆、栈、树就把图论、群论、集合论……全部学完？学离散数学还要有前置课程，照你这样要学到什么时候才能开始学习大部分时候真正需要的数据结构？感觉你在度的把握上偏差太大了。

原帖由 陈珺 于 2010-5-27 23:35 发表

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

你学离散数学的时候自己证明过相关的定理吗？要是出了问题怎么办？后果多严重啊，不光离散数学是错的了，连数据结构也白学了，你学离散数学的时候没有这样的担心吗？如果没有，是不是敷衍了事呢？

原帖由 Maxwell 于 2010-5-27 23:40 发表


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

可能变和可能不变是你判断成熟不成熟的依据吗？应不应该应用软件工程应该看应用后是否比应用前更容易使软件项目成功，而不是一个空口说的成熟还是稚嫩。另外，也许你需要考虑一下为什么在软件开发中很多项目都使用了或者声称使用了各种软件工程方法，而甚少使用或者声称使用了你所谓的成熟的理论呢？全球IT民工皆醉你独醒吗？当然，如果你的目标是创立一门更能提高软件开发的学科你的观点也许没有问题，但是如果你的目标只是提高项目成功率，我实在不看好你仅“借鉴”软件工程的观点。

原帖由 陈珺 于 2010-5-27 23:42 发表

我主贴就说了,学东西学到可以解决实际问题就可以收手,关键是软件工程根本不足以解决实际问题,用软件工程做的项目BUG还是巨多.
总不能解决不了实际问题,还死抱着软件工程去灵活运用吧,那和自创一套理论有何区 ...

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

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

你就凭着看过的软件工程的只言片语当然不足以解决问题。别人能用软件工程提高项目质量你却不行，你应该找自己的原因。

那看来你要组织一个团队得需要一群心理专家才行，要不然沟通居然会有问题。
你看到很多表达要通俗认真倾听之类的废话多是你选的书不行，如果缺乏基本的判断能力，恐怕学什么学都白搭。
但是在软件工程里面，沟通是通过文档、规范、UML、CRC卡片等各种手段来保证沟通的，对心理专家来说，这些可能都太难理解了，毕竟这都是针对软件开发人员设计的。

原帖由 陈珺 于 2010-5-27 23:58 发表

我前面就说了,IT业项目失败率很高,或者说成功也是以高成本,低质量,低效率为代价的,算不上真正成功.
先不说我的理论,就是那三册书也没什么人用,那是不是说那三册书的理论也不实用呢?
软工解决不了很多实际问题,所以才会导致项目失败率很高,而实际问题总得解决怎么办?赤手空拳?
借鉴的含义你还是不明白,原理讲清楚并且能解决实际问题的都可以去接受,但软件工程有几个理论做到了?

原帖由 陈珺 于 2010-5-28 00:08 发表
这是一个搞AI的说的,我发现这种遇到问题不是从它本质去分析而是直接用XX理论然后冥思苦想半天的人多的是,你就是想单靠软件工程和灵活应用解决所有开发问题吧

原帖由 陈珺 于 2010-5-28 00:16 发表
的确可以提高项目质量,可是提高项目质量是以大量劳动为代价的,明明别的理论效果更好,何苦要抱着软件工程不放?
不是说不可以提高项目质量,而是(1)提高的太有限,根本满足不了要求;(2)不讲原理,容易产生教条主义 ...

原帖由 陈珺 于 2010-5-28 00:24 发表
我记得有本书就批评UML越来越乱了,现在的关键问题是文档、规范、UML、CRC都只是形式,怎么用呢,我看过一本讲怎么用的书,它说找对象就是把它上面的几类都以"宁可错杀,不可漏网"的方式网罗进来,然后再 ...

你妄下的论断太多了。

通过你对软件工程的描述，你的借鉴的含义就是说软件工程不是彻底的无用而已。我跟你讨论这些，无非是想告诉你软件工程里的学问已经够你学一阵的了，暂时不看好你能发明出什么比现有方法更有效的方法来。大部分人的创新都是站在前人成果的基础上的，只有民科们才能凭空创造各种“更好”的理论。当然，我也无非就是随便说说，你也就随便听听而已。

哪种理论跟实践没有差距？你那些非软件工程学科手把手教你面对什么问题时要怎么解决了？那得多厚一本，国家图书馆放得下不？软件工程中有些方法就是很呆板的，那是有它的道理的，等你以后做项目慢慢体会吧。

原帖由 陈珺 于 2010-5-28 00:43 发表

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

说了这么多,你还认为我完全独创,从谈话中可以看出,你对我的认识还处于前几年的水平,实际上,我现在大部分时间在看书,而不是冥思苦想,只不过不能完全看软件工程的书,从我的体会看 ...

我只是告诉你软件工程有用，至于我怎么用那是我的问题。
你对工程的理解还是有问题，软件工程的目标我前面回帖说过，不再多说。在既定目标下使用成熟算法或者复用代码一点问题都没有，有限的资源要有重点地使用，只有菜鸟才会想着处处创新

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

原帖由 陈珺 于 2010-5-28 01:02 发表
也许我得到的成果的确属于软件工程范畴,但这些成果是参考了大量学科(可能也借鉴过软件工程),那这是不是也牵强附会成是用软件工程呢?
我知道几个世纪前有大成的科学家都懂哲学,钱学森也懂哲学,所以他们视野开阔,容易有成就,倒是现在实用主义多了,把这些基础抛弃了,结果项目出了问题. 项目开发本身就是创造过程,一个应用者的思路,能解决的问题终究有限

原帖由 Maxwell 于 2010-5-28 00:59 发表

我没有认为你几年前水平低，也没有认为你现在水平高，我的判断只是依据你说软件工程讲得太浅不足以指导开发、要借鉴软件工程等言论。每种理论都是理解之后根据实际情况灵活应用，数据库也不例外，拿个常用的例 ...

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

原帖由 陈珺 于 2010-5-28 01:08 发表

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

要是所有人都像科学家一样工作，呵呵。。。科学家和工程师应该用相同的方法工作？但是你的志向要是在理论突破上，那就没有问题了。

原帖由 Maxwell 于 2010-5-28 01:16 发表


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

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

原帖由 Maxwell 于 2010-5-28 08:15 发表


不懂就去学啊，软件工程又不解决你非不肯学的问题。回去看软件工程的目标再来说话。有几个菜鸟会抱着一本软件工程指望从编程都不会到软件开发高手的？我该说的已经都说了，而且软件工程本来就鼓励在实践中创 ...

业余开发失败核心原因探究

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

原帖由 陈珺 于 2010-5-29 09:34 发表

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

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

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

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

原帖由 陈珺 于 2010-5-29 19:45 发表

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

我可以替你问个软件工程更没法解决的问题：团队中有个成员不会做饭，快要饿死了，该如何解决？
跟你开个玩笑。
需要强调的一件事情就是每种学科都有每种学科要解决的问题，你这个问题并不是仅靠软件工程就能解决的，软件工程只能解决其中一部分问题。另外你要清楚我反对的是你软件工程“讲的太浅”、“借鉴”软件工程的思想，而不是反对你使用其它学科。
你讲的解决方案里面虚的东西不少，思路是好的，只是实践起来别人未必按照你的想法去做，就算按照你的想法去做，他需要学习的东西也过多（哲学、转变性格的要求），这样会在解决问题的时候面对更多的问题。
关于业余开发团队，我没有太多经验，只简单说几点跟你提到的问题有关的解决方法，具体的也不展开写了，今天没多少时间，以后会专门有一篇写业余开发团队开发模式的。

原帖由 陈珺 于 2010-5-29 20:12 发表

我当然知道在解决问题的时候面对更多的问题,所以我长期不搞团队而是单干,问题就在前提不具备
我说的核心问题是普遍存在,微软的操作系统老延期都跟这个原因有一定关系,只不过商业开发持续时间更长在一定程度缓 ...

原帖由 Maxwell 于 2010-5-29 20:19 发表


量力而行是好事，但是我并不认为技术上弱就一定不行，技术上的差距工程可以弥补一部分。现在业余开发团队的技术已经基本具备组成团队的能力，做个大项目很难，做个小项目有希望。

原帖由 陈珺 于 2010-5-29 20:38 发表

主贴你还是没认真看,要是做小项目我一个人就够了(再加美工),何必动用团队,之前的经验表明,对小项目,一个人比搞团队效果要好
原理就类似写简单程序用汇编更高效

原帖由 Maxwell 于 2010-5-29 20:45 发表

我大致上把3-10万行代码的归为小项目。我做项目的目的是探索团队开发，为了单纯写个软件出来，何苦到网上组团队。

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

原帖由 陈珺 于 2010-5-29 20:50 发表

探索团队开发的目的何在呢?不是为了做更大的项目吗?

原帖由 陈珺 于 2010-5-29 20:54 发表

记得有个项目经理说过,软件工程要在大公司实行才比较有效
当然如果运气够好,业余团队也能实行,但这风险多大啊

原帖由 Maxwell 于 2010-5-29 21:17 发表

做大项目更需要软件工程了。通过小项目得到软件工程经验，可以提高大项目的成功率，你这么一说，确实应用软件工程有这么个好处。



我还记得有人说软件工程太浅，不足以指导开发呢，这又有个说在大公司能 ...

做大项目更需要软件工程了。通过小项目得到软件工程经验，可以提高大项目的成功率，你这么一说，确实应用软件工程有这么个好处。

原帖由 陈珺 于 2010-5-29 22:13 发表

我想知道组队的最终目的是什么,软件工程顶多是工具

我还是想知道软件工程的作用除了“借鉴”还有什么,难道可以直接用?

原帖由 Maxwell 于 2010-5-29 22:42 发表



按你的观点有什么不是“借鉴”的？

原帖由 陈珺 于 2010-5-29 22:48 发表

起码数学和哲学不是
我的理解学习是接受大部分,而借鉴是经过思考有选择的接受

原帖由 陈珺 于 2010-5-30 04:38 发表
第一篇 基础篇
第一章 系统科学与数学
1.1 系统
1.2 信息
1.3 整体与部分
1.4 一般与特殊
1.5 随机
1.6 图论
1.7 集合论
1.8 代数
1.9 概率论
第二章 管理科学与数学
2.1 管理与目标
2.2 计划与执 ...

原帖由 Maxwell 于 2010-5-30 09:38 发表


你词典里借鉴是这个意思我也没办法，不过对你学习数学和哲学不思考深表同情。

原帖由 Maxwell 于 2010-5-30 09:42 发表


好歹比你推崇的管理学、心理学、思维科学目录长点儿。。。另外，怎么也没见你说借鉴这几门呢？都说的学习，这不仍然证明了你认为软件工程不行？

原帖由 陈珺 于 2010-5-31 00:27 发表

我感觉很多地方你都有误会
学什么都需要思考

原帖由 陈珺 于 2010-5-31 00:38 发表

因为我发现软件工程和这里面一些理论有矛盾,而且这些理论讲道理,你如果看了,说不定也会怀疑软工,我怀疑软工不是没事看不上它,恰恰是各方面书看多了,发现问题

你的逻辑和表达很难不让人“误会”。你要是看了软件工程并且思考了，就不会有这么多“误会”了。软件工程就看了二十年前的书就来妄谈“借鉴”，你自己的逻辑站得住脚吗？且不说软件工程实际上有用没有，从你得出结论的逻辑来看就有问题。

原帖由 陈珺 于 2010-6-1 00:45 发表

我倒是觉得,我很多话你都是跳着看,所以才会“误会”
UML,OO,设计模式是二十年前的书里的吗
其实我之前已经表达过一个意思,现在的软工恐怕还不如二十年前的

原帖由 Maxwell 于 2010-6-1 07:42 发表


这下彻底没误会了，你已经明确说软件工程不行了。

原帖由 陈珺 于 2010-6-2 01:46 发表

现在有个普遍问题是泛泛而谈,我觉得你就有这种迹象
你用这么概括性的语言,怎么能讨论下去呢
如果你真的想说明软件工程怎么有用,就说具体能解决什么问题,这样的讨论才有帮助

原帖由 Maxwell 于 2010-6-2 08:01 发表


我现在要谈的无非是你在本帖是不是认为软件工程不行，对于这个问题我谈的够具体了，论点论据都有，还要怎么个具体法？我不想说明软件工程怎么有用，我没义务替软件工程做宣传。
另，如果发现了一个普遍问题 ...

原帖由 陈珺 于 2010-6-3 02:32 发表

你的论点大概就是软件工程足以提高软件开发水平,而论据就是代码集体所有权之类的.但这对于说明你那观点实在太不够了.你可以说说哪些理论可以解决哪些问题啊,列出来就行.
你既然要推荐软工,就要引一条路,而不是类似"软工就够你学了"的观点,人的时间有限,不可能花这么大精力钻到一个很可能没有多大价值的东西去吧,你应该说说哪些理论有价值,改变我的认知,而不是一味的让我去看.而且我对软工也不是一无所知.

原帖由 Maxwell 于 2010-6-3 07:58 发表


你仔细看我说的是什么，我的论点是你认为软件工程不行，我的论据是你说过的话。我最多是帮你认识到你认为软件工程不行，可没义务替软件工程费劲扭转别人的认知。

通过适当的组织，可以将大工作量的项目在尽量不影响个人生活的情况下通过增加团队人数和拉长制作周期的方式完成。轩辕春秋版的岳飞传在业余团队的组织上是一个成功的例子，但是我个人认为它的成功不可复制到正向开发上，因为岳飞传的技术难度大、工作枯燥的编码工作非常少，而且投入产出比比正向开发要高得多。

个人认为，要解决业余团队的正向开发必然需要软件工程的支持，尤其是开发人员工作时间无法保证，开发能力参差不齐的情况下。

原帖由 陈珺 于 2010-6-3 22:50 发表

你最初说的可是这个


那么,那个论点目的在哪呢?告诉我软件工程可以?

原帖由 Maxwell 于 2010-6-3 23:02 发表


那是你没有说软件工程不行之前，你既然认为软件工程不行，那就没有讨论那个话题的必要了。

原帖由 陈珺 于 2010-6-3 23:12 发表

那你提这个论点的目的呢?

原帖由 Maxwell 于 2010-6-3 23:41 发表


论点。。。这里是辩论赛吗？

你仔细看我说的是什么，我的论点是你认为软件工程不行，我的论据是你说过的话。我最多是帮你认识到你认为软件工程不行，可没义务替软件工程费劲扭转别人的认知。

原帖由 Maxwell 于 2010-6-3 23:53 发表
这有什么矛盾吗？很明显的事情，开始的方向是讨论开发，后来你言论中表达出软件工程不行但是你又不承认你是这个意思，所以后来的方向就转向辩论了。

原帖由 陈珺 于 2010-6-3 23:57 发表

我一直忽略了一个问题
你的"不行"是什么意思

原帖由 Maxwell 于 2010-6-4 00:09 发表

自己的发言这么快就不记得了吗？
只从第一页看就有“太浅”、“不足以指导开发”、指导软件开发“比软件工程更好的兵书已经很多了”、“所提供的方法远远不足以解决实际问题”、“软件工程理论研究者思路出了 ...

原帖由 陈珺 于 2010-6-4 00:17 发表

我感觉你的"不行"有全盘否定的意思

原帖由 Maxwell 于 2010-6-4 00:22 发表


我说的无非是指代你的诸多言论，我总不能每次把你各种言论都照抄一遍，光第一页上就够多了。至于是全盘否定还是可以“借鉴”不是我说行还是不行能影响的了的，看了你的发言的人会有自己的判断。

原帖由 陈珺 于 2010-6-4 00:31 发表

"不行"成指代了?那你这句话不能按常规理解
不过既然是指代,怎么又说"没什么好说的"
到底是指代还是结论?

那是你没有说软件工程不行之前，你既然认为软件工程不行

原帖由 Maxwell 于 2010-6-4 00:46 发表

前面就说了你学那么多学科不如先学学逻辑。

举例说明

前面一个“不行”指代你的言论，后面一个“不行”是对你的言论的总结，“不行”在词典中的解释有“不成功，不中用”的意思，你可以对照你说的看看我 ...

这下彻底没误会了，你已经明确说软件工程不行了。

原帖由 陈珺 于 2010-6-4 03:28 发表


这个不行属对言论的总结吧?

讲得太浅是指。。。？软件工程的发展虽然没有解决所有问题，但是对于提高国内开发团队的开发水平还是绰绰有余的。

原帖由 陈珺 于 2010-6-6 03:01 发表
我觉得你的逻辑也有问题,我一直都是在回答你这个问题吧

原帖由 Maxwell 于 2010-6-6 09:05 发表

你的回答不就是软件工程不行吗？最多是可以“借鉴”一下。

原帖由 陈珺 于 2010-6-6 23:44 发表

我说那么多,全被你"不行"概括了,不能具体点吗

原帖由 Maxwell 于 2010-6-7 15:06 发表


150楼的不够具体？那我再给你具体点：
“太浅”、“不足以指导开发”、“比软件工程更好的兵书已经很多了”、“所提供的方法远远不足以解决实际问题”、“软件工程理论研究者思路出了问题”、“这样的学科 ...

原帖由 陈珺 于 2010-6-7 22:24 发表

不是我不够具体,是你不够具体
这么多具体问题,你都笼统回答

原帖由 Maxwell 于 2010-6-7 22:55 发表


这叫问题？这些是你对软件工程所发表的言论，你对软件工程的观点已经表达的很清楚了。我对你的这些观点的总结就是你认为软件工程不行、无用、最多就是可以“借鉴”，你无非就是不愿意承认这个总结而已。这些 ...

原帖由 Maxwell 于 2010-6-7 23:06 发表
还有必要再讨论你认为软件工程中分别哪些部分不行吗？看看你以往的发言就可以知道了，你已经下了定论了。比软件工程好的理论你都知道了，何苦抱着软件工程不放呢？何苦非要辩解自己没有说过软件工程无用呢？你本 ...

原帖由 陈珺 于 2010-6-7 23:12 发表

到底是不是不行无所谓
我说的是哪里不行,这才是关键

“太浅”、“不足以指导开发”、“比软件工程更好的兵书已经很多了”、“所提供的方法远远不足以解决实际问题”、“软件工程理论研究者思路出了问题”、“这样的学科就只能借鉴参考”、“管理学……比软件工程更全面更深入,用管理学不是更好?”、“我既然说借鉴就不是完全否定”、“一门有表无实的学科”、“对于软工这种还在萌芽期的理论,如果去用,恐怕很容易出问题”、“关键是软件工程根本不足以解决实际问题”、“明明别的理论效果更好,何苦要抱着软件工程不放?”、“但关键就在于已经有现成的理论可以突破呆板,为什么不用”、“因为我发现软件工程和这里面一些理论有矛盾,而且这些理论讲道理”、“现在的软工恐怕还不如二十年前的”

原帖由 Maxwell 于 2010-6-7 23:17 发表


反正我没认为不行，我自然也说不出哪里不行。你要是非问我认为你认为哪里不行的话，我认为你认为软件工程有两点不行。

原帖由 陈珺 于 2010-6-7 23:21 发表

关键是我说不行的很多地方你没否认,倒是纠缠于我是不是认为不行
有句古语:海纳百川

原帖由 Maxwell 于 2010-6-7 23:26 发表


我说过多次了，我没有义务替软件工程宣传。如果有人愿意讨论软件工程，那可能会有人跟帖讨论，但是你既然给软件工程定性了，我就不会替软件工程翻案。在这个版里没人会被跨省，大大方方承认自己的观点就可以。

照你这么讲所有叫作XX工程的学科都可以不要了，只需要开技术课程外加心理学和人力资源管理就可以了？软件工程里面很大一部分内容就是讲如何协作的，而且大部分流行的软件工程方法都是经过实践检验的，不知道你所谓的“远远不足以解决实际问题”是否只是说你所掌握的软件工程知识呢？即便你说软件工程不足以解决实际问题，但是你还是需要说明解决实际问题是否完全不需要软件工程？

原帖由 陈珺 于 2010-6-7 23:31 发表

我记得你开头可是一直在翻案,只是后来没东西说了,然后纠缠起我是不是认为不行

原帖由 Maxwell 于 2010-6-8 00:26 发表

那你就认为你胜利了吧，你的管理学、心理学、人力资源管理战胜了软件工程。

软件工程的发展虽然没有解决所有问题，但是对于提高国内开发团队的开发水平还是绰绰有余的。
软件工程这些年的发展并不是简单重复多年前的观点。其实软件工程无用论在国内还是挺流行的，结果就是自己在低水平徘徊。
近年来各种轻量级软件工程方法也有较大的发展，比如各种敏捷方法，这些方法都很注重实践且易于执行。
软件工程里面很大一部分内容就是讲如何协作的，而且大部分流行的软件工程方法都是经过实践检验的
软件工程本来就是要解决实际困难的，可是被你无视了。
软件工程理论是指导实践的，非要放着前人积累的经验不用，自己去摸索一套，岂不是更增加满足温饱的难度？

原帖由 陈珺 于 2010-6-8 21:46 发表

这些都是你第一页翻案

我就觉得奇怪你觉得软件工程那么好,怎么项目一停就是几年,估计你自己都觉得枯燥

原帖由 Maxwell 于 2010-6-8 22:14 发表


做饭工具管着出米吗？有些话我就不说了。软件工程已经被你的管理学、心理学和人力资源管理打败了，你放心研究你的能产米的炊具吧。

原帖由 陈珺 于 2010-6-8 22:19 发表

你不是说绰绰有余吗?怎么又管着不出米

原帖由 Maxwell 于 2010-6-8 22:30 发表


在另外有人声称看不懂我指的是什么之前，强烈建议你学学逻辑学和语文。

原帖由 陈珺 于 2010-6-8 23:10 发表

你这话就有语病,逻辑方面你也好不了多少
我的感觉是你用软工其实是赌博,从你说"非要造出太空堡垒来才会打仗"开始,我就发现了
我说软工理论缺陷的时侯,你说"软工就够你学了",这合逻辑?