Blackwell Encyclopedia of Sociology

To remain competitive in a fast changing environment, many companies started to migrate their legacy applications towards a Microservices architecture. Such extensive migration processes require careful planning and consideration of implications and challenges likewise. In this regard, hands-on experiences from industry practice are still rare. To fill this gap in scientific literature, we contribute a qualitative study on intentions, strategies, and challenges in the context of migrations to Microservices. We investigated the migration process of 14 systems across different domains and sizes by conducting 16 in-depth interviews with software professionals from 10 companies. Along with a summary of the most important findings, we present a separate discussion of each case. As primary migration drivers, maintainability and scalability were identified. Due to the high complexity of their legacy systems, most companies preferred a rewrite using current technologies over splitting up existing code bases. This was often caused by the absence of a suitable decomposition approach. As such, finding the right service cut was a major technical challenge, next to building the necessary expertise with new technologies. Organizational challenges were especially related to large, traditional companies that simultaneously established agile processes. Initiating a mindset change and ensuring smooth collaboration between teams were crucial for them. Future research on the evolution of software systems can in particular profit from the individual cases presented.

Microservices Migration in Industry: Intentions, Strategies, and Challenges

Software defect prediction models are classifiers that are constructed from historical software data. Such software defect prediction models have been proposed to help developers optimize the limited Software Quality Assurance (SQA) resources and help managers develop SQA plans. Prior studies have different goals for their defect prediction models and use different techniques for generating visual explanations of their models. Yet, it is unclear what are the practitioners’ perceptions of (1) these defect prediction model goals, and (2) the model-agnostic techniques used to visualize these models. We conducted a qualitative survey to investigate practitioners’ perceptions of the goals of defect prediction models and the model-agnostic techniques used to generate visual explanations of defect prediction models. We found that (1) 82%-84% of the respondents perceived that the three goals of defect prediction models are useful; (2) LIME is the most preferred technique for understanding the most important characteristics that contributed to a prediction of a file, while ANOVA/VarImp is the second most preferred technique for understanding the characteristics that are associated with software defects in the past. Our findings highlight the significance of investigating how to improve the understanding of defect prediction models and their predictions. Hence, model-agnostic techniques from explainable AI domain may help practitioners to understand defect prediction models and their predictions.

Practitioners’ Perceptions of the Goals and Visual Explanations of Defect Prediction Models

Context: Microservices Architecture (MSA) has received significant attention in the software industry. However, little empirical evidence exists on design, monitoring, and testing of microservices systems. Objective: This research aims to gain a deep understanding of how microservices systems are designed, monitored, and tested in the industry. Method: A mixed-methods study was conducted with 106 survey responses and 6 interviews from microservices practitioners. Results: The main findings are: (1) a combination of domain-driven design and business capability is the most used strategy to decompose an application into microservices, (2) over half of the participants used architecture evaluation and architecture implementation when designing microservices systems, (3) API gateway and Backend for frontend patterns are the most used MSA patterns, (4) resource usage and load balancing as monitoring metrics, log management and exception tracking as monitoring practices are widely used, (5) unit and end-to-end testing are the most used testing strategies, and (6) the complexity of microservices systems poses challenges for their design, monitoring, and testing, for which there are no dedicated solutions. Conclusions: Our findings reveal that more research is needed to (1) deal with microservices complexity at the design level, (2) handle security in microservices systems, and (3) address the monitoring and testing challenges through dedicated solutions.

Design, Monitoring, and Testing of Microservices Systems: The Practitioners' Perspective.

Defect prediction aims to automatically identify potential defective code with minimal human intervention and has been widely studied in the literature. Just-in-Time (JIT) defect prediction focuses on program changes rather than whole programs, and has been widely adopted in continuous testing. CC2Vec, state-of-the-art JIT defect prediction tool, first constructs a hierarchical attention network (HAN) to learn distributed vector representations of both code additions and deletions, and then concatenates them with two other embedding vectors representing commit messages and overall code changes extracted by the existing DeepJIT approach to train a model for predicting whether a given commit is defective. Although CC2Vec has been shown to be the state of the art for JIT defect prediction, it was only evaluated on a limited dataset and not compared with all representative baselines. Therefore, to further investigate the efficacy and limitations of CC2Vec, this paper performs an extensive study of CC2Vec on a large-scale dataset with over 310,370 changes (8.3 X larger than the original CC2Vec dataset). More specifically, we also empirically compare CC2Vec against DeepJIT and representative traditional JIT defect prediction techniques. The experimental results show that CC2Vec cannot consistently outperform DeepJIT, and neither of them can consistently outperform traditional JIT defect prediction. We also investigate the impact of individual traditional defect prediction features and find that the added-line-number feature outperforms other traditional features. Inspired by this finding, we construct a simplistic JIT defect prediction approach which simply adopts the added-line-number feature with the logistic regression classifier. Surprisingly, such a simplistic approach can outperform CC2Vec and DeepJIT in defect prediction, and can be 81k X/120k X faster in training/testing. Furthermore, the paper also provides various practical guidelines for advancing JIT defect prediction in the near future.

Deep just-in-time defect prediction: how far are we?

Software defects are well-known in software development and might cause several problems for users and developers aside. As a result, researches employed distinct techniques to mitigate the impacts of these defects in the source code. One of the most notable techniques focuses on defect prediction using machine learning methods, which could support developers in handling these defects before they are introduced in the production environment. These studies provide alternative approaches to predict the likelihood of defects. However, most of these works concentrate on predicting defects from a vast set of software features. Another key issue with the current literature is the lack of a satisfactory explanation of the reasons that drive the software to a defective state. Specifically, we use a tree boosting algorithm (XGBoost) that receives as input a training set comprising records of easy-to-compute characteristics of each module and outputs whether the corresponding module is defect-prone. To exploit the link between predictive power and model explainability, we propose a simple model sampling approach that finds accurate models with the minimum set of features. Our principal idea is that features not contributing to increasing the predictive power should not be included in the model. Interestingly, the reduced set of features helps to increase model explainability, which is important to provide information to developers on features related to each module of the code which is more defect-prone. We evaluate our models on diverse projects within Jureczko datasets, and we show that (i) features that contribute most for finding best models may vary depending on the project and (ii) it is possible to find effective models that use few features leading to better understandability. We believe our results are useful to developers as we provide the specific software features that influence the defectiveness of selected projects.

Understanding machine learning software defect predictions

Software metrics and thresholds provide means to quantify several quality attributes of software systems Indeed, they have been used in a wide variety of methods and tools for detecting different sorts of technical debts, such as code smells Unfortunately, these methods and tools do not take into account characteristics of software domains, as the intrinsic complexity of geo-localization and scientific software systems or the simple protocols employed by messaging applications Instead, they rely on generic thresholds that are derived from heterogeneous systems Although derivation of reliable thresholds has long been a concern, we still lack empirical evidence about threshold variation across distinct software domains To tackle this limitation, this paper investigates whether and how thresholds vary across domains by presenting a large-scale study on 3,107 software systems from 15 domains We analyzed the derivation and distribution of thresholds based on 8 well-known source code metrics As a result, we observed that software domain and size are relevant factors to be considered when building benchmarks for threshold derivation Moreover, we also observed that domain-specific metric thresholds are more appropriated than generic ones for code smell detection

Evaluating domain-specific metric thresholds: an empirical study

Microservices architectures have become largely popular in the last years. However, we still lack empirical evidence about the use of microservices and the practices followed by practitioners. Thereupon, in this paper, we report the results of a survey with 122 professionals who work with microservices. We report how the industry is using this architectural style and whether the percep- tion of practitioners regarding the advantages and challenges of microservices is according to the literature.

https://hal.inria.fr/hal-01944464/document

Microservices in Practice: A Survey Study

Code smells are symptoms that something may be wrong with the app. Aiming at removing code smells and improving the maintainability and performance of the app, we may apply the refactoring technique, which could reduce hardware resource use, such as CPU and memory. However, a few studies have evaluated the impacts of the refactoring in Android. This paper presents a study to assess the effects of smartphone resource use caused by refactoring of 3 classic code smells: God Class, God Method, and Feature Envy. To this purpose, we selected 9 apps from GitHub. The results show that refactoring used in desktop software may not be appropriate for Android apps. For example, the refactoring of God Method had increased CPU consumption by more than 47%, while the refactoring of the 3 code smells reduced memory consumption in average 6.51%, 8.4%, and 6.37%, respectively, in one app. Our results can support the community in conducting research and future implementation of new tools. Also, it guides app developers in refactoring and thus improving the quality of their apps. keywords: Code Smells, Android Smells, and Consumption of Smartphone Resources

/pdf/an-empirical-study-on-the-impact-of-android-code-smells-on-20nuy458ty.pdf

An Empirical Study on the Impact of Android Code Smells on Resource Usage.

Third-party libraries have been widely adopted in modern software projects due to several benefits, such as code reuse and software quality. Software development is increasingly complex and requires specialists with knowledge in several technologies, such as the nowadays libraries. Such complexity turns it extremely challenging to deliver quality software given the time pressure. For this purpose, it is necessary to identify and hire qualified developers, to obtain a good team, both in open source and proprietary systems. For these reasons, enterprise and open source projects try to build teams composed of highly skilled developers in specific libraries. Developers with expertise in specific libraries may reduce the time spent on software development tasks and improve the quality of the final product. However, their identification may not be trivial. In this paper, we first argue that source code activities can be used to identify library experts. We then evaluate a mining-based strategy to identify library experts. To achieve our goal, we selected the 9 most popular Java libraries and identified the top-10 experts in each library by analyzing commits in 16,703 Java projects on GitHub. We validated the results by applying a survey with 137 library expert candidates and observed, on average, 88% of precision for the applied strategy.

Markos Viggiato

Papers

Understanding machine learning software defect predictions

Evaluating domain-specific metric thresholds: an empirical study

Microservices in Practice: A Survey Study

An Empirical Study on the Impact of Android Code Smells on Resource Usage.

How Well Do You Know This Library?: Mining Experts from Source Code Analysis