This section provides a list of implications and recommendations derived from the analyses presented in the six papers.
The results in Paper 1 indicate that the correspondence between code-smell-based system- level measures and maintenance outcome measures depends on whether the systems are of similar sizes or not. When systems of similar sizes are compared, we may use code smell density. Otherwise, we may benefit from using the number of code smells to indi- cate differences in maintainability, as measured by maintenance effort and defects. Our analysis comparing different system-level maintainability assessment approaches indicates that such assessments are likely to benefit from the use of expert judgment. Expert judg- ment, given a good expert, provides a higher chance of adapting to different maintenance contexts, such as the differences related to the complexity of the tasks, the size of the systems, and the maintenance goals. We do, however, believe that expert judgment and code smells complement each other because code-smell-based analyses may sometimes spot potentially problematic areas of the system missed by the expert. Consequently, we recommend the use of code smells in combination with expert judgment to support more comprehensive and accurate system-level assessments of maintainability.
The results in Paper 2 suggest that file size and number of revisions are stronger indicators of effort to maintain a file than the presence of code smells. This implies that to reduce the reading and updating effort of a file during maintenance work, it is more important to strive for the reduction of a code rather than the removal of any specific code smell. Also, the presence of the code smell Refused Bequest indicates a significantly less reading and updating effort of that file. A similar result was found for the code smell Data Clump in the study reported in Paper 3. This suggests that in some contexts, there may be potentiallypositive effects from the presence of some code smells. Based on this result, we recommend that at least these two code smells be investigated further to determine if the underlying concept of the code smell has, in fact, positive effects on maintainability or if the detection strategy used for the code smell leads to false negatives (i.e., investigate whether there is a lack of correspondence between the original concepts of the code smells and their detection implementations).
The results in Paper 3 indicate that the ISP Violation in a file leads to a higher like- lihood of that file being problematic during maintenance. An exploratory factor analysis indicates that ISP Violation and Shotgun Surgery tend to occur in the same file and are rather independent of the factor related to the size of a file. These two code smells aresize-independentindicators of problematic codes. We recommend examining for their presence in the files to identify potentially problematic areas and to prioritize refactoring efforts. Paper 3 also reports that the study of interaction effects between code smells and between a code smell and other design flaws should be investigated further to understand better the effects of code smells. This is similar to the notion of inter-smell relations, as proposed by Walter and Pietrzak [148]. A potentially meaningful approach for analyzing
the interactions between code smells is to observe and analyze the effects of code smells collocated in the same file on maintainability by using the exploratory factor analysis we applied in Paper 3.
Paper 4 reports that only about 30% of the total amount of maintenance problems could potentially (best case) be explained and predicted by the presence of code smells. This means that aspects covered by current code smell detection methods may have a relatively low potential in explaining and predicting outcomes of a maintenance project. These results may, to some extent, explain the findings reported in Papers 2 and 3 (i.e., the lack of significant coefficients for most of the code-smell-related variables in the regression analyses). This supports the recommendation that code smell analysis should be done in combination with alternative maintainability assessment strategies, such as expert- judgment-based assessments.
Additional observations led us to believe that we should have only a modest expec- tation of the explanatory and predictive power of individual code smells in relation to software maintainability. Paper 4 reports that interaction effects occur between code smells and between code smells and other design flaws. This implies that the current ap- proach for code smell analysis (i.e., analyzing individual smells and not the effect of their combinations) limits the capability of code smells to explain much of the maintenance problems caused by design flaws. Another limitation of the current approaches for code smell analysis is that couplings among elements containing code smells (e.g., files contain- ing code smells) are not considered in the analyses. The findings from Papers 3 and 4 indicate that interaction effects between code smells distributed across coupled files may have the same consequences from a practical perspective as interaction effects between code smells collocated in the same file. This last finding implies a serious consideration for further studies on code smells and a need to include dependency analyses to provide a better understanding of the role of code smells in software maintenance.
In the analysis in Paper 5, many maintainability factors deemed critical not only by the software experts in Ref. [6], who evaluated the maintainability of the four systems, but also by the developers who maintained the systems, were not addressable via code smell analysis. This result supports the recommendation that alternative approaches should be combined with code smell analysis to achieve better assessments of maintainability. Based on the maintainers’ assessments, the development and improvement of detection strategies that focus on code smells related to the factor “design consistency” should be prioritized, perhaps including the development of new code smells.
Results from Paper 6 imply that there are proven methods/techniques outside the software engineering domain that can be used to address some of the challenges and limitations entailed by maintainability assessments based on code smells. We propose the
use of concept mapping as a promising technique for this purpose.