To efficiently fix defects within a specific time frame during software development, researchers have proposed defect severity prediction to help developers determine which defects to fix first and make efficient use of limited resources.Additionally, to improve the efficiency of defect fixing, just-in-time (JIT) defect prediction has been proposed to promptly predict code fragments that may introduce defects when developers make code changes (i.e., submit a commit).In this way, defect feedback is prompt and localization precision is high.Typically, high-priority defects must be addressed as soon as possible, but when the bug report records a defect back to developers, they need to take time to get reacquainted with the related code fragments, slowing down the speed of high-priority defect fixes.Therefore, we used three machine learning algorithms to develop a JIT defect severity prediction model that allows developers to classify the severity of potential defects when submitting code changes.Our models were tested on ten large-scale projects and showed they can effectively predict defect severity just in time.With Random Forest, our models achieved an average precision of 0.552, and an average recall, F1-measure, and AUC of 0.579, 0.528, and 0.729, respectively.Using Decision Tree, the average precision, recall, F1-measure, and AUC achieve 0.479, 0.494, 0.485, and 0.619, respectively; Using KNN, the average precision, recall, F1measure, and AUC are 0.466, 0.468, 0.467, and 0.593, respectively.Meanwhile, we find a large portion (90.3% on average) of defectintroducing changes are at a high severity level.

Deep learning (DL) is a really active topic in recent years. Code cloning is a common code implementation that could negatively impact software maintenance. For DL software, developers rely heavily on frameworks to implement DL features. Meanwhile, to guarantee efficiency, developers often reuse the steps and configuration settings for building DL models. These may bring code copy-pastes or reuses inducing code clones. However, there is little work exploring code clones’ impact on DL software. In this article, we conduct an empirical study and show that: (1) code clones are prevalent in DL projects, about 16.3% of code fragments encounter clones, which is almost twice larger than the traditional projects; (2) 75.6% of DL projects contain co-changed clones, meaning changes are propagated among cloned fragments, which can bring maintenance difficulties; (3) Percentage of the clones and Number of clone lines are associated with the emergence of co-changes; (4) the prevalence of Code clones varies in DL projects with different frameworks, but the difference is not significant; (5) Type 1 co-changed clones often spread over different folders, but Types 2 and 3 co-changed clones mainly occur within the same files or folders; (6) 57.1% of all co-changed clones are involved in bugs.

Microservice is an architecture style that decomposes complex software into loosely coupled services, which could be developed, maintained, and deployed independently. In recent years, the microservice architecture has been drawing more and more attention from both industrial and academic communities. Many companies, such as Google, Netflix, Amazon, and IBM have applied microservice architecture in their projects. Researchers have also studied microservices in different directions, such as microservices extraction, fault localization, and code quality analysis. The recent work has presented cross-service code clones are prevalent in microservice projects and have caused considerable co-modifications among different services, which undermines the independence of microservices. But there is no systematic study to reveal the underlying reasons for the emergence of such clones. In this paper, we first build a dataset consisting of 2,722 pairs of cross-service clones from 22 open-source microservice projects. Then we manually inspect the implementations of files and methods involved in cross-service clones to understand why the clones are introduced. In the file-level analysis, we categorize files into three types: DPFile (Data-processing File), DRFile (Data-related File), and DIFile (Data-irrelevant File), and have presented that DRFiles are more likely to encounter cross-service clones. For each type of files, we further classify them into specific cases. Each case describes the characteristics of involved files and why the clones happen. In the method-level analysis, we dig information from the code of involved methods. On this basis, we propose a catalog containing 4 categories with 10 subcategories of method-level implementations that result in cross-service clones. We believe our analyses have provided the fundamental knowledge of cross-service clones, which can help developers better manage and resolve such clones in microservice projects.