不同语言发展的相对成本研究
Posted
技术标签:
【中文标题】不同语言发展的相对成本研究【英文标题】：Studies of relative costs for development in different languages 【发布时间】：2011-02-25 18:32:14 【问题描述】：有没有人看到最近（并且相当平衡）研究使用不同语言进行软件开发的相对成本？我特别想看看 Java Vs 的相对成本。 C# 对比德尔福。
【问题讨论】：
【参考方案1】：没有。但我并不热衷于任何一个，而是作为顾问工作，并根据我的每一个要求推荐其中一个。因此，这里有一些事实可以让您更轻松地选择使用什么来满足您可以拥有的系统开发需求。
共同点：
他们都是各自领域的佼佼者：
Java 是最好的 Java 开发选项。 C# 是最佳的 .NET 开发选项。 Delphi 是最佳的原生开发选项。他们都有：
提供优质组件和库的全球第三方供应商。 用它们创建的全球知名应用程序（例如 Delphi 的应用程序可能更为人所知：Yahoo Go for TV!、Macromedia Captivate、TotalCommander、MediaMonkey、FinalBuilder、InstallAware、WinLicense、mysql Administrator 等）。李>都是：
具有 RAD 功能的高度可靠的技术。 得到最佳开发辅助工具（UML 等）的支持。 发布其技术的重大升级（Java 7、.NET 4.0 和 Delphi 多平台）。区别：
C# 更好的三件事：
可用的开发人员数量（与 Java 相比）可以在其中编写代码 (*)。 微软落后了。 就工资而言（通常）更便宜的开发成本。Java 更好的三个方面：
可用的开发人员数量（与 Delphi 相比）可以在其中编码 (*)。 便携性。 太阳在后面。Delphi 在哪些方面更好：
速度（对时间要求严格的系统具有更好的性能）。 占用空间小（Delphi 编译器生成非常小的二进制文件）。 没有明确的依赖关系（更容易分发）。(*) 有一个非常可靠的事实，可以使用 C# 编写代码的其他语言开发人员比使用 Java 编写代码的其他语言开发人员要多，这意味着更容易找到 C# 程序员。也许这解释了为什么在许多允许多语言问题、重构等的网站和论坛中，通常有更多的 C# 问题和答案 (84k vs 50k)。此外，由于Java jobs are best paid 在世界许多地方，常识指出 Java 开发人员的工作时间比 C# 开发人员更长，这使得找到 Java 开发人员比 C# 开发人员更难。当然还有一些其他因素可以讨论，但我很确定找到 C# 程序员通常比找到 Java 程序员更容易。
【讨论】：
您是否有任何链接可以为此提供证据？据我所知，Java 开发人员比 .NET 开发人员多。 @stevendick：这方面的研究结果差异很大，具体取决于问题的提出方式。例如，如果您问“我是一名我不了解正式的研究，但我听说过很多关于公司在 Delphi 中使用现有应用程序并出于某种原因用 C# 重写它的轶事。它们都以相同的方式结束。
用 C# 重写程序所用的时间是最初用 Delphi 编写程序所用时间的两倍，即使所有业务逻辑和领域知识已经制定并以现有 Delphi 代码库的形式呈现。在此期间，他们没有发布更新，因为他们所有的资源都忙于重写，从而让他们的竞争对手获得市场份额。而当它完成时，它是一个1.0级别的产品。故障、缓慢且难以使用，通常存在严重的向后兼容性问题。
对解释持开放态度的原因，但我认为让 Delphi 比 C#（或 Java）更高效的主要因素之一是语言的外观和感觉。
众所周知，维护和调试现代程序比最初编写现代程序需要更多的工作、时间和精力，但通常不会遵循该原则得出其合乎逻辑的结论。如果最需要的工作是维护程序，那么根据编写代码的容易或快速来选择一种语言就是过早的优化。如果您使用一种易于阅读和维护的语言，您将获得更好的投资回报。在代码可读性方面，Pascal (Delphi) 毫不逊色地击败了 C 系列。 p>
这不是正式的研究，但值得思考。
【讨论】：
说得很好。我会稍微改进一下——仍然可以用 Pascal 编写“坏”代码，但通常你必须不遗余力地这样做......同样可以用花括号语言编写“好”代码，但同样，你必须不遗余力地这样做。即帕斯卡 - 通常 - 会在相同的努力下产生更好的结果。 我认为 Delphi 是 C 语言家族的一员。 Delphi 和上面提到的其他语言之间唯一的主要语法区别是它使用begin 和end 而不是花括号来表示块范围。
@Don：那是完全错误的。一方面，Pascal 是在 C 之前创建并影响了它的设计，而不是相反。所有的控制结构都有不同的语法，尤其是 for 和 case。声明变量的规则非常不同。在 C 系列中，任何东西都可以是布尔值，这会导致各种丑陋的语法（Yoda 条件、布尔运算符的单独逻辑和按位版本等），而在 Pascal 中，布尔值是编译器定义明确的类型明白。我可以继续，但我的字符不多了。不过，它们完全不同。
@Mason - 但是 Delphi 不是 Pascal，而是 Oobject Pascal，它是在 C 之后创建的。说一种语言属于 C 家族意味着它看起来与 C#、Java、C++ 大体相似等。这并不意味着它与 C 完全一样。从宏观上看，我仍然认为 Delphi 看起来与这些语言大体相似，不像 Lisp、Ruby、SQL 等。
@Don：我想你要找的是 C 和 Pascal（以及他们所有的后代）都是 Algol 家族的成员。【参考方案3】：
由于复杂变量的数量，这种定量比较很难确定：开发人员使用该语言的经验、该语言对目标领域的适用性、开发人员的整体质量（有人认为非- 主流语言吸引更高质量的开发人员），与最终产品的权衡（Ruby 或 Python 应用程序是否与编写良好的 Delphi 或 C++ 应用程序一样快？）等。
在Code Complete, 2nd Ed. 中，Steve McConnell 列出了几种语言的表达能力（每种语言的单个语句可以表达多少行等效的 C 代码）。有人建议，无论语言如何，程序员在代码行中的生产力都是相对恒定的。如果这是真的，那么每种语言的表达能力应该粗略估计每种语言的相对开发成本。来自第 62 页的表 4.1：
相对于 C 的语言水平 C 1 C++ 2.5 Fortran 95 2 Java 2.5 Perl 6 蟒蛇6 小话 6 视觉基础 4.5他列出了该表的几个来源：Estimating Software Costs、Software Cost Estimation with Cocomo II 和“七种编程语言的实证比较”（Prechelt，来自 IEEE 计算机，2000 年 10 月）。
McConnell 引用的数据都是几年前的数据，但据我了解，Cocomo II 模型非常详细，因此当前的 Cocomo II 材料可能会提供 Delphi 和 C# 的最新数据。
【讨论】：
麦康奈尔的数据已经过时了； .NET 语言（VB 和 C#）从那时起有了巨大的进步，尤其是泛型和 LINQ。 LINQ 在 .NET 中添加了函数式编程能力，这会大大影响生产力数据。 我认为这个论点是有缺陷的，因为它假设开发人员花费了 100% 的时间编码，而没有提及所生成代码的质量。对于许多项目来说，这个百分比接近 30%（我认为来自神话人月。） +1 指出编码不是花费大部分时间的地方。我从未见过一个项目因为使用的语言而被取消或迟到（当然，假设是合理的选择）。 我在某处听说 java 和 c++ 并不完全相等......Java 2.5 和 c++ 2.6 或类似的东西......它与数千个 LOC 的大型项目相关【参考方案4】：我从未寻找过这样的研究，但如果存在的话，我会感到惊讶。任何旨在以适当的科学方式衡量和比较多种语言的实际开发成本的实验都非常昂贵。
正确地做：
您需要在一系列应用程序域中指定一些重要的项目。
您需要组建多个项目团队，每个团队都由在使用其中一种语言开发大型应用程序方面具有丰富经验的开发人员组成。
然后，您需要针对每种语言对每个项目实施 N 次 ... 以获得具有统计意义的结果。
因此，您需要相当于project-size * nos-languages * nos-projects * nos-repetitions 的开发人员工作量。假设一个不平凡的项目需要 1 个人年，即有 5 个项目，并且它们在每种语言中被开发了 5 次（为我们提供足够大的样本量以具有统计意义），即 25 经验丰富的开发者年。 .. 说 200 万美元到 500 万美元... 每种语言检查。
这些数字（显然）是凭空捏造的，但我的观点是，对不同语言的开发成本进行适当的科学比较会非常昂贵。
即使那样，研究结果也不会解决：
持续的可维护性/维护成本， 数字如何扩展到大型项目， 团队规模的语言特定影响， 各种语言的开发工具的可用性、成本和收益， 为每种语言组建经验丰富的团队的难易程度， 等等。结果会在 3 到 5 年后过时。
【讨论】：
【参考方案5】：Peopleware (by Tom DeMarco and Timothy Lister) 包含第八章中关于“编码战争游戏”的部分。从 1984 年到 1986 年，有超过 600 名开发者参与。
在对游戏结果的分析中，他们发现编程语言与性能的相关性很小或没有相关性。 （只有汇编语言参与者被所有其他语言组严重落后）
【讨论】：
【参考方案6】：美国空军很感兴趣，发现 Delphi 的编码速度明显更快。每年的 C++ 竞赛都会吸引速度编码团队参加比赛。 Delphi 编码员掩盖了这场竞争，并且几乎总是能以更快的速度完成所需的代码。
在担任空军开发主管之后，我的前任老板 Bill Roetzheim 写了一本关于估算软件开发成本的书。他的选择，最重要的是德尔福。那是版本 3/4。 Rational 使用了他的估计模式。我仍然在使用它，并且在我一直这样做的这些年里没有比这更好的了。
设计的清晰性和代码表达的力量在版本中没有太大变化。大多数时候，您都在关注视觉变化和增量增强。 20 年前的核心最佳实践仍然适用。这就是使建筑成为可能的原因。我们知道最佳实践是什么样的，因为在一定规模下，代码必须符合一组变化不大的标准要求。您几乎总是可以使它更好用，或者减少笨拙笨拙的界面，但是使业务系统工作的数据、安全/过滤和工作流系统仍然使用与 GoF 设计模式一书中相同的设计模式。如果小型设备教会了我们什么，那就是强烈的清晰度和简单性值得称赞。您的代码库用于此目的的难易程度非常重要。所有主要环境都可以很好地进行域设计。系统的速度和易于开发使 Delphi 和 Node.js 成为我的两个后端偏好。但是能力方面的 C# 和 Java 都很好。如果我担心环境对开发人员的安全性，我会在某些情况下选择 C#，因为编码人员更难违反规则。但是当我不需要这些规则时，即大多数时候，我更喜欢可扩展的更开放的环境。当我不太关心安全性时，我可能更喜欢 Node.js，因为它可以快速完成。大多数时候我发现在 Node 中犯错误太容易了，我最终需要完整的测试代码覆盖率。总的来说，Delphi 是我的首选。
【讨论】：
【参考方案7】：“开发人员的素质”很难衡量。 Java 和（在较小程度上）C# 在学校和大学中被大量用于培训学生的编程基础。 其中许多最终出现在带有家庭作业问题的支持论坛上，并且会以某种方式被视为使用该语言的程序员（和可怜的程序员）。 实际上，他们中的绝大多数人在完成那门必修的入门课程后永远不会编写一行代码，而其余的大多数人可能不会用那种语言编写代码。
---关于程序员能力的“比较研究”的咆哮完成---
如前所述，即使不是不可能，也很难对用不同语言实现某些东西进行成本比较估算，至少作为适用于所有项目的一般情况。 有些东西更适合 .NET，另一些更适合 Java，还有一些可能最好在 Excel 宏中完成。
而且开发成本通常只是系统 TCO 的一小部分，尤其是当它是在具有数据库等的应用服务器上运行的多层应用程序时。 如果客户已经拥有一个运行 IIS 并以 MS SQL Server 数据库作为后端的服务器群，那么向他们出售使用 Oracle 后端的 Java EE 应用程序就是对他们的损害，即使这对于应用程序而言是最合乎逻辑的选择。 开发成本可能会更低，但客户的运行成本会高得多。
另一方面，您的街角杂货店希望开始通过网络接受订单以便在附近送货的网站不应该在 .NET 或 Java EE 中实现。解决方案的成本（尤其是托管）将远远超过收益。 基于例如 php 或 rails 的简单事物将为该客户提供更好的服务。托管成本降低，无需支付昂贵的数据库和应用程序服务器许可费用，他实际上可能会使用生成的网站赚钱。
【讨论】：
【参考方案8】：正如其他人所说，没有研究......因为没有人感兴趣。没有可测量的差异。拿几乎任何关于项目管理的书来说，你都会看到没有提到语言，除非有例子，也没有依赖特定的语言特性。大多数时候，项目生命周期中的任何花钱问题都不是编码问题，而是架构和组织问题。
为了正确看待问题，如果您遇到语言的严重缺陷并且必须实施一些解决方法 - 您会损失几个小时。维护人员可能会花费更多时间来了解您在那里做什么以及为什么要这样做 一两天的工作日将会丢失。好吧，如果你带着错误的心情来工作，你会在同一天失去。如果您在理解需求或与同事和管理层沟通时遇到问题，您很容易损失数周甚至数月的时间。
【讨论】：
如果没有研究，那我们怎么知道“没有可测量的差异”呢？或者这仅仅是一个教条？ ;)以上是关于不同语言发展的相对成本研究的主要内容，如果未能解决你的问题，请参考以下文章