54 research outputs found

    Influence of developer factors on code quality: a data study

    Get PDF
    © 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Automatic source-code inspection tools help to assess, monitor and improve code quality. Since these tools only examine the software project’s codebase, they overlook other possible factors that may impact code quality and the assessment of the technical debt (TD). Our initial hypothesis is that human factors associated with the software developers, like coding expertise, communication skills, and experience in the project have some measurable impact on the code quality. In this exploratory study, we test this hypothesis on two large open source repositories, using TD as a code quality metric and the data that may be inferred from the version control systems. The preliminary results of our statistical analysis suggest that the level of participation of the developers and their experience in the project have a positive correlation with the amount of TD that they introduce. On the contrary, communication skills have barely any impact on TD.Peer ReviewedPostprint (author's final draft

    Towards Surgically-Precise Technical Debt Estimation: Early Results and Research Roadmap

    Get PDF
    The concept of technical debt has been explored from many perspectives but its precise estimation is still under heavy empirical and experimental inquiry. We aim to understand whether, by harnessing approximate, data-driven, machine-learning approaches it is possible to improve the current techniques for technical debt estimation, as represented by a top industry quality analysis tool such as SonarQube. For the sake of simplicity, we focus on relatively simple regression modelling techniques and apply them to modelling the additional project cost connected to the sub-optimal conditions existing in the projects under study. Our results shows that current techniques can be improved towards a more precise estimation of technical debt and the case study shows promising results towards the identification of more accurate estimation of technical debt.Comment: 6 page

    Impact of Opportunistic Reuse Practices to Technical Debt

    Get PDF
    Technical debt (TD) has been recognized as an important quality problem for both software architecture and code. The evolution of TD techniques over the past years has led to a number of research and commercial tools. In addition, the increasing trend of opportunistic reuse (as opposed to systematic reuse), where developers reuse code assets in popular repositories, is changing the way components are selected and integrated into existing systems. However, reusing software opportunistically can lead to a loss of quality and induce TD, especially when the architecture is changed in the process. However, to the best of our knowledge, no studies have investigated the impact of opportunistic reuse in TD. In this paper, we carry out an exploratory study to investigate to what extent reusing components opportunistically negatively affects the quality of systems. We use one commercial and one research tool to analyze the TD ratios of three case systems, before and after opportunistically extending them with open-source software.Peer reviewe

    Evolution of technical debt remediation in Python: A case study on the Apache Software Ecosystem

    Get PDF
    In recent years, the evolution of software ecosystems and the detection of technical debt received significant attention by researchers from both industry and academia. While a few studies that analyze various aspects of technical debt evolution already exist, to the best of our knowledge, there is no large-scale study that focuses on the remediation of technical debt over time in Python projects -- i.e., one of the most popular programming languages at the moment. In this paper, we analyze the evolution of technical debt in 44 Python open-source software projects belonging to the Apache Software Foundation. We focus on the type and amount of technical debt that is paid back. The study required the mining of over 60K commits, detailed code analysis on 3.7K system versions, and the analysis of almost 43K fixed issues. The findings show that most of the repayment effort goes into testing, documentation, complexity and duplication removal. Moreover, more than half of the Python technical debt in the ecosystem is short-term being repaid in less than two months. In particular, the observations that a minority of rules account for the majority of issues fixed and spent effort, suggest that addressing those kinds of debt in the future is important for research and practice

    ANALISIS QUALITY CODE MENGGUNAKAN SONARQUBE DALAM SUATU APLIKASI BERBASIS LARAVEL

    Get PDF
    Analisis Kode Statis (Static Code Analysis) masuk ke dalam metode white box testing yang digunakan pada pengembangan aplikasi. Analisis ini dilakukan dengan cara mengevaluasi source code untuk mendeteksi pelanggaran kode apa saja yang terdapat dalam project aplikasi open source To Do List berbasis website menggunakan Laravel dan Vue.js. Proses analisis kode statis bertujuan memberikan pemahaman serta memastikan basic code pada project telah memenuhi standarisasi pengkodean yang telah ditetapkan. Teknik pengujian source code dilakukan melewati proses scanning pada project dengan standarisasi pengkodean yang telah ditetapkan dan diatur dalam Quality Gate SonarQube sebagai acuan untuk seberapa tinggi kualitas kode yang harus dilalui. Hasil analisis yang diperoleh melalui tool SonarQube menunjukkan pelanggaran kode yang ditemukan secara keseluruhan pada project To Do List dengan beberapa kategori issues, yaitu 4 bug, 2 security hotspots, 31 code smell, dan 117 duplicate lines of code dengan density sebesar 18,3% yang membutuhkan total waktu estimasi pengerjaan untuk perbaikan pelanggaran kode sebanyak 2 jam 35 menit

    Empirical evaluation of an architectural technical debt index in the context of the Apache and ONAP ecosystems

    Get PDF
    Background. Architectural Technical Debt (ATD) in a software-intensive system denotes architectural design choices which, while being suitable or even optimal when adopted, lower the maintainability and evolvability of the system in the long term, hindering future development activities. Despite the growing research interest in ATD, how to gain an informative and encompassing viewpoint of the ATD present in a software-intensive system is still an open problem. Objective. In this study, we evaluate ATDx, a data-driven approach providing an overview of the ATD present in a software-intensive system. The approach, based on the analysis of a software portfolio, calculates severity levels of architectural rule violations via a clustering algorithm, and aggregates results into different ATD dimensions. Method. To evaluate ATDx, we implement an instance of the approach based on SonarQube, and run the analysis on the Apache and ONAP ecosystems. The analysis results are then shared with the portfolio contributors, who are invited to participate in an online survey designed to evaluate the representativeness and actionability of the approach. Results. The survey results confirm the representativeness of the ATDx, in terms of both the ATDx analysis results and the used architectural technical debt dimensions. Results also showed the actionability of the approach, although to a lower extent when compared to the ATDx representativeness, with usage scenarios including refactoring, code review, communication, and ATD evolution analysis. Conclusions. With ATDx, we strive for the establishment of a sound, comprehensive, and intuitive architectural view of the ATD identifiable via source code analysis. The collected results are promising, and display both the representativeness and actionability of the approach. As future work, we plan to consolidate the approach via further empirical experimentation, by considering other development contexts (e.g., proprietary portfolios and other source code analysis tools), and enhancing the ATDx report capabilities

    The Impact of Ownership and Contribution Alignment on Code Technical Debt Accumulation

    Full text link
    Software development organisations strive to maintain their effectiveness while the complexity of the systems they develop continues to grow. To tackle this challenge, organisations tend to be organised into small teams working with components that can be developed separately. Here, organisations must design their architecture and organisational structures in a way that enables communication and minimises dependencies, and helps teams reduce code and architectural degradation. Ensuring that each small independent team is responsible for components they primarily contribute is one approach to achieving this goal. This study aims at understanding the impact of ownership and contribution alignment on accumulation of code technical debt and how abrupt changes in team constellation affect teams' effectiveness in managing TD. We conducted an embedded case study in a company developing a very large software system, analysing ten components belonging to 1 team. During the studied period, the team was split into two, and the components owned by them were distributed between the two new teams. With high degrees of contribution alignment, we noticed a negative correlation between contribution alignment and TD Density before the team split. In 4 components, this correlation is statistically significant. This means a higher contribution alignment degree implies a lower TD Density. After the split, we observe a negative correlation in 3 components. The positive correlation observed in the other 5 components could be attributed to low contribution alignment, leading to difficulties in managing TD. Our findings suggest that contribution alignment can be important in controlling TD in software development organisations. Making teams responsible for the quality of components they have more expertise over and minimising dependencies between teams can help organisations mitigate the growth of TD.Comment: Submitted to Transactions on Software Engineering (TSE

    Approaches, Techniques, and Tools for Identifying Important Code Changes to Help Code Reviewers

    Get PDF
    Software development is a collaborative process where many developers come together and work on a project. To make things easy and manageable, software is developed on a version control system. A version control system is a centralized system which stores code and adds code from all other developers as an increment to the code base in the repository. Since multiple people work on the same code repository together, it is important to make sure that their contributions do not conflict with each other. It is important to maintain the quality and integrity of the repository. This is where the code review process comes into the picture. All the changes made to the repository by developers are reviewed by other, preferably senior developers, before it is integrated into the repository. This is done to maintain a high standard of development. The problem is that this is a manual and highly time consuming process. This research proposes a tool that tries to optimize the code review process. This is done by ranking the changes that the developers need to review: this makes it easier for the developer to decide which change he/she needs to review first. Also since every reviewer has their own preference and style, the tool takes feedback from the code reviewer after every change and readjusts the ranked change list according to his/her feedback. Adding to that, the tool classifies each change and tags it so that the code reviewers have a better understanding of the change that he/she is about to review. It also provides additional refactoring information about each change. Refactoring changes are very easy to miss, since they are not usually erroneous changes, but they erode the quality of the software overtime. The tool points out these changes so that these changes are not missed by the code reviewer. The research was evaluated on 7 open source project and a usability study was conducted which prove that this tool does have a positive impact on the code review process
    • …
    corecore