我被要求给出一个关于公司应用程序大小的度量标准。有问题的应用程序是一个基于 Web 的应用程序,我不确定如何量化它的大小。明显但无用的指标是代码行数、文件数量等。有哪些建议的方法可以确定应用程序的大小,从而提供真正的意义?
申请注意事项:
- 基于 ASP.NET Web 窗体的 C# 应用程序
- 分层架构
- 所有数据库交互都通过存储过程
我被要求给出一个关于公司应用程序大小的度量标准。有问题的应用程序是一个基于 Web 的应用程序,我不确定如何量化它的大小。明显但无用的指标是代码行数、文件数量等。有哪些建议的方法可以确定应用程序的大小,从而提供真正的意义?
申请注意事项:
用户可以访问的“页面”或“区域”的数量
问题:这可以通过将部分分成不同的页面或部分来伪造,而将它们合并到一个单一的“控制中心”界面会更有意义。
班级数
问题:与其他类相比,这没有考虑某些类的复杂性(或简单性)。您可能有一个包含两个属性和一个方法的类,而另一个类可能是核心。
非查找表的数量
问题:这不会考虑您的软件的复杂性,只考虑它所依赖的数据层。与类数量相关的一些相同问题也可以在这里应用,因为某些表比其他表更复杂。
代码行
问题:这是一个相当标准的指标,但它对具有大量行的程序赋予了更多积极的含义,而不是鼓励更高效和优雅的代码。
开发需要多少工时
问题:在创建一个软件时,没有两个开发人员具有相同的技能,也没有两个开发人员可能会花费完全相同的时间(或遵循相同的路径)。因此,单个开发人员所花费的时间可能与由 3 名技术/经验较低的开发人员组成的团队编写相同数量的代码所花费的时间相同。此外,如果你开始让更多的人来解决一个问题,而不是真正需要,整个“神话人物月”就会开始抬头。
总的来说,我认为指标的最大问题是他们试图衡量软件的一些可量化的属性,而实际上软件是关于质量而不是数量的,这就是指标真正失败的地方。
SLOC(源代码行)是一种普遍接受的大小度量。
您的问题仅询问大小,但我敢打赌,您被要求提出这些指标,以便管理层可以确定支持此应用程序所需的工作量。在这种情况下,我也会查看代码的复杂性。
您可能想下载一个试用版的了解它适用于多种编程语言,它将为您提供所需的指标,免费试用版将持续足够长的时间来获得管理所需的数字。
至于指标,我会看看:
圈复杂度V(G) 是复杂度的一个很好的度量。
SEI 可维护性指数有助于了解维护代码库的难度。
代码与注释的比例至少为 15%,以及其他必要的高级和低级设计文档。意识到其中大部分都将过时,但它们仍然可以帮助您的员工入门。
测试覆盖率也是需要关注的其他内容。他们有单元测试吗?当你有一个很好的单元测试套件时,代码更容易维护,你可以运行它给自己一个“合理”的感觉,你没有破坏任何东西。80% 的测试覆盖率通常是最低要求。
功能点分析法,我认为适合大中型应用,独立于编程语言:
http://en.wikipedia.org/wiki/Function_point_analysis
分析的结果是一个功能点值,可用于估计执行时间。这种方法很容易理解和实现(使用简单的电子表格),但是它需要一些经验,因为计算中的一些关键因素是可变的。
有哪些建议的方法来确定将提供真正意义的应用程序的大小?
如果您找到了一个非常好的答案,请正确地写出来,好吗?
根据我的经验,代码指标几乎普遍都很糟糕。他们中的一些人只是很糟糕。
[附录]
公平地说,问题不在于“代码度量很烂”,毕竟它们只是度量(希望是定义明确的度量);问题是他们似乎从来没有衡量人们希望他们衡量的东西,而是像他们那样被使用。将这种滥用行为归咎于数字并不公平。
一个指标只有在你知道它的用途时才能提供真正的意义。你知道测量尺寸的目的吗?如果没有,请问。