公司命令切换到某个IDE是否会产生危险信号？[关闭]

我最近加入了一家快速成长的初创公司。在过去的三个月中，开发团队已从4名增加到12名。到现在为止，他们对开发人员过去所做的工作非常放任。实际上，最初让我对公司有吸引力的一件事是，大多数程序员都使用Linux，或者认为自己最适合自己的操作系统。

现在，无需讨论的命令就减少了，每个人都将改用Eclipse。优秀的编辑。我更喜欢SublimeText2，但这只是我个人的口味。

明确一点：我们是一个使用Backbone的JS团队，而Eclipse并不擅长理解Backbone代码。这意味着使用/ good / IDE（PHP Storm）的团队中的那些人必须回去做很多的搜索工作，三步之遥，等等。而不是按住ctrl键并单击并使用后退/前进键-可能会使生产力降低15％，而享受度降低50％...

这是一个危险信号吗？告诉开发人员（非MS）似乎已经很反复无常，并且要控制开发人员（非MS）要使用哪些IDE或工具集（如果它们已经解决并可以投入使用）。

“现在，没有讨论的命令就降下来了，每个人都应该改用Eclipse。”

我认为这是真正的危险信号。您的团队是软件开发方面的专家，并且是受此决策影响的专家，但是您在导致该顺序的讨论中没有说一句话吗？

听起来像是尖刻的老板过度管理。决策者/团队是否对该决策具有相关见解？

鉴于决策者有足够的资格做出这样的决定，因此不征求开发团队的意见至少有两个缺点：

• 团队不感到参与。让团队参与是管理的优先事项。我不想在某个地方对像IDE这样的核心问题没有足够重视甚至无法征求我的意见的地方从事开发工作。当然，征求别人的意见然后做出决定可能会更糟，但在那种情况下，我希望该决定具有扎实的理由。

• 管理层无论经验如何，都无法100％地开发此特定代码。假设那些根本没有有趣洞察力的人是幼稚的。当然，经理人可能会想到开发人员想出的一切，但是唯一的了解方法就是提出问题。

合理的是，当您在一个共同的项目上一起工作时，在每个工作站上您都拥有可用于编辑/构建/调试软件的所有工具，并且从事90％开发工作的核心工具为每个人所熟知。团队。如果您的团队不断壮大并且每个人都使用他个人最喜欢的工具集，那么实现此目标将变得更加困难-更多的人，更多的意见。如果您不让工具数量增加到不必要的程度，管理工作也将变得更加轻松。

当然，如果一个开发人员坚持使用他个人喜欢的编辑器，那可以确定，只要他可以确保源代码在团队的主编辑器中（在您的情况下为Eclipse）不会看起来或行为不同，所以如果使用dev B必须编辑dev A的源代码，不应强迫dev B学习A的个人喜欢的编辑者才能有效地更改源代码。但是要注意，如果两个人必须不时在同一台显示器前协同工作（或进行一些配对编程），那么如果选择的编辑器是众所周知的，那么事情通常会更容易。

为了进行配对编程，如果屏幕前的双方在使用键盘时具有相同的技能，那就很好了。很高兴知道，如果您的项目在IDE中有特殊的配置需求，那么每个人的配置方式都是相同的。如果每个人的工具都相同，则开始新开发人员会更容易。

但是，如果您将其与仅仅尝试最有效的进行比较，那确实不值得

是的，管理层认为自己可以更好地判断使用哪种工具比使用哪种工具要好，这是一个危险的信号。

它本身并不是一个危险信号。

有时管理层需要做出决定。任何需要标准化的问题都属于此类。我曾经在一位允许标准漂移了几年的客户中工作，他们拥有20多种不同的SCM工具。由不同的开发团队作为独立选择开始的事情变成了后勤上的噩梦，严重地阻碍了整个组织之间的技能共享和代码协作。集成的构建是.....呃.....不是很集成.....

此外，为每个决定咨询所有人都是不切实际或不必要的。需要做到的程度取决于组织的文化以及决策的重要性/复杂性。通常，您会选择以下咨询较少的选项之一：

1. 如果您对优点/缺点有足够的了解，请自己做出决定，这不是需要进行广泛咨询的重要决定。
2. 请咨询一些关键人物（他们可能是最有资格做出决定的高级开发人员）。
3. 向所有可能受到影响的人（电子邮件，市政厅会议，团队会议）做出决定。说出您认为正确的决定是什么，但是如果出现新的证据相反，您愿意改变这一决定。如果有人有重要意见，请他们单独提出
4. 邀请人们组成一个小组来审查选项并提出建议。如果真的是一个平仓电话，那是个不错的选择，您不知道答案，并且希望参与其中的人参与决策。

对于诸如开发人员工具之类的问题（这可能是一个有争议的问题），我可能会先做2，然后再做3或4。也就是说，肯定会有一些个人我不会亲自讨论这个问题，但是另一方面的关键人物将有机会为决策做出贡献。

对我来说，如果您强烈认为自己做出了错误的决定，那么真正的危险信号就会出现（错误==它会伤害公司，而不是仅仅选择您喜欢的工具）。提出此问题时，管理层将如何反应：

• 优秀的管理人员会倾听您的观点，衷心感谢您的反馈，并在您提出新见解时重新考虑他们的立场。他们可能仍然不同意您的意见，并可能坚持他们的决定，但是他们会感激您与他们一起提出来，并请您礼貌地说出他们为什么坚持他们的决定。他们甚至将来可能会改变他们做出此类决定的方式，如果您的观点不错，他们可能会将您列入他们的“要问的聪明人”名单中。
• 错误的管理将变得防御，说“已做出决定”和其他避免此类事实的策略，以避免面对他们可能做出错误决定的事实。他们可能将您视为“麻烦制造者”。公司和您对管理的信念一样遭受痛苦。这是一个真正的危险信号！尽你所能！

如果您使用的是maven或类似的东西，那么使用哪个IDE都没关系。如果您依赖某些插件，那么在某些情况下，您可能会与eclipse之类的特定IDE绑定在一起。

我认为您应该能够选择自己的IDE，这是您生产效率最高的IDE。但是，正如我已经说过的，在某些情况下使用标准IDE是有意义的。

我将安装“企业授权” IDE，但仍然可以在我想要的任何IDE中完成我的大部分工作-似乎没有人能告诉我使用了哪个IDE来编辑源文件。

在IDE与编辑器方面...对于几乎所有语言，我都强烈希望使用IDE（IntelliJ），因为它可以为您提供比编辑器更多的功能。我可以将某些内容恢复为ST2或Emacs，但是对于日常编码，尽管我非常喜欢ST2 / Emacs，但IDE几乎总是可以胜出的。

我曾经参与过的每个团队都有很多IDE和编辑器：Eclipse，Netbeans，IDEA，VIM，Emacs，Textmate，RubyMine-从来都不是问题。决不。

在我看来，这对于组织的高层来说确实是一个误会。重要的是让优秀的程序员完成他们需要做的事情，并使用使他们感到最舒适的工具。IDE的一致性与有关对象体系结构，单元测试，算法等基本问题的实际交流关系不大。

与下一个家伙拥有相同的IDE只是意味着我们俩都知道如何使用相同的快捷方式浏览代码，以及如何设置我们的编译/配置。在讨论实际代码问题时，这都不重要。

看，它是否适合居住，取决于公司的其他因素。您总是可以使用自己喜欢的编辑器来处理日常工作。也许您的团队正在做其他伟大的事情，这些都会造就伟大的文化。但是强制性的IDE是IMO的重大失误。对我而言，如果我正在采访一家公司，并且他们告知我允许使用哪个IDE ，我要感谢他们的时间。

在我们的Ruby商店中，强烈建议使用团队中大多数人都喜欢的IDE（RubyMine），因为我们知道它可以完成工作并且可以互相教捷径等。

开发人员可以自由使用其他IDE，但是如果他们愿意，我们要求他们在该编辑器中具有扎实的技能。如果我们看到有人在导航他们的项目或在他们的自定义FooEdit中编辑文本，那么RubyMine就可以了。

如果程序员是给定IDE的专家，那么他们应该使用它。如果他们不是任何IDE的专家，那么对于您的编程语言或您的团队而言，很可能只有一两种很常见，因此对他们来说很有意义。

被迫在IDE上进行标准化听起来很可怕。

应该检查公司通常在其开发人员上强制使用特定编辑器或软件的原因。我的偏执（也许不是我要找的词）部分认为，他们要求开发人员安装的日蚀可能添加了某种生产力跟踪。更加不那么偏执（再次）的想法是，他们花了很多时间在此IDE中添加产品构建工具，如果每个人都按下相同的按钮来测试和构建其代码分支，这将使事情变得容易得多。

无论如何，我想说的可能不仅仅是官僚主义，或者是一种与开发人员的头脑打交道的方法。

这是一个巨大的危险信号。每个公司都有一些如此愚蠢的想法，但是如果其他危险信号不断出现，那就走吧。

某些决策背后的动机很容易迷失-尤其是对于快速成长的团队。迁移到Eclipse的动机可能是这样一个事实，即大多数开发人员似乎在配置IDE时浪费了很多时间，并且公司的专业知识有限。

我只是想按顺序转移到Eclipse，这意味着您可以在需要时进行Eclipse的安装，但是请在您喜欢的编辑器中继续进行工作。（如果您的公司开始在Eclipse中部署出色的工具，则可能必须逐渐迁移到Eclipse。）

危险信号：如果有更多这样的非理性命令，我会等着担心。

初创公司通常试图保持足够长的敏捷度，以找出可持续的商业模式。一旦确定了金钱部分，管理层便开始扩大业务规模。通常这是所有早期技术员工开始离开的时间，因为工程流程越来越紧。

如您所知，在运行代码之前，您不知道它将实际执行什么代码。图灵在计算的早期就证明了这一点。这意味着在编写软件时，没有任何有意义的衡量生产力的方法。但是，要使管理人员做好工作，生产率必须清晰可辨。由于您无法衡量代码（例如，人们已经尝试过-例如，几行代码），因此他们将衡量他们可以看到的内容。程序员比他们开发的软件更清晰易读。典型的管理团队会尝试控制程序员，以使程序员可以理解这些事情（而不是真正地工作：躲开）。而且由于它们测量的是错误的东西，因此效果不佳。

话虽如此，您仍然可以与一个松散耦合的团队一起走很长一段路。Github的开发团队大约有50个人，他们违反了业务管理教科书中的所有规则。他们似乎做得很好。错误得到修复（最终）。功能已添加。火被扑灭。

一个大的危险信号是，如果他们试图扩大规模而又不知道如何赚钱。那时，您想知道未投资的期权和赠款中有多少确实值得。

当然这是一个坏主意。不可避免的是，由于必须学会使用新工具，因此团队的工作效率将降低。即使这样，他们也不会与他们已经的工具一样有效神交。

由于我自己尝试过各种工具，因此我总会感到“太棒了，该编辑器用<插入一些与首选工具的错误/差异>烦死了我”。因此，这也是一个道德缺陷。

但是当然，也有一些专家让整个团队使用相同的工具。共享配置，skripts，插件和所有类似的东西。使用各种各样的工具集是不可能的。

另一方面……如果每个人都使用他或她喜欢的软件，则不需要最后一点。;）

您可以在仍然输入SublimeText2的同时“使用” Eclipse。

这意味着已经为项目安装并配置了Eclipse，并对其进行了升级，以便在进行配对编程时同样感到舒适。只要维护并行设置不会占用过多时间，并且您不会与自己打交道，那么没有人会（或者至少应该）在乎您实际使用哪种编辑器键入您提交的代码。标准开发环境。

如果您使用的是Git而分支已关闭，则无论如何都不需要使用彼此的编辑器。如果他真的不能弄清楚您的工具集，则可以只推一个分支，然后让另一个开发人员拉它以使其正常工作。强迫所有人使用相同的编辑器听起来像是某些业务负责人的命令，他们想看起来很聪明，但实际上并不了解你们的运作方式。

如果您从管理层的角度考虑这一问题，那么他们这样做的原因是为了遵守法律。该公司有责任确保所使用的所有工具均得到合法使用，并且不会妨碍正在开发的产品。（有些编辑器是免费供个人使用的，但不是免费供任何其他用途，等等。）审核每个开发人员可能想要使用的每个工具可能会很昂贵。我已经看到，在时间紧迫的项目中，管理人员将谨慎对待哪些工具/库/等用于最小化项目后期由法人指导的更改。

在更高安全性的项目上，还需要考虑IDE在哪里存储临时文件，以及在会话之间存储什么信息。

这完全取决于他们推荐Eclipse的原因。如果开发人员因每个人的组织方式不同而在设置环境方面遇到麻烦，则可能有理由推荐直筒外套。但是，如果每个人都愿意并愿意使用他们想要的东西，那么就没有理由对如此深深参与创意过程的事物进行改变。

Eclipse不仅仅是一个编辑器-您可能会继续使用自己喜欢的编辑器来编辑代码，并依赖Eclipse进行源代码控制，调试以及公司强制性工作流希望用于的其他任何操作。

最后一件事-此级别的执行过程可能表明公司打算扩展开发团队，并希望拥有一定的结构，以便新的团队成员可以更快地提高生产率。如果您认为Rails（或Django）是一个“有意见的”框架，您将意识到拥有结构有助于更轻松地理解新应用程序。

危险信号不仅仅在于将单个IDE /编辑器强加给每个开发人员，而是这个决定，尤其是不是要使用哪个IDE /编辑器的决定并不是所有开发人员都做出的，也许没有一个他们！？！

当然，开发人员最好达成共识，尤其是因为他们显然最有资格做出决定（至少在哪个编辑器/ IDE上）。可能有充分的理由进行整合，该决定应权衡管理层的偏爱，但哪个编辑器/ IDE应该是所有开发人员的决定。

要让12位开发人员进行投票很容易。当然有足够的时间来做到这一点！无论如何，该结论可能还是很痛苦的，甚至最终可能最终还是Eclipse，但是在这种情况下将需求标记为“危险信号”将更具争议。