5,068 research outputs found
An analysis of techniques and methods for technical debt management: a reflection from the architecture perspective
Technical debt is a metaphor referring to the consequences of weak software development. Managing technical debt is necessary in order to keep it under control, and several techniques have been developed with the goal of accomplishing this. However, available techniques have grown disperse and managers lack guidance. This paper covers this gap by providing a systematic mapping of available techniques and methods for technical debt management, covering architectural debt, and identifying existing gaps that prevent to manage technical debt efficiently
A Longitudinal Study of Identifying and Paying Down Architectural Debt
Architectural debt is a form of technical debt that derives from the gap
between the architectural design of the system as it "should be" compared to
"as it is". We measured architecture debt in two ways: 1) in terms of
system-wide coupling measures, and 2) in terms of the number and severity of
architectural flaws. In recent work it was shown that the amount of
architectural debt has a huge impact on software maintainability and evolution.
Consequently, detecting and reducing the debt is expected to make software more
amenable to change. This paper reports on a longitudinal study of a healthcare
communications product created by Brightsquid Secure Communications Corp. This
start-up company is facing the typical trade-off problem of desiring
responsiveness to change requests, but wanting to avoid the ever-increasing
effort that the accumulation of quick-and-dirty changes eventually incurs. In
the first stage of the study, we analyzed the status of the "before" system,
which indicated the impacts of change requests. This initial study motivated a
more in-depth analysis of architectural debt. The results of this analysis were
used to motivate a comprehensive refactoring of the software system. The third
phase of the study was a follow-on architectural debt analysis which quantified
the improvements made. Using this quantitative evidence, augmented by
qualitative evidence gathered from in-depth interviews with Brightsquid's
architects, we present lessons learned about the costs and benefits of paying
down architecture debt in practice.Comment: Submitted to ICSE-SEIP 201
30 Years of Software Refactoring Research: A Systematic Literature Review
Peer Reviewedhttps://deepblue.lib.umich.edu/bitstream/2027.42/155872/4/30YRefactoring.pd
Understanding Architecture Erosion: The Practitioners' Perceptive
As software systems evolve, their architecture is meant to adapt accordingly
by following the changes in requirements, the environment, and the
implementation. However, in practice, the evolving system often deviates from
the architecture, causing severe consequences to system maintenance and
evolution. This phenomenon of architecture erosion has been studied extensively
in research, but not yet been examined from the point of view of developers. In
this exploratory study, we look into how developers perceive the notion of
architecture erosion, its causes and consequences, as well as tools and
practices to identify and control architecture erosion. To this end, we
searched through several popular online developer communities for collecting
data of discussions related to architecture erosion. Besides, we identified
developers involved in these discussions and conducted a survey with 10
participants and held interviews with 4 participants. Our findings show that:
(1) developers either focus on the structural manifestation of architecture
erosion or on its effect on run-time qualities, maintenance and evolution; (2)
alongside technical factors, architecture erosion is caused to a large extent
by non-technical factors; (3) despite the lack of dedicated tools for detecting
architecture erosion, developers usually identify erosion through a number of
symptoms; and (4) there are effective measures that can help to alleviate the
impact of architecture erosion.Comment: The 29th IEEE/ACM International Conference on Program Comprehension
(ICPC
30 Years of Software Refactoring Research:A Systematic Literature Review
Due to the growing complexity of software systems, there has been a dramatic
increase and industry demand for tools and techniques on software refactoring
in the last ten years, defined traditionally as a set of program
transformations intended to improve the system design while preserving the
behavior. Refactoring studies are expanded beyond code-level restructuring to
be applied at different levels (architecture, model, requirements, etc.),
adopted in many domains beyond the object-oriented paradigm (cloud computing,
mobile, web, etc.), used in industrial settings and considered objectives
beyond improving the design to include other non-functional requirements (e.g.,
improve performance, security, etc.). Thus, challenges to be addressed by
refactoring work are, nowadays, beyond code transformation to include, but not
limited to, scheduling the opportune time to carry refactoring, recommendations
of specific refactoring activities, detection of refactoring opportunities, and
testing the correctness of applied refactorings. Therefore, the refactoring
research efforts are fragmented over several research communities, various
domains, and objectives. To structure the field and existing research results,
this paper provides a systematic literature review and analyzes the results of
3183 research papers on refactoring covering the last three decades to offer
the most scalable and comprehensive literature review of existing refactoring
research studies. Based on this survey, we created a taxonomy to classify the
existing research, identified research trends, and highlighted gaps in the
literature and avenues for further research.Comment: 23 page
Detection of microservice smells through static analysis
A arquitetura de microsserviços é um modelo arquitetural promissor na área de software,
atraindo desenvolvedores e empresas para os seus princÃpios convincentes. As suas vantagens
residem no potencial para melhorar a escalabilidade, a flexibilidade e a agilidade, alinhando se com as exigências em constante evolução da era digital. No entanto, navegar entre as
complexidades dos microsserviços pode ser uma tarefa desafiante, especialmente à medida
que este campo continua a evoluir.
Um dos principais desafios advém da complexidade inerente aos microsserviços, em que o seu
grande número e interdependências podem introduzir novas camadas de complexidade. Além
disso, a rápida expansão dos microsserviços, juntamente com a necessidade de aproveitar as
suas vantagens de forma eficaz, exige uma compreensão mais profunda das potenciais
ameaças e problemas que podem surgir. Para tirar verdadeiramente partido das vantagens
dos microsserviços, é essencial enfrentar estes desafios e garantir que o desenvolvimento e a
adoção de microsserviços sejam bem-sucedidos.
O presente documento pretende explorar a área dos smells da arquitetura de microsserviços
que desempenham um papel tão importante na dÃvida técnica dirigida à área dos
microsserviços.
Embarca numa exploração de investigação abrangente, explorando o domÃnio dos smells de
microsserviços. Esta investigação serve como base para melhorar um catálogo de smells de
microsserviços. Esta investigação abrangente obtém dados de duas fontes primárias:
systematic mapping study e um questionário a profissionais da área. Este último envolveu 31
profissionais experientes com uma experiência substancial no domÃnio dos microsserviços.
Além disso, são descritos o desenvolvimento e o aperfeiçoamento de uma ferramenta
especificamente concebida para identificar e resolver problemas relacionados com os
microsserviços. Esta ferramenta destina-se a melhorar o desempenho dos programadores
durante o desenvolvimento e a implementação da arquitetura de microsserviços.
Por último, o documento inclui uma avaliação do desempenho da ferramenta. Trata-se de
uma análise comparativa efetuada antes e depois das melhorias introduzidas na ferramenta.
A eficácia da ferramenta será avaliada utilizando o mesmo benchmarking de microsserviços
utilizado anteriormente, para além de outro benchmarking para garantir uma avaliação
abrangente.The microservices architecture stands as a beacon of promise in the software landscape,
drawing developers and companies towards its compelling principles. Its appeal lies in the
potential for improved scalability, flexibility, and agility, aligning with the ever-evolving
demands of the digital age. However, navigating the intricacies of microservices can be a
challenging task, especially as this field continues to evolve.
A key challenge arises from the inherent complexity of microservices, where their sheer
number and interdependencies can introduce new layers of intricacy. Furthermore, the rapid
expansion of microservices, coupled with the need to harness their advantages effectively,
demands a deeper understanding of the potential pitfalls and issues that may emerge. To
truly unlock the benefits of microservices, it is essential to address these challenges head-on
and ensure a successful journey in the world of microservices development and adoption.
The present document intends to explore the area of microservice architecture smells that
play such an important role in the technical debt directed to the area of microservices.
It embarks on a comprehensive research exploration, delving into the realm of microservice
smells. This research serves as the cornerstone for enhancing a microservice smell catalogue.
This comprehensive research draws data from two primary sources: a systematic mapping
research and an industry survey. The latter involves 31 seasoned professionals with
substantial experience in the field of microservices.
Moreover, the development and enhancement of a tool specifically designed to identify and
address issues related to microservices is described. This tool is aimed at improving
developers' performance throughout the development and implementation of microservices
architecture.
Finally, the document includes an evaluation of the tool's performance. This involves a
comparative analysis conducted before and after the tool's enhancements. The tool's
effectiveness will be assessed using the same microservice benchmarking as previously
employed, in addition to another benchmark to ensure a comprehensive evaluation
Experiences on Managing Technical Debt with Code Smells and AntiPatterns
Technical debt has become a common metaphor for the accumulation of software design and implementation choices that seek fast initial gains but that are under par and counterproductive in the long run. However, as a metaphor, technical debt does not offer actionable advice on how to get rid of it. To get to a practical level in solving problems, more focused mechanisms are needed. Commonly used approaches for this include identifying code smells as quick indications of possible problems in the codebase and detecting the presence of AntiPatterns that refer to overt, recurring problems in design. There are known remedies for both code smells and AntiPatterns. In paper, our goal is to show how to effectively use common tools and the existing body of knowledge on code smells and AntiPatterns to detect technical debt and pay it back. We present two main results: (i) How a combination of static code analysis and manual inspection was used to detect code smells in a codebase leading to the discovery of AntiPatterns; and (ii) How AntiPatterns were used to identify, characterize, and fix problems in the software. The experiences stem from a private company and its long-lasting software product development effort.Peer reviewe
- …