开发经理是否应该允许全权选择平台和语言？
我是一家小型软件公司的开发经理，主要生产用 Java 编写的产品以及一系列与 Java 相关的 Web 技术和框架（当我们需要较低级别的东西时，使用 C++ 来编写）。
当一位开发人员来找我说“我想用 Perl / Python / Ruby / Visual Basic / Fortran / 6800 Assembler 构建一个内部工具（基本上是我们核心技术列表中没有的任何东西）”时，我的第一反应是我不想要当那个人离开时我们可能无法支持的东西 - 内部工具会变得至关重要，你需要能够独立于特定个人来维护它们。
我的观点是，这并不是说我要求他们用 C 语言编写一个 Web 应用程序，我们的核心技术列表通常包含适合此类工作的工具（如果可能不如某些替代方案），但是在这些情况下应如何严格地应用标准？
（标记为社区维基，因为我知道它是主观的 - 虽然不是，我希望有争议 - 但我确信如果人们认为这是不合理的，他们会关闭）。
I'm development manager in a small software house producing products written primarily in Java and a bunch of Java related web technologies and frameworks (the odd bit of C++ when we need something lower level).
When one of the developers comes to me and says "I want to knock up an internal tool in Perl / Python / Ruby / Visual Basic / Fortran / 6800 Assembler (basically anything that's not on our core technology list)", my immediate response is that I don't want something we may not be able to support when that person leaves - internal tools have a way of becoming critical and you need to be able to maintain them independent of a particular individual.
My view is that it's not as if I'm asking them to write a web app in C, our core technology list contains generally tools which are fine for the sort of job in question (if perhaps not as good as some alternatives), but how strictly should standards be applied in these situations?
(Marker as community wiki as I know it's subjective - though not, I hope argumentative - but I'm sure people will close if they think it's unreasonable).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据定义，标准是对潜在解决方案的任意限制。从本质上讲，它们并不总是包含针对特定工作的“最佳”工具（当然不是针对“最佳”的所有解释）。但遵守标准可以让您保持合理的成本并保持灵活性（避免由于非标准技术而您的员工技能不足而不敢接触工具链的情况）。所以一般来说，要坚定你的标准：你有一个很好的案例。
然而，鉴于世界的不断变化，特别是 IT，标准也需要不断发展。 这就是您应该为实验留出一些回旋余地的地方：允许您的开发人员将例如 Ruby 工具组合在一起以感受它，但要为使用已批准的技术替换它预留预算，并且不允许原开发者来维护它，以获得第二意见并降低锁定原开发者的风险。 （当然，这在紧急情况下会造成伤害。）如果新技术有效并且显着超过了您现有的标准（关键点！），请考虑逐步采用它。但也不能不逐步淘汰某些技术否则（至少十分之九）：您不希望您的标准投资组合不受控制地增长。
Standards are, by definition, arbitrary restrictions on potential solutions. By nature, they don't always include the 'best' tool for a given job (certainly not for all interpretations of 'best'). But adhering to standards allows you to keep costs reasonable, and to stay flexible (avoiding situations where you don't dare touch your toolchain because of a nonstandard technology for which you have insufficiently skilled staff). So generally speaking, be firm on your standards: you have an excellent case.
However, given the flux of the world in general and IT in particular, standards also need to evolve. That's where you should leave some wiggle room for experimentation: allow your developers to throw together e.g. a Ruby tool to get a feel for it, but budget for its replacement with an approved technology, and don't permit the original developer to maintain it, in order to get second opinions and decrease the risk of lock-in to the original developer. (Which, granted, is going to hurt in an emergency.) If the new technology works out and significantly surpasses your existing standards (key point!), consider phasing it in. But not without phasing out something else (in at least nine cases out of ten): you don't want your standard portfolio growing uncontrollably.
你的立场看起来非常合理，也就是说，你能够向人们解释你所说的话背后的原因。
他们之所以不能用他们最喜欢的语言做得更快，甚至更好，是因为你会疯狂地管理它。除了，如果你不这样做怎么办？
明智的管理策略可能（可能是！）一般对这些事情说“不”，但时不时地说“是”。并尝试学习。
这是我的建议：一个编写良好、用您通常不使用的语言构建的内部工具，可能会让您进一步使用该工具。 Python 和 Django、Ruby 和 Rails，这样的例子不胜枚举。所以你是一个 Java 人。对你有好处。
但是，当您抛开任意限制并将限制留给真正有 100% 可靠的业务和财务案例支持时，您的开发团队、组织可能会超出预期。
害怕学习新的编程语言是组织中的平庸人员和优秀人员之间的区别。对他们生产力的人为限制最终会导致你失去那些吱吱作响的轮子。他们会去其他地方。你的问题应该是“如果我勾掉这些人然后他们离开，我是否失去了一些好的东西，一些值得保留的东西，而我现在拥有的人，所有的东西都用 Java 编写，是否有能力为我打造下一个伟大的东西？”或者当我需要解决我的下一个大问题时，他们都是集体思维团队中缓慢而平等的成员，而没有一个人有独创性的想法？”
我提出以下建议：
i．对 Visual Basic 和 C# 说不，因为 Java 和 JVM 提供了 .net 托管代码环境的优势的超集。迁移到 .net 意味着保留第二个虚拟机技术、运行时和竞争框架，同时失去 Java 的可移植性和开源 JVM 平台，这对您的组织来说是净损失。
二.对 Ruby 和 Python 说“是”，因为它们位于初创公司用来改变世界的语言列表中。他们是正在崛起的明星。
三.当您有明确的业务案例需要这样做时，请说“不”；而当六个月或更短的时间内，您可以暂时回答“是”，这将为您提供更好的答案，告诉您什么可以为您的软件团队提供最佳结果和功能。还有什么是 Java 做不到的吗？不。还有什么事情是你不能用 Python 和 Ruby 做得更快、甚至更好的吗？你们中的一些人说是吗？给他们一个机会来证明这一点。
四.另外，不要使用辅助语言对主要 Java 产品进行扩展和改进。如果使用的话，Python 和 Ruby 是独立的内部工具，而不是“用来代替 Java 来扩展现有主要 Java 应用程序的一流语言”，也不是完全重写的目标，也不是放弃的方式爪哇。
Your position seems eminently reasonable, that is to say, you are able to explain reasons behind what you are telling people.
The reason they can not do something faster, and perhaps better, with their favorite language, is because you would go crazy managing it. Except, what if you didn't?
A sane management strategy might be (might be!) to generally say no to these things, but every now and then, say yes. And try to learn.
Here is my suggestion: An internal tool that is well written, built in a language you don't normally use, just might open you up to further use of that tool. Python and Django, Ruby and Rails, and the list goes on and on. So you're a Java guy. Good for you.
But your development team, organization can probably outperform expectations when you leave behind arbitrary limits, and leave the limits to what really has a 100% solid business and financial case behind it.
Fear of learning a new programming language is the difference between the mediocre, and the good people in your organization. Artificial limits on their productivity, will in time, cause you to lose those squeaky-wheels. They will go elsewhere. Your question should be "if I tick off these guys and they leave, did I lose something good, something worth keeping, and do the people who I have now, who all write everything in Java, have the capability to build me my next big product, or solve my next big problem, when I need it solved? Or are they all plodding egalitarian members of a groupthink-team, and not one of them capable of an original thought?"
I submit to be beaten-up the following proposal:
i. Say no to Visual Basic, and C# on the grounds that Java and the JVM offer a superset of the benefits of the .net managed code environment. Moving to .net means keeping around a second virtual machine technology, runtime and competing frameworks, while losing Java's portability and open source JVM platform, a net loss to your organization.
ii. Say yes to Ruby and Python, because they are on the list of languages that startups are using to change the world. They are stars in ascendancy.
iii. Say no when you have a clear business case to do so, and a provisional yes when six months or less will give you a better answer on what will provide the optimal results and capabilities to your software team. Is there anything you can't do in Java? No. Is there anything that you can't do faster, and possibly better, in Python and Ruby? Some of your people are saying yes? Give them a chance to prove it.
iv. Also, say no to extensions and improvements to your main Java products using secondary languages. If used, Python and Ruby are for standalone internal tools, not as "first class languages to be used instead of Java to extend your primary existing Java applications", and not as a destination for a total rewrite, and not as a way to abandon Java.