Question

设置场景 - 我在其中一个喜欢估计和跟踪几乎所有内容的行业中工作。我们的一个关键指标是SLOC（源代码行 - 声明性和可执行语句）。我们将其用于项目规模和成本估算，项目规划以及许多其他方面。我们尝试用它来比较苹果和苹果（即，我们不将一种语言/域中的SLOC与另一种语言/域中的SLOC进行比较）。注意：我们不会根据此指标评估各个开发人员，也不会因为SLOC与预期不同而调用错误或错误。我们做，但是，考虑一个项目有更多的SLOC可能也有更多的错误。

最近，我开始研究使用库代替组件的项目，否则这些组件将被手工编码 - 例如JSF而不是JSP，Hibernate而不是JDBC等等。所以......而不是写作代码行，我们的团队正在开发XML文件。 XML映射仍然需要付出努力，并且复杂性仍然存在模糊关联 - 在给定项目中，如果将这些XML配置文件中的100倍更多，可能会表明创建需要花费更多精力，并且调试可能比仅使用项目更复杂1/100的XML文件。

那么......有没有人有任何关于测量这些XML配置文件大小的建议？元素数量？＃elements + #properties？别的什么？

Answer 1

有趣的问题。我所知道的唯一指标（除了按照您的建议计算节点和属性之外）就是称为结构化文档复杂度指标。

http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_5_str_1.html

目前我能找到的最佳链接（已经有一段时间了）。我还发现了这个小工具，显然会为你计算它（可能还有其他的）：

http://schematron.com/resources/documentcomplexitymetric.html

除此之外，我担心我唯一的建议就是选择一些跟踪看似合理的指标，然后重新评估它们以确定它们是否确实在应用于每个文档的情况下做出趋势。

Answer 2

首先我要说的是，基于这样的标准评估项目与评估基于同一事物的程序员一样愚蠢。我知道有研究表明代码行数和代码缺陷的nuber之间存在明显的相关性。在我看来，这仅仅是规模扩大的问题。

话虽如此，如果你的霸主......错误......我的意思是管理层要求你想出一些东西，这是一些相对简单的测量方法：

节点总数
节点类型数
每个节点的平均属性
最高级别的嵌套

Answer 3

好吧，如果您只是根据基本的SOAP / WSDL操作，消息和类型将模式映射到结构，那么您可以将这些方面中的每一个等同于它的相应方法，消息和类。

例如......客户架构如下：

  <?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:tns="http://tempuri.org" 
           targetNamespace="http://tempuri.org"
           xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Customer">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="FirstName" type="xs:string" />
        <xs:element name="LastName" type="tns:LastNameType" />
      </xs:sequence>
      <xs:attribute name="CustID" type="xs:positiveInteger"
                    use="required" />
    </xs:complexType>
  </xs:element>
  <xs:simpleType name="LastNameType">
    <xs:restriction base="xs:string">
      <xs:maxLength value="20"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

...等同于Customer类......

public class Customer
{
    public string FirstName{}
    public string LastName{get;set;}
    etc...
}

通过这种方式，您可以继续以相对比例继续使用当前的SLOC基准。

问题在于，编写XML模式并不能真正考虑到编写Java或C＃程序时LOC的大变化。程序员可以用百万种不同的方式编写C＃类，因为模式定义更加结构化，并且实际上只允许操作，消息和变量名称的变化。因此，如果您现在只是编写XML而不是Java或C＃，那么您可能需要考虑您的SLOC指标在确定项目大小和错误方面所用的水量要少得多。

您如何衡量/估计XML编程工作的大小？

3 个答案: