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开发者_Go百科 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?
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.
精彩评论