有人有使用合同设计指标的经验吗？或者可以推荐指标来衡量合同设计在代码库中的使用情况？
目前，我们正在向大约 60 名开发人员组成的软件开发团队引入合同设计，他们正在开发不同的组件。我们首先为 C# 和 Java 定义合同设计策略。为了衡量进度，我们通过简单搜索关键字（不包括注释和字符串文字）来计算类的数量和契约断言（先决条件、后置条件和不变量）的数量。所以我们有两个统计数据：
- 每个合同断言的数量 组件
- 每个组件每个类的合同断言的平均数量
是否有人有使用合同设计指标的经验，或者可以推荐指标来衡量代码库中合同设计的使用情况？
We are currently introducing Design-by-Contract to a software development group of about 60 developers, which are developing different components. We started by defining Design-By-Contract policies for C# and Java. To measure the progress we are counting the number of classes and the number of contract assertions (Preconditions, post conditions and invariants) with a simple search for keywords (excluding comments and string literals). So we have two statistics:
- Number of contract assertions per
component - Average number of contract assertions per class per component
Has someone experiences with metrics for Design-By-Contract or can recommend metrics to measure the usage of Design-By-Contract in a code base?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为你的第一步应该是对签入的所有新代码进行代码审查。
除非你让所有代码都变得“正常”，否则我看不到自动检查工具的工作
你的程序员使用“合同设计”
也许在表格上包含代码审查的结果，作为决定程序员是否加薪的过程的一部分会有所帮助。
I think you first step should be code review of all new code that is checked in.
I can’t see an automated checking tool working until you have make it “normal” for all
your programmers to use “Design-By-Contract”
Maybe include the results of the code reviews on the form that is filled in as part of the process of deciding if a programmer will get a pay increase will help.
我建议像查看单元测试一样查看合同，尝试通过不变量和后置条件以及先决条件的检查参数数量来衡量代码的覆盖率。
I would suggest looking on the contracts the same way you look at unit tests, try to measure the coverage of code by invariants and postconditions and number of checked arguments for preconditions.