软件开发团队中的多个 IDE

发布于 2024-10-31 04:58:32 字数 163 浏览 6 评论 0原文

我的团队即将开始开发具有 Swing 客户端和 EJB 后端的应用程序。

我正在考虑标准化使用 Netbeans 来开发 Swing 部分,因为它是非常用户友好的 Swing 设计器功能,但仍然使用 Eclipse 来完成其余部分。

只是想知道是否有人这样做过,如果是,效果如何?

My team's about to begin development on an application with a Swing client and an EJB Back end.

I'm thinking of standardizing on using Netbeans for developing the Swing portion because of it's very user friendly swing designer functionality but still make use of Eclipse for the rest.

Just wondering if anybody has done this and if so how well did it work?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

流绪微梦 2024-11-07 04:58:33

您应该对 Swing 项目的 NetBeans 进行标准化

是的,如果您正在开发 Java Swing 客户端 IDE,那么您应该对 NetBeans 进行标准化。否则整个团队将无法利用 NetBeans 中优秀的 GUI 设计器。此外,他们可能会破坏成员使用 NetBeans GUI 工具完成的工作。

我参与过一个项目,我们使用 3 或 4 个 IDE 来开发价值数百万美元的 Swing 客户端。由于整个团队并未使用 NetBeans,因此生产力大幅下降。

理论上,您可以允许多个 IDE 进行后端工作,因为这并不重要,但能够使用 NetBeans 构建并将所有内容完全集成到单个 IDE 中是非常好的。

根据我没有按照您的建议进行操作的经验,以及我能够使用 NetBeans 在 Swing 中进行快速开发的经验,我想说肯定会锁定 NetBeans。

You should standardize on NetBeans for a Swing Project

Yes you should standardize on NetBeans if you are doing a Java Swing Client IDE. Otherwise the entire team will not be able to take advantage of the excellent GUI designer in NetBeans. Moreover they may break the work done by the members using the NetBeans GUI tool.

I have worked on a project where we used 3 or 4 IDEs to develop a multi-million dollar Swing Client. There was a major productivity loss because NetBeans was not used by the entire team.

Theoretically you could allow multiple IDEs for the backend work as it doesn't matter as much, but it is very nice to beable to use the NetBeans builds and to fully integrate everything in a single IDE.

Based on my experience not doing what you are proposing, and on my experience in being able to do rapid development in Swing with NetBeans I would say definitely lock in on NetBeans.

独孤求败 2024-11-07 04:58:33

虽然开发人员的自由度很大,但如果不在单个 IDE 上进行标准化,您就会牺牲很多功能。项目元数据通常不能很好地混合,而您确实希望将元数据置于源代码管理中。如果您在开发人员之间进行配置文件更改之战,那么您就做错了。

您可能需要考虑使用 Eclipse 的 WindowBuilder 插件,而不是使用 NetBeans 进行 Swing 开发。

http://www.eclipse.org/windowbuilder

While developer freedom is great, you are sacrificing a lot of functionality by not standardizing on a single IDE. Project metadata often doesn't mix well and you really do want to put the metadata in source control. If you are getting battle of configuration file changes between developers, you are doing it wrong.

You may want to consider WindowBuilder plugin for Eclipse rather than going to NetBeans for Swing development.

http://www.eclipse.org/windowbuilder

一指流沙 2024-11-07 04:58:32

我认为答案是“视情况而定”。

如果你有相对经验丰富的工程师可以管理自己的IDE配置,那么我会说让他们使用他们想要的任何东西。我参与了一个项目,在 Web 端我使用 netbeans,而在其余模块中我使用 eclipse。它工作正常,但实际上并没有任何设定的“标准”,因为每个人都有足够的经验来管理他们的 IDE。

在工程师经验不足的环境中,拥有一个 IDE 就很棒,因为它会减少团队领导必须花费在维持初级开发人员的启动和运行上的时间,在这种情况下,会更容易维护单个开发环境而不是多个。

在任何情况下我都不会签入由 netbeans 或 eclipse 生成的项目文件。虽然一开始让人们启动并运行似乎很好,但当任何人想要自定义他们的设置时,你会突然在源代码管理中遇到配置文件之争,这很糟糕。

I think the answer is going to be "it depends."

If you have relatively experienced engineers that can manage their own IDE configuration, then I would say let them use whatever they want. I worked on a project where in the web side I was in netbeans, and in the rest of the modules I was in eclipse. It worked ok, but there wasn't really any set "standard" because everyone was experienced enough to be able to manage their IDE.

In a setting where you have less experienced engineers then having a single IDE is great because it'll reduce the amount of time the team leads have to spend keeping the junior developers up and running, and in that case, it would be much easier to maintain a single development environment instead of multiple.

In no case would I check in the project files generated by netbeans or eclipse. While it may seem to be nice at the start to get people up and running, when anyone wants to customize their setup at all you suddenly have a battle of configuration files in your source control, and that stinks.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文