感慨：IDE功能越来越强大，不知对于开发人员是好还是坏？

问题是，丢了IDE，写个synchronized都会拼错，那才叫个惨

不学思想，永远只能用框架，而不能自己发明框架。

李刚在他的Struts2权威指南里说

“实际上，真正优秀的程序员当然可以使用IDE工具，但即使使用VI（UNIX下无格式编辑器）、记事本也一样可以完成非常优秀的项目。笔者对于IDE工具的态度是：可以使用IDE工具，但绝不可依赖于IDE工具。学习阶段，千万不要使用IDE工具；开发阶段，才去使用IDE工具。

提醒 对于IDE工具，业内有一个说法：IDE工具会加快高手的开发效率，但会使初学者更白痴。”

呵呵 。我认为在一个经验非常足够的情况下IDE的作用是会被MDA这类工具代替。

ANT MAVEN2等等构建工具和一些集成工具可以完成许多IDE的 工具了 。比如新建项目。MAVEN2是不错的选择。当然，在独自开发的 情况下单独使用IDE是 可以的 。如果在项目十个人以上的情况，不使用构建，持续集成工具是不可想象的 。

楼主所说的"跟着eclipse中提供的向导点击“下一步完成HIbernate映射配置"，这里有一个陷阱，你是不是首先导入数据库，然后按照eclipse的一步步完成呢，如果是这样，那你就完全误用Hibernate了，Hibernate是对象冬眠的意思，应该根据领域模型再一步步完成Hibernate配置。

楼主的问题不只是一个IDE工具问题，而是IDE使用者的素质问题，如果没有OO/IOC/AOP等基本知识，当然使用SSH会觉得麻烦，更可能会被一些所谓快速IDE误用。

使用者素质高低和软件框架难易之间存在角力的问题，一些IDE(如一些Hibernate插件)或软件如Ruby等脚本就钻了这个空子，将原先100%羊绒降为20%羊绒，但是还能叫纯羊绒吗？

本人还是力荐提高使用者素质：将OO作为软件学习基础，如果你具备了OO分析设计知识，将来IDE必然被MDA或MDSD工具替代，这样，你就可以直接使用这些强大的新的IDE工具（Borland剔除其JBuilder IDE工具软件，重点发展Together等都是一个趋势）。

第二点，IDE能够帮助我们提高开发效率，比如OSGI就从开发到运行提供了一个方便组件框架，但是个人认为OSGI解决组件之间依赖关系如果不使用IOC，将是发明类似EJB容器的另外一个轮子，尽管OSGI可以将WEB的JSP进行分包，但是实际用处不大，如果我的WEB应用不是以war部署，而是直接目录文件形式，结合Struts+Tiles的细分，某个JSP更改，我直接上传更改这个JSP就可以，比OSGI的bundle包更方便精准，OSGI其他除了和Eclipse能够绑定提供方便开发Plugin之外，看不出比IOC/AOP组件容器有什么优点。

本人不赞成开发阶段和运行阶段进行耦合，把Eclipse的一个Plugin包作为运行包带到运行环境中，这又形成了与Eclipse自己的绑定，又被误导了。

我也不同意楼上关于“学习阶段 不用IDE，开发阶段才用IDE”观点，又走向另外一个极端，如果一个技术学习和开发可以分开，那就不是实战性技术，那你学习的技术就是花架子，脱离实际的，说这话的人估计没有什么实战经验。为什么这么说呢？因为Java软件是一个组件技术，每一个项目都是有几十个组件通过XML等配置组合在一起，就象一个房子由很多板块 砖头通过水泥组合在一起，这已经是Java软件的常态，这样的常态软件开发必然依赖IDE提供方便提示功能，比如XML提示等，以及JSP的标签提示，如果没有这些，你使用记事本几乎无法学习Java软件，更无法了解Java企业软件的常态，也就是它到底是个什么样这个最基本目的。

IDE除支持软件开发外，还有协同开发的功能，这是其最重要的一个功能(当软件开发靠XML捆绑以后，IDE在支持软件开发上已经显示不出什么优势)，如果一个开发者在学习开始没有从SVN上拉软件的习惯，很难想象他以后有很好的协同开发能力，因为解决版本冲突问题已经不是一个简单问题，而是一个复杂的技能问题。没用过的是不知道的。

IDE还有另外一个发展方向，就是想象Delphi那样提供可视化开发，注意，这表面好像很吸引人，是一个银弹，但是不要被误导：Java架构是多层次的，IDE提供可视化开发只是Java多层中表现层的开发如JSF，不会再象以前那样直接将数据库拖到界面了，如果IDE提供这个功能就是倒退；如果IDE只提供表现层的可视化开发，这里面有一个悖论：JavaEE表现层是MVC模式，JSP是一个MVC中的一个静态View，就是一个HTML，MVC提供的就是将软件和HTML网页制作分离，HTML可以由专业的美工来通过Deamweaver.frontpage等软件完成，那么IDE提供的可视化开发到底是什么内容呢？

[该贴被admin于2007-12-10 10:30修改过]

还是喜欢用Editplus。

只用vi, 而拒绝ide，不免有些食古不化。

程序设计真正在意的是设计意图能够快速容易的被表达，被实现，语言的发展是如此，ide的发展更是如此。

软件工程化的趋势，必须强调整个开发团队的一致性，往往容易的，快速的东西能够让团队保持一致。

任何事物都有两面性，是好是坏，必须从行业性考虑

我觉得还是万物为我所用，要强调的是OO，以及开发流程的匹配。

其实现在的社会,既需要喜欢用ide的人,也需要喜欢vi和记事本的人,才能和谐.
否则将来就没有好的ide使用了!

处于学习阶段的人 和 开发阶段的人 同时看待IDE 就会产生这个问题，
IDE 本身就是为开发人员创建的

很同意这一点：“不只是一个IDE工具问题，而是IDE使用者的素质问题”。随着生产力发展，社会分工是必然，软件行业也逃不脱这一点。并不是所有的开发人员都需要深刻理解OO/IOC/AOP这些东西，对于很多人来说，IDE帮他们屏蔽掉这些，将注意力放到自己关心的代码部分才是最能提高效率的。即使开发人员想了解这些，IDE也并没有设置障碍，从一个最简单的项目做起一步步手工配置就是了。所以，我认为学习时用IDE也没有什么不妥，他提供了一种“自顶向下”的学习通道，就像做系统设计建模一样，永远只关注自己最关心的内容，而用记事本则是“自底向上”的，学习周期可能会很长。

另外，“可视化”不仅是“可视化开发”，也应该包括“可视化建模”。设想软件产业充分发展后，“组件化生产”有可能成为一种模式。在这种情况下，软件开发人员将分化为两种角色，一种是“组件提供者”，利用“古老的”开发方式生产组件；另一种是“组件消费者”，基于组件通过拖拖拉拉画画图等方式搭建业务系统。这部分人需要的技能是理解业务和掌握工具，而且理解业务更重要。而他们工作的环境，都可以是在同一个IDE。换句话说，MDA完全可以纳入IDE的范畴，何必分而裂之呢。在这条路上，普元走的不错。

IDE很大程度上是软件质量杀手，因为自动生成的“臭味代码”太多了。

老老实实用字处理器，才能逼迫开发者不断重构以改进代码，并进一步改进设计。不知不觉中，API越输越熟，重复代码越来越少，系统质量越来越高，学会用简单直接的方式解决复杂的问题，以至于最后开发效率比IDE更高。

至于IDE，个人认为比较适合培养初学者的兴趣。

真怀疑你们作过开发没有

一味地强调IDE弊端的人，我相信，你们并没有完成过很大的项目，所接触的，也只是没有多少页面，或多少类，在开发中，我觉得IDE是必要的，什么地方必要，它的工程的管理，以为对于类的组织管理。可以大大加快开发的速度，而对于Banq所说的陷阱，这种是从DB -> OO的方式，虽然可能不够OO，但，这却仍是现在开发的最常用的方式，我觉得，按照Banq的思想，Grails做得不错，一开始就从domain的设计开始。而这方面，rails却仍是先定义数据库的结构。
[该贴被scorpioer于2007-12-25 22:47修改过]

IDE当然是越高级越好，本来就是工具嘛，既不会让你更聪明，也不会让你更白痴。
不过要老是用高级IDE做智能UI式的开发，就纯粹是业余水平了。
这也正是软件业越来越明显的趋势－－业余选手的水平越来越高了，专业的呢？倒未必越来越专业！