程序式编程与OOP的开发成本？

我来自一个相当强大的OO背景,OOD和OOP的好处对我来说是第二天性,但最近我发现自己处于一个与程序编程习惯相关的开发工作室.实现语言具有一些OOP功能,它们不以最佳方式使用.

更新:每个人似乎对此主题都有意见,我也是如此,但问题是:

是否有任何良好的比较研究对比使用过程编程语言与面向对象语言的软件开发成本？

一些评论者指出了尝试将苹果与橙子进行比较的可疑性质,我同意准确测量是非常困难的,但也许并非完全不可能.

大多数所有这些问题都被个体程序员的生产率变化一个数量级或更多的问题所困扰; 如果你碰巧有一个OO程序员,他是生产力x的一员,而程序员是一个10x程序员,那么即使OO在某种意义上更快,程序程序员也有可能获胜.

还有一个问题是编码生产率通常只是实际项目总投入的10-20%,因此更高的生产率没有太大的影响; 即便是那个假想的10x程序员,或者是一个无限快速的程序员,也无法将整体工作量削减10-20%.

你可以看看Fred Brooks的论文"No Silver Bullet".

OO或程序提供不同的开发方式,如果管理不善,两者都可能成本高昂.

如果我们假设这两件作品都是由最好的人完成的,我认为结果在成本方面可能相同.

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

因此,我认为,与Procedural相比,OO成本从长远来看会更低.

在谷歌四处寻找之后,我在这里发现了这篇论文.我使用的搜索术语是面向生产力的面向对象.

开头的段落接着说

面向对象技术的引入似乎并没有阻碍新的大型商业项目的整体生产力,但它似乎在前两代产品中都没有改善它.在实践中,治理影响可能是业务工作流程,而不是方法.

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

我认为S.Lott指的是"不可重复的实验"现象,即你不能在程序上编写应用程序X然后倒回时间并将其写入OO以查看差异是什么.

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

你会学到一些有关应用程序的知识,这是第一种可以帮助你的第二种方式,并且

您可能在OO方面比在程序方面更好,反之亦然,这取决于您的经验以及应用程序的性质和所选择的工具

所以没有直接的比较基础

实证研究同样没用,出于类似的原因 - 不同的应用,不同的团队等.

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

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

如果不是,好吧,也许是时候擦亮简历...... ;-)