Abstract
Reading, adapting, and maintaining complex software can be a daunting task. We might need to refactor it to streamline the process and make the code cleaner and self-explanatory. Traditional refactoring tools guide developers to achieve better-quality code. However, the feedback and assistance they provide can take considerable time. To tackle this issue, we explored the concept of Live Refactoring. This approach focuses on delivering real-time, visually-driven refactoring suggestions. That way, we prototyped a Live Refactoring Environment that visually identifies, recommends, and applies several refactorings in real-time. To validate its effectiveness, we conducted a set of experiments. Those showed that our approach significantly improved various code quality metrics and outperformed the results obtained from manually refactoring code. © 2024 IEEE Computer Society. All rights reserved.

Abstract
Background: Approaches to documenting the software patterns of a system can support intentionally and manually documenting them or automatically extracting them from the source code. Some of the approaches that we review do not maintain proximity between code and documentation. Others do not update the documentation after the code is changed. All of them present a low level of liveness. Approach: This work proposes an approach to improve the understandability of a software system by documenting the design patterns it uses. We regard the creation and the documentation of software as part of the same process and attempt to streamline the two activities. We achieve this by increasing the feedback about the pattern instances present in the code, during development-i.e., by increasing liveness. Moreover, our approach maintains proximity between code and documentation and allows us to visualize the pattern instances under the same environment. We developed a prototype-DesignPatternDoc-for IntelliJ IDEA that continuously identifies pattern instances in the code, suggests them to the developer, generates the respective pattern-instance documentation, and enables live editing and visualization of that documentation. Results: To evaluate this approach, we conducted a controlled experiment with 21 novice developers. We asked participants to complete three tasks that involved understanding and evolving small software systems-up to six classes and 100 lines of code-and recorded the duration and the number of context switches. The results show that our approach helps developers spend less time understanding and documenting a software system when compared to using tools with a lower degree of liveness. Additionally, embedding documentation in the IDE and maintaining it close to the source code reduces context switching significantly.

Abstract
During the process of software architectural design, numerous questions arise which must be answered. These questions may be about requirements on the proposed system (the problem space) or about how the system should be designed and developed (the solution space). As questions arise they may be answered immediately, deferred until later, or provisionally answered with an assumption about the answer. The objective of this work was to explore the nature of questions that arise during architecture. We explored the types of questions, how they are organized, how they are tracked, and how and when they are answered. We started by surveying highly experienced architects about their practices with respect to architectural questions. We also performed a controlled experiment with master students about organizing architectural questions that clarified and substantiated the survey data. We learned that architectural questions include slightly more questions about the problem space than the solution space, as well as a minority of questions related to the managing of the project. We found that architects often use ad hoc methods to organize and track them, although they typically organize them along more than one dimension. We learned also that, about a third of the time, architects make assumptions about the answers to architectural questions in order to make progress on the architecture. This suggests that some projects may have risks of incorrect design or later costly rework due to inadequate tracking or incorrectly answered architectural questions.