锁定老帖子 主题:与高手交流的一个陷阱
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2004-02-13
[quote="hijack]在分工越来越细的今天和明天, **Domain Expert** is more valuable than *coder*
程序员已经成为打字员了<---- Sorry, a lot of codes are auto-genernated 你的观点我都同意。但是,从一个刚毕业的学生来看吧。你认为他可以做什么呢?程序员还是domain expert?恐怕还是要从基础的做起吧?在一个设计和代码的区分不是很大的公司里,程序员可以通过参与设计/重构活动来得到设计的经验。但是,在MDA模式下的程序员呢?诚如你所说的,大量的代码都是自动生成的。他们能够得到什么样的经验? MDA的目的其实无非是把程序编写改造成流水线作业,把分工明确化。但是,这对于软件工程十分适用么? |
|
返回顶楼 | |
发表时间:2004-03-18
dlee 写道 hijack 写道 请不要以斑竹的身份说这种话,我不习惯于权威。
Show your experience first. Don't just get, get, get, never give. ok? 这里没有什么权威,说话是否权威要看你对论坛的贡献大小(也不是看发帖多少,主要是看帖子质量)。 这里是我管理的版面,如果不喜欢我的风格请到其它版或其它论坛。例如 CSDN,那里非常适合你这样的高手。 我不是完人,也犯不着为了你做完人。 对,支持贡献度是唯一标准。信誉要靠积累,说服力不是靠口水。要靠事实。 |
|
返回顶楼 | |
发表时间:2004-04-04
大家讨论的很激烈^_^
中国有这么多人来关注和思考这个问题,也就是中国软件业幸事.有了思想就有有了前进的动力. 人要成功的话确必须是一个偏执狂,因为一个flexible的了,是很难make decision. MDA,是软件工程的理想目标,我宁愿相信其是可能的,因为软件发展和人类文明的发展的趋势是一样的,工具的使用是标志着人类成为智人的标志,程序辨析从机器码到汇编,到低级语言到高级语言,没一次的突破都是把底层的实现包装了,让程序员不用过多关注细节而专注于业务逻辑的实现. MDA也是如此,只是这次似乎要把程序员这个名词从软件开发中抹去,似乎是一个天大的谎言.且不论DMA这场革命是否成功或彻底,甚至是一次商业抄作,但其意义是推进软件工程的发展,也许它会失败,但是失败的教训是软件工程新发展的宝贵财富.没有前人的失败,哪有你现在站在巨人肩膀上的辉煌.其实成功是偶然的,Coca Cola如此,java 也是一样. 谁敢说当初的Bill Gates会成功呢? 中国软件业要正视自己的落后,因为中国不是没有很好的programmers,而是没有很好的thinkers,中国不只是缺管理者是缺适合中国的管理理论.拿来主意在中国现在中国是比比皆是,可鲁迅业说了不可以全盘西化.既然中国还在学习阶段就要谦虚加上不断的思考,否定别人并不能给你有多大提高,而借鉴别人的思想做自己的实践却可以使你受益非浅. |
|
返回顶楼 | |
发表时间:2004-04-04
当vb出现的时候(交互化编程真的是伟大)有人说程序员将90%失去职业。而MDA在我看来和VB的情况类似,一些没有基础支持的人总是希望通过一条所谓的捷径到达一个很高的高度。MDA的其实还是敏捷的一个分支,多数人好像不知道这个细节,所以大家有必要去看看敏捷的第一次聚会的情况,这可以解释MDA对于文档和代码的态度。而MDA认为可以面对业务进行建模,这个模型可以通过MDA提供的接口调用底层的组件,这样就生产出一个可以运行的程序。我不知道大家研究MDA的方向是什么?是研究如何MDA,还是研究如何实现MDA。MDA在我看来只是对工作从新进行了划分,让一些人去专心的为实现MDA、满足它的接口而进行底层的工作。
我对于MDA的不看好,是因为我不认为MDA就可以完成大部分的工作,而且MDA会让工作变得更多。就如同VB一样,一些人利用VB把原来的应用可以简单的建立起来,但是更多的应用于是产生出来。MDA可能会提高一些工作的效率,但是这样的提高是有限的。 |
|
返回顶楼 | |
发表时间:2004-04-04
现在的IT界新概念多得离谱,简直让人眼花缭乱了。不过事物的发展都是一个累积过程,一个量变到质变的过程。即便MDA能够完成它所描绘的工作那也是我们在编程过程中积累出来的,我们现在的累积已经达到那种程度了么?远远没有。当我们累积到那种程度的时候,自然就会产生象MDA描述的那样的工具,也不用现在去弄个这样的概念来炒作。
|
|
返回顶楼 | |
发表时间:2004-04-04
以我的经验来看,文档驱动开发,只是一个想法,在实际中是很难进行的。
软件最终的制品毕竟是代码,可运行的代码,而不是文档。 如果讲说大家会先看文档,而不是代码,谁能告诉我一下,什么人回来看文档? 当然我对于开源项目没有多少的参与,也觉得相同内容的异构表现形式能节省很多劳动,但现实和理想总是有差距的。 软件工程有太多的东西可能和技术无关,有些并非最优的东西,因为强有力的控制和管理活动,反而达到了不错的效果。 |
|
返回顶楼 | |
发表时间:2004-04-04
文档毕竟是文档,随着我自己的经验的增长,我觉得开发人员并不会像宣扬的那样需求越来越少,而会越来越多,不过讨论的基点,工作的基点在提高,需要解决的问题,越来越不同了。
|
|
返回顶楼 | |
发表时间:2004-04-26
这里有一篇关于Maven的:
http://www.jroller.com/page/fate/?anchor=too_many_jars BTW.关于设计,这个blog值得推荐: http://www.jroller.com/page/fate |
|
返回顶楼 | |
发表时间:2004-05-05
个人观点,工具在软件开发里很重要,基本的工具是必须的。以前喜欢用text editior, 不喜欢IDE, 是因为IDE用起来麻烦,而且在unix上也没有ide可以用。现在喜欢用eclipse, 是因为确实提高了效率,以前笔误太多。楼主提到的工具都在用,关于issue track,以前用过bugzila, 现在还在找,大家给了不少好的意见。
工具的目的是提高效率和质量,ant很好用,但从pm的观点来看,想试试maven, 毕竟多人协同工作,能有一个project portal很吸引人。 最后,大家的火气是不是太大了,那么容易就开始互相指责,希望这里能更心平气和一些。 |
|
返回顶楼 | |
发表时间:2004-10-05
gKarerM 写道 以我的经验来看,文档驱动开发,只是一个想法,在实际中是很难进行的。
软件最终的制品毕竟是代码,可运行的代码,而不是文档。 如果讲说大家会先看文档,而不是代码,谁能告诉我一下,什么人回来看文档? 当然我对于开源项目没有多少的参与,也觉得相同内容的异构表现形式能节省很多劳动,但现实和理想总是有差距的。 软件工程有太多的东西可能和技术无关,有些并非最优的东西,因为强有力的控制和管理活动,反而达到了不错的效果。 文档驱动开发,只是一个想法,在实际中是很难进行的。真的吗?我以前做日本外包项目的时候,完全是按照日方提供的文档来进行编码的,如果文档是错的,有两种办法:1.按错的做 2.提出来,等日方修改完后再往下进行。如果不看清楚文档中的每一句话就编码,吃亏的肯定是自己。 虽然觉得他们的文档错误很多,但是没看懂文档的人写出的代码的bug会更多 |
|
返回顶楼 | |