团队中的每个成员都应该使用相同的IDE吗？[关闭]

您认为强制团队的每个成员必须使用相同的IDE是否有意义？

例如，团队中所有已经使用过IDE的工程师。两位新工程师来了，他们想使用IDE Y，因为这是他们几年来一直在使用的东西。

您有“混合IDE”团队的经验吗？如果是这样，那是什么？

如果“正式的”构建系统（如Continuous Build服务器所使用的）对所有人都相同，那么我看不出团队中的每个成员都无法选择他想要的工具的任何原因...

如果您的团队依赖于仅可用于某些IDE的某些插件，则只有在同一开发平台下统一每个人才有意义。我还发现，如果开发人员遇到与我相同的IDE，则可以更轻松地帮助他们，而如果我要使用不熟悉的界面阅读某人的屏幕，则需要花费更长的时间。

缺点是配对时您无法流畅地交换键盘。在主流IDE之间，这可能不是一个大问题，但是如果一个人习惯了Eclipse，而另一个人习惯了vim，那么将会出现不匹配的情况。Eclipse用户很可能完全无法使用vim，而vim用户（就是我；）花了很多时间来抱怨使用香草Eclipse的速度太慢了。

话虽如此，我还是宁愿自己使用vim。如果您的同伴对你们中的一个“长时间开车”感到满意，那就可以了。

而且我知道有一些插件可以使Eclipse像vi一样工作，但是我在谈论我要去哪里与可以按自己的意愿运行Eclipse的人配对，所以他们不会安装该插件。

强迫每个Linux内核开发人员使用相同的IDE（或完全使用任何IDE）根本没有意义。

我没有使用混合IDE的经验，除非您计算出一个商业IDE并偶尔添加一个文本编辑器“多个IDE”作为补充，但是我可以想到一些优点和缺点。

优点

• 每个开发人员可以利用他们最了解的知识来提高生产力
• 某些IDE可能比其他IDE更具优势（一个IDE可能在重构方面更好，另一个IDE在提供编码辅助方面可能更好，其他IDE在数据集成方面可能更好，无论如何）。使用混合可能会使您的团队利用这一点。
• 对于其中一个IDE失效的可能性，您会有所顾忌。

缺点

• 许可问题。如果涉及多个商业IDE，那么可能会更昂贵。至少，要跟踪更多。
• 许可问题2.如果有IDE或langauge许可的框架或插件，这会有问题吗？
• 如Dszordan所述，某些插件可能与不同的IDE不兼容。
• 如果IDE具有代码生成组件或样式格式化引擎，它们的功能有所不同，则可能会引起混淆。

有一个可以强制执行此操作的原因。只需考虑Visual Studio和emacs / vim。与在Windows上一样，Visual Studio将在行尾添加一个额外的\ r。这弄乱了emacs / vim中的显示。选项卡也会造成问题。我们面临的问题是，我们的开发人员在Linux中工作，但我们的软件体系结构在Visual Studio中还是可以接受的。他曾经诅咒我们说我们没有正确格式化文件。但是，当他发现这是由于默认设置问题引起的时，我们都同意了相同的格式。
如果有人强迫我使用特定的IDE，我不会感到难过。无论对团队有什么好处，我都会尊重并会做出相应的妥协。

当今的开发人员希望选择自己的工具。

但是随着时间的流逝，这种情况已经改变。10或15年前，在我工作过的地方没有太多选择。（是的，编辑很多，但不是“选择”）。我在15年前工作的那家商店是“老派”（即使在那时！），而vi是编辑。没有选择。这实际上非常有用，因为经过第一个月的指责和宣誓之后，我才真正喜欢上它。

如今，有许多选择，每种选择都有许多优势。

以我的个人经验，我使用IDE-rubyMine-几年了，然后才切换回vi（m）。我之所以这样做，是因为Ruby是一种很难为IDE（鸭子类型和其他动态功能）编写IDE的语言，因此IDE的运行速度往往很慢，并且/或者需要最新，最快的机器。

好吧，是的，我在混合Windows / Unix和C ++ / Java团队中有一些经验。我认为这不是问题，只要每个人都可以与另一个IDE一起工作，或者永远不会出现不熟悉IDE Y的人需要与另一个人（即具有IDE Y的人）一起工作的情况。 ）系统。

如果每个人都愿意，那很好，但是不同的人可能想要使用不同的编辑器/ IDE。如果我与团队一起从事大型工作，我真的不希望人们强迫我使用我喜欢的编辑器之外的其他编辑器，而且我怀疑我是一个人。如果您不强迫他们使用特定的编辑器，人们可能会对这种情况最满意。

顺便说一句，Emacs！

我认为不是每个人都需要具有“相同”的IDE，但是每个人都具有“受支持的” IDE会很好。

例如，就注释和更新代码而言，如果将IDE集成到代码审查过程中，那么每个人都可以使用受支持的平台是有意义的。

如果您的公司使用的是Rational Team Concert之类的协作环境，而一个或两个人想使用不受支持的IDE（或其他版本），而其他所有人都使用兼容的IDE，那么对于那些选择成为在支持循环之外。

在我们这里，我们使用Visual Studio构建项目。在编辑文本时，我切换到Emacs。只要工作完成，您的公司就不会在意。

听起来有点像“我们在以前的工作中使用了它”。好吧，他们不是以前的工作。

如果它不影响您的工具链或源代码管理插件，那么可能是的。再说一次，这两个新人能展示出明显的好处吗？他们使用过您的IDE吗？

否则，除非有充分的理由，否则我不会忍受这种废话。他们不是以前的工作：想离开那里真不是那么好。使用另一个IDE是旧工作中的唯一亮点：如果是这样，他们应该对STFU表示感谢。

是！实施单例IDE。

当项目依赖项更改时，它将产生问题。如果一个人对项目引入了新的依赖关系，那么每个人都将浪费时间来引入新的依赖关系，并且有些人可能会失败并浪费时间。浪费大量时间。

应该有一个很好的理由向团队添加其他IDE，这意味着节省的时间应该超过专门用于将系统迁移到不同IDE的时间。