Which are the best techniques to be used for code and architectural debt identification?

We are particularly interested (University of Milano Bicocca-Software Evolution and Reverse Engineering Lab) in the identification of code and architectural issues that can be the source of technical debt at code and architectural level, in the automated support for the identification of these issues and in the prioritization of the most critical ones.

Our Work.
Respect to code level issues, we worked on code smells detection both through metrics-based and machine learning-based techniques (ESE-2015). Regarding the metric-based approach, we developed a code smells detection tool (JcodeOdor), we defined an Intensity Index to evaluate and prioritize the most critical smells to be removed (MTD2015) and we defined some filters to remove false positive instances (ICSE2015-poster, SANER 2016).

Respect to architectural level issues we performed an empirical study on the possible correlations existing among code smells and architectural smells. We are working also with other colleagues on the definition of a catalogue and classification of architectural smells.

We experimented different commercial and open source tools (e.g., inFusion, Structure101, Sonarqube, Sonargraph) with the aim to evaluate their support in the identification of architectural smells or other problems at architectural level, in the evaluation of the usefulness of the Technical Debt Index they provide (SAC2016), and the support these tools offer for the refactoring of architectural problems (WICSA2016). We observed and found many limitations in the tools and different problems to effectively use the computed Technical Debt Indexes, e.g.:
• Tools usually do not exploit historical and/or dynamic information to assess TD.
• Tools detect different relevant issues, and sometimes provide integration with IDEs to show issues in context, but they do not leverage the IDE features to trigger and automate refactoring operations.
• The way time/costs are associated to TD index values is arbitrary and not supported by evidence; even if the index provides a good approximation of TD, its prioritization suffers from this lack of a solid link with measures that can be used for decision-making.

Future Work
We are interested in defining and providing an Architectural/Technical Debt measure that can be effectively used and that takes into account also the history of a project. We also plan to enhance the detection of architectural smells by developing a new tool or collaborating with researchers already working in this direction. We would like also to exploit our experience in design pattern detection (JSS-2015) to enhance the identification of architectural smells, e.g., prioritizing architectural smells that affect subsystems considered more “critical” due to the presence of some specific design patterns.

Another direction we are interested in is the integration of data and software analysis to reach a more precise and holistic assessment of the debt of a system. We had some experience of this kind (JSME-2013) in recovering conceptual schemas from data-intensive systems.