The Results
Now that we have concrete definitions of changes and modules in each of our three systems, we can finally begin to investigate how developers work with these modules.
Change Locality
We begin our exploration with a simple question: are most changes to the code constrained to a single module? Figure 21-5 shows a histogram of the number of modules modified per change for each system, and Table 21-4 presents some summary statistics.
Table 21-4. Number of modules affected by each change
|
Project |
% changes affecting only one module |
Mean modules affected |
|---|---|---|
|
Evolution |
86.6% |
1.243 |
|
Firefox |
73.7% |
1.577 |
|
Mylyn |
69.7% |
1.634 |
Examined Modules
When making these code changes, how many modules does a developer consult? We can answer this question quantitatively for Mylyn given the availability of task context data, but not for the other two systems.
Figure 21-6 shows the number of modules that were examined by a developer for each change. The mean number of examined modules is 2.365, with a median of 2. The mean of examined modules is higher than the mean number of modules that are actually modified (1.634), which suggests that developers occasionally consult modules that they do not end up actually changing.
If we take a closer look at the modules that are examined but not modified in each change, we find two of Mylyn’s modules stand out. In 13% of changes, a developer examined the Tasks module without changing it, and in 8% of changes the same holds for the Bugzilla module. We might ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access