开发人员工具、语言、框架等是否应该在整个组织中标准化?[关闭]

标准化有很多好处。我的组织对我们将使用什么样的技术制定了相当的标准。我们在以下方面实现了巨大的利益…

1. 招聘。很容易描述我们正在寻找什么样的技术,并确保我们的招聘人员正在寻找合适的人。

2. 许可证/软件成本。我可以很容易地买到企业许可证。这给了我一个机会,通过让我花更多的钱与较少的供应商,从而获得更多的杠杆率,降低成本。

3. 交付的一致性。我们的团队对项目的构建、推出和维护有一个很好的想法,因为他们以前做过成功的项目(他们也知道其中的陷阱)。

   • 敏捷性。因为标准化,我可以让一个团队代替另一个团队,或者让一个人代替另一个人。

   • 质量。我们有跨团队的同行评审和跨团队的质量保证。

如果没有对技术堆栈、工具、语言和框架的一致使用,这些类型的好处将更加难以实现。我并不排斥新技术,但除了“如果我想怎么办…”之外,还有一个具体的原因。

标准化的一个主要问题是,一旦标准出台,它们就会被具体化,很难改变。这就是为什么我们的企业it环境被困在ie 6上,而我们可以访问的最好的变更控制系统是cvs。鉴于这种情况,一些开发商违反了规则,一些人在创新性更强的公司找到了工作。

你这里有一个混合的包。

我不会对ide进行标准化,因为每个开发人员的工作方式都不同。如果被迫使用visual studio,那些疯狂精通emacs的人可能会看到他们的性能受到影响。我用一个30英寸的显示器优化我的visual studio体验,并发现它非常高效。

然而,标准化一些工具,如scons或make或其他构建产品的工具是完全合理的。

禁止一些图书馆,并有一个新图书馆批准或不批准的程序,也是非常合理的。我知道很多公司禁止boost,jquery,或者一般禁止开源库等等,他们有充分的理由这么做。我知道当一个实习生把他在互联网上发现的一些随机的“安全”图书馆合并在一起,却没有任何人运行时,我感到相当不安。

最终每个公司都是不同的。你必须有足够的标准化,以避免严重的并发症和问题,因为人们来来去去,或随着新产品的形成和组织结构的变化。但你必须足够灵活,避免重新发明你需要的每一个轮子。

重要的是要有明确的理由采用某个工具或禁止其他工具或库。你不能仅仅让管理层要求你使用这个而不是那个,除非咨询工程团队并以合理的理由做出决定。一旦做出决定,这些理由就应该写下来并清楚地传达出去。

而且,如果最后,你最喜欢的工具或库没有被采用,请不要抱怨。要有适应力,做好你的工作,或者找一个能让你更快乐的新工作。

我曾经为一位经理工作过,他觉得有必要在 每一个 他的软件开发操作水平。每个开发工具都必须是最先进的(最好是beta版)。他让我们使用的许多工具没有很好的文档,也没有培训。最终,我们尝试的大多数技术 不起作用 是的。我们浪费了大量的时间在新技术的研发上,结果发现我们无法取得进展时就放弃了。

我试图证明创新在 value proposition 谎言。在标准技术失败的地方,也可以明智地使用创新。但对于大多数平凡的任务,使用可靠的工具和方法应该是默认的。更少的风险,更少的成本,更少的管理关注。因此,你可以把时间和精力集中在创新最有利的领域。

所以我认为标准化有着重要的作用。但盲目地说一切必须标准,就像我的经理认为一切必须创新一样,肯定会失败。

支持标准化的首要论点是,它最大限度地提高了整个组织使用共同知识体系的能力。不知道如何在asp.net/c中构建自定义web控件?去大厅问问比尔谁知道。如果你使用不同的工具,这种组织智慧就会被扼杀。当它是 不 很好被限制在一个最小的共同点(希望你的管理层会意识到这一点)你不应该忽视分享经验的好处!

更新:我知道 不 同意创新和标准化是对立的。事实上,如果我们仍然拥有20世纪80年代特有的网络标准的混乱局面,我们的网络创新水平会接近吗?不,我们不会。当然,我们可能在新的低级网络协议上有更多的创新,但这真的值得吗?取而代之的是,在tcp/ip和web标准(http、html等)的范围内,我们的创造力得到了极大的发展。

诀窍是知道如何标准化,而不把它作为结束所有新探索的理由。例如,在我的公司中,我们只使用asp.net/c/sql server,但我完全愿意在此框架中使用新工具(例如,我们最近采用了devexpress报告包,取代了以前的标准)。

标准化是一个生产性开发团队的必备条件。然而,这并不意味着你不能不时地修订标准,以适应新技术和新趋势。

无论是为内部客户开发操作软件,还是为外部客户开发产品,都没有令人信服的理由 不 标准化。你当然没有给。 如果你看到公司是如何努力将已经维持了10年或更长时间的异质产品结合在一起的,并且现在是一个由各种技术组成的企业集团,开发人员在某种程度上认为这是有道理的,你就不会问这个问题了。

从我的头顶上,我可以说出至少两个著名的软件公司,因为它们的维护成本太高,无法再竞争(但我不会)。

我认为这里的误解是压制个人主义会压制创新。这根本不是真的。阻碍创新的是糟糕的技术领导。

标准化的一个令人不快的后果是,它往往会扼杀创新。

创新是可怕的。这涉及到成本和风险。

标准化并不可怕。它在短期内降低了成本和风险。直到你的竞争对手创造出改变游戏规则的创新。那么标准化是非常昂贵的。

这取决于我认为的组织。像微软,是的,应该有一点标准。一家只有一个IT部门的小公司,没有。一家在全球有多个办事处的大公司…也许吧。

这取决于-p

假设公司有一套广泛的企业应用程序需要管理,我会说不,原因如下,尽管我可能会认为 一切都一样 有点太夸张了:

• 对系统使用同类最佳的折衷方案,例如,如果所有数据库都是MS-SQL,则会抛出任何Oracle DB解决方案。这也适用于这样一个事实:每个使用ide的人都必须使用同一个ide,无论他们是在进行数据仓库报表开发、web应用程序、控制台应用程序还是winforms。我在考虑像erp、crm、scm、cms、sso和其他各种tla、flas和sla的系统。(LA=解码提示的字母缩写,如果需要的话)

• 委员会升级是另一个有趣的问题。如果每个团队都可以选择他们的工具,并且有一个人决定升级,例如开始使用visual studio 2008而不是visual studio 2005,那么现在必须确定在多大的阈值下同时升级每个人是值得的,如果开发人员超过几个,这可能是一个大问题。例如,在过去的10年中,什么时候会有ide更改、框架更改等?

• 标准的例外情况。如果承包商认为可以帮助他们构建更好的软件,例如resharper或其他一些承包商认为非常值得的附加组件,而公司不想花这些钱去获得,那么他们是否可以引入一些在组织中不使用的东西?如果遗留系统可能会使标准变得有些笨拙,例如,它是在asp.net 1.1中构建的,所以每个人都必须安装vs 2003,即使大多数人永远不会使用它?

只是我的想法。

标准化有几个好的理由。

首先,如果每个人都或多或少地熟悉相同的事情,它允许企业具有更好的组织灵活性。它还允许人们更好地互相帮助。我无法帮助解决asp.net方面的问题,在c++方面也没有那么多人能帮我。

其次,它减少了支持问题和开支。Oracle和SQL Server都是不错的产品,但将两者用于类似的功能只会导致问题。更不用说,我在商店里用过几个大不相同的平台做过类似的事情,这并不好玩。

第三,有些事情需要标准化。我们不能用VS2005和VS2008操作一半,因为我们将项目文件置于源代码控制之下。我们得挑个时间转换一下。

第四,在一些企业,它简化了监管问题。我不知道你在做什么生意。我在一个地方工作,现在我们可以不犯错误,但我也在一家银行和一家公用事业公司签约,在那里必须能够向审计人员表明,一切都在以一种标准的方式进行。

第五,如果你处理的是花钱的软件,它可以简化采购。

这并没有特别限制我们,因为如果我们需要的东西不是标准化的,我们就去做或者去做。

如果你想做一个反对标准化的商业案例,你需要一个与商业相关的论据。你的论点似乎是你无法实现用户想要的功能,这是一个考虑因素。还有争论吗?

在一个足够丰富的ide上进行标准化,以便为单个开发人员配置,这没有什么错。

但是,请确保您不会阻止个别开发人员使用其他工具,只要这些工具获得许可,并且一个开发人员使用该工具不需要所有其他开发人员使用它。

例如,我碰巧用 NORMA 帮助我设计数据库。输出是sql server ddl(或任何我想要的东西)。我可以将ddl作为项目的一部分,而不必将norma源作为项目的一部分。以后的开发人员不需要使用norma来处理项目。

另一方面,如果我决定使用 Configuration Section Designer 要创建配置部分,未来的开发人员也必须使用它。是否使用该工具需要作出决定。

我工作的公司使用c,asp.net,javascript并生成html。与上述优点相比,上述优点是可以感知到维护和自适应更改的速度有所提高。缺点包括给那些技术熟练(极客)的人带来一些无聊感,他们喜欢使用混合和匹配的语言,这取决于他们喜欢什么更适合,或者出于“性能原因”。

当你在一个高度饱和的网络开发市场上快速开发以满足紧迫的期限和竞争时,技术和个人监督总是很好的。