过程式编程与面向对象编程的开发成本?

所有这些问题中的大多数都被一个问题所混淆,即单个程序员的生产力相差一个数量级或更多;如果你碰巧有一个OO程序员是生产力x团队中的一员,还有一个“过程式”程序员是10倍程序员,那么即使OO在某种意义上更快,过程式程序员也很容易获胜。

还有一个问题是,在一个现实的项目中,编码生产力通常只占总工作量的10-20%,因此更高的生产力没有多大影响;即使是那个假想的10倍程序员,或者一个无限快的程序员,也无法将总体工作量减少超过10-20%。

你可以看看弗雷德·布鲁克斯的论文 "No Silver Bullet" .

在谷歌搜索后,我找到了这篇论文 here 。我使用的搜索词是面向生产力对象的。

开头几段接着说

面向对象简介 技术似乎没有阻碍 新大型企业的整体生产力 商业项目,但两者都不是 前两项似乎有所改善 产品世代。在实践中 统治影响力可能是 业务工作流程,而不是 方法论。

我想你会发现面向对象编程在特定情况下更好,但对其他一切都是中立的。将公司的CAD/CAM应用程序转换为面向对象的框架,让我的老板们信服的是,我准确地展示了它将有所帮助的确切领域。重点不是整个方法论,而是它将如何帮助我们解决我们遇到的一些具体问题。对我们来说,有一个可扩展的框架来添加更多的形状、报告和机器控制器,并使用集合来消除旧设计的内存限制。

面向对象或过程提供不同的开发方式,如果管理不善,两者都可能成本高昂。

如果我们假设这两种情况下的工作都是由最优秀的人完成的,我认为就成本而言,结果可能是相等的。

我相信成本差异将取决于你的表现 维护阶段 您需要添加功能和修改当前功能。程序性项目更难进行自动测试,不太容易在不影响其他部分的情况下扩展,也更难逐个理解概念(因为有凝聚力的部分不需要分组在一起)。

因此,我认为,从长远来看,面向对象的成本将低于程序成本。

我认为S.Lott指的是“不可重复的实验”现象,即你不能按程序编写应用程序X 倒带时间 并将其写为OO,看看有什么区别。

你可以用两种不同的方式编写同一个应用程序两次,但是

• 你将通过第一种方式了解应用程序的一些信息,这将在第二种方式中对你有所帮助,以及
• 根据您的经验、应用程序的性质和所选工具,您可能更擅长OO而不是过程化,反之亦然

所以真的没有 直接的 比较依据

由于类似的原因,实证研究同样无用——不同的应用、不同的团队等。

范式转换是困难的,一小部分程序员可能永远不会进行转换

如果你可以自由发展 你的方式 ,那么解决方案很简单:以你的方式开发东西,当你的同事注意到你在他们周围编码,你的代码几乎不经常坏等等,他们问你是怎么做的,然后教他们OOP(以及TDD和你可能使用的任何其他好实践)

如果没有,那么也许是时候润色简历了。.. ;-)

好主意。头对头的比较。以过程风格和面向对象风格编写应用程序X,并对其进行度量。开发成本。投资回报。

用两种风格编写同一个应用程序意味着什么?这将是一个不同的应用程序,不是吗?程序化人员会阻止OO人员在使用继承、消息传递或封装时作弊。

不可能有这样的比较。比较应用程序的两个“版本”是没有依据的。这就像问苹果或橙子作为水果是否更具成本效益。

话虽如此,你必须专注于其他人能看到的东西。

1. 是时候建造一些有用的东西了。

2. 错误和问题的发生率。

如果你的方法更好,你就会成功,人们会想知道为什么。

当你解释OO会导致你的成功。…好吧。…你赢了这场争论。

关键是时间。公司需要多长时间来更改设计以添加新功能或修复现有功能。你所做的任何研究都应该集中在这个领域。

我的公司在90年代中期使用VB3创建了一个面向事件驱动程序的CAM软件设计。使软件适应新机器需要很长时间。测试bug修复和新功能的效果需要很长时间。

随着VB6的出现,我能够绘制出当前的设计和一个解决测试和自适应问题的新设计。这位非技术型老板立刻明白了我在做什么。

关键是要解释为什么OOP将使项目受益。使用Fowler的重构和设计模式来展示新设计将如何缩短做事的时间。还包括你如何从A点到达B点。重构将有助于展示你如何拥有可以交付的工作中间阶段。

我想你找不到这样的研究。至少你应该定义一下你所说的“成本”是什么意思。由于面向对象编程的设计速度较慢,因此使用过程式编程进行短期开发可能会更快。在很短的时间内,意大利面条编码可能会更快。

但当项目开始发展时,情况正好相反,因为OOP设计最适合管理代码复杂性。

因此,在一个小项目中,程序化设计可能更便宜,因为它更快,也没有缺点。 但在一个大项目中,只使用像过程式编程这样的简单范式,你很快就会被卡住

我怀疑你会找到一个明确的研究。正如一些人提到的,这不是一个可重复的实验。你会发现很多轶事证据。有些人可能会找到一些统计研究,但我会仔细研究它们。我不知道有什么真正好的。

我还将提出另一点,在现实世界中没有纯粹面向对象或纯粹程序化的东西。许多(如果不是大多数)对象方法都是用过程代码编写的。同时,许多过程式程序使用面向对象的方法,如封装(也有人称之为抽象)。

不要误解我的意思,面向对象和过程式程序看起来和实际情况不同,但这是一个深灰色和浅灰色的问题,而不是黑白的问题。

这 article 没有提到OOP与Procedural。但我认为你可以使用你公司的类似指标进行讨论。

我发现这很有趣,因为我的公司开始探索 ROWE 主动权。在我们的第一次会议上,很明显,我们目前没有获得足够的结果指标。

因此,您需要关注1)当前流程的维护是否会阻碍未来的发展?2)不同的方法将如何影响#1?