BackgroundDevelopers often have to locate design problems in the source code. Several types of design problems may manifest as code smells in the program. A code smell is a source code structure that may reveal a partial hint about the manifestation of a design problem. Recent studies suggest that developers should ignore smells occurring in isolation in a program location. Instead, they should focus on analyzing stinkier code, i.e., program locations—e.g., a class or a hierarchy—affected by multiple smells. There is evidence that the stinkier a program location is, the more likely it contains a design problem. However, there is no empirical evidence on whether developers can effectively identify a design problem in stinkier code. Developers may struggle to make an analysis of inter-related smells affecting the same program location. Besides that, the analysis of stinkier code may require proper tool support due to its analysis complexity. However, there is little knowledge on what are the requirements for a tool that helps developers in revealing stinkier program locations. As a result, developers may not be able to identify design problems due to tool issues.MethodTo address this matter, we aimed at achieving three goals. In the first case, we proposed Organic—a tool supporting the analysis of stinky code. In the second case, we applied a mixed-method approach to analyze if and how developers can effectively find design problems when reflecting upon stinky code—i.e., a program location affected by multiple smells. We conducted a study with 11 software professionals. Finally, in the third case, we aimed at understanding if Organic could be used by developers to identify design problems. To achieve this goal, we used a method from the Semiotic Engineering theory. This method enabled us to evaluate what are the tool issues that may hinder the identification of design problems in stinky code.ResultOur study revealed that only 36.36% of the developers found more design problems when explicitly reasoning about multiple smells as compared to single smells. Moreover, 63.63% of the developers reported much lesser false positives when using the first approach as compared to the latter. The second study, in its turn, showed that most developers may be unable to identify design problems in stinky code without proper tool support.ConclusionOur experiences, in particular the second study, helped us to refine the features of Organic for better supporting developers in reflecting upon stinkier code. For example, analyses of stinky code scattered in class hierarchies or packages is often difficult, time-consuming, and requires proper visualization support. Moreover, without effective support, it remains time-consuming to discard stinky program locations that do not represent design problems.

中文翻译：

---

关于臭代码设计问题的识别：经验与工具支持

背景开发人员经常需要在源代码中定位设计问题。几种类型的设计问题可能表现为程序中的代码异味。代码异味是一种源代码结构，它可以揭示有关设计问题表现的部分提示。最近的研究表明，开发人员应该忽略在程序位置孤立发生的气味。相反，他们应该专注于分析更糟糕的代码，即受多种气味影响的程序位置（例如，类或层次结构）。有证据表明程序位置越臭，它就越有可能包含设计问题。然而，没有经验证据表明开发人员是否可以有效地识别更糟糕的代码中的设计问题。开发人员可能很难对影响同一程序位置的相互关联的气味进行分析。除此之外，由于其分析的复杂性，对臭代码的分析可能需要适当的工具支持。但是，对于帮助开发人员揭示更糟糕的程序位置的工具的要求是​​什么，知之甚少。因此，开发人员可能会因为工具问题而无法识别设计问题。 解决这个问题的方法，我们旨在实现三个目标。在第一种情况下，我们提出了 Organic——一种支持分析臭代码的工具。在第二种情况下，我们应用混合方法来分析开发人员在反思臭代码（即受多种气味影响的程序位置）时是否以及如何有效地发现设计问题。我们对 11 位软件专业人员进行了一项研究。最后，在第三种情况下，我们旨在了解开发人员是否可以使用 Organic 来识别设计问题。为了实现这一目标，我们使用了符号工程理论中的方法。这种方法使我们能够评估哪些工具问题可能会阻碍在臭代码中识别设计问题。结果我们的研究表明，与单一气味相比，在明确推理多种气味时，只有 36.36% 的开发人员发现了更多的设计问题。此外，与后者相比，63.63% 的开发人员在使用第一种方法时报告的误报要少得多。第二项研究反过来表明，如果没有适当的工具支持，大多数开发人员可能无法识别臭代码中的设计问题。结论我们的经验，尤其是第二项研究，帮助我们改进 Organic 的功能，以便更好地支持开发人员进行反思在更臭的代码上。例如，分析分散在类层次结构或包中的臭代码通常很困难、很耗时，并且需要适当的可视化支持。此外，如果没有有效的支持，丢弃不代表设计问题的臭程序位置仍然很耗时。