中文
Home / Research

Research

Three technical routes around software quality assurance, with four selected works in detail.

01
TECHNICAL ROUTES

Three Routes

Code Smell Detection

Mining software repositories (MSR), static analysis

01

Data-Driven Impact Analysis

Open-source communities, socio-technical analysis

02

Adaptive Refactoring

Code recommendation, program comprehension

03
02
SELECTED WORKS

Selected Works in Detail

01
ICPC 2021 · JCST 2022

Multi-Granularity Community Smell Prediction with Developer-Oriented Features and Process Metrics

Authors: Zijie Huang, Zhiqing Shao, Guisheng Fan, Huiqun Yu, Xingguang Yang, Kang Yang, Ziyi Zhou
Keywords

community smell; developer sentiment; socio-technical analysis; empirical software engineering

Background

Open-source software development is a social activity organized by communities. Recent studies show that OSS quality and productivity are shaped by both technical and social factors, yet social debt — the extra cost caused by low-cohesion communication and collaboration — has received far less attention than its technical counterpart. Community smells are unhealthy organizational structures that operationalize social debt. Empirical evidence shows they significantly hamper refactoring and accelerate software aging. Prior work targets community managers and refactors communities top-down; however, OSS communities are flatter and more heterogeneous than traditional hierarchies, so a purely top-down lens is insufficient.

Objective

Community smells originate in development activities and are directly driven by developers. We therefore consider individual developers' experience, sentiment, and process characteristics, aiming to prevent community smells at the individual level. We examine whether these features suffice for prediction, and interpret their influence from both individual and community perspectives.

Method

We build machine-learning models over experience, sentiment, and process features to predict whether a developer is affected by three prevalent community smells (lone wolf, organizational silo, and bottleneck), and whether an affected developer subsequently leaves the community. At the individual granularity, we apply SHAP to well-performing models to quantify feature importance and effect direction. At the community granularity, we forecast the number of affected developers to support maintainers' restructuring decisions.

Results

Under within-project, time-sensitive, and cross-project validation, the individual-level models achieve F1 scores of 0.73–0.92; the community-level forecast attains an R² of 0.68. SHAP analysis shows experience and process metrics dominate, while sentiment features carry balanced, moderate importance.

Conclusions

We recommend that heavily loaded developers proactively communicate in direct and courteous ways to help build healthy communities, and that maintainers use the forecasting model to guide organizational restructuring.

Authors: Zijie Huang, Zhiqing Shao, Guisheng Fan, Huiqun Yu, Kang Yang, Ziyi Zhou
Keywords

code smell; object-relational mapping (ORM); Hibernate; static analysis; OOP

Background

To realize object-oriented programming in data-intensive applications and ease the object–relation impedance mismatch, developers bind OOP classes to relational schemas via object-relational mapping. However, inheritance and polymorphism combined with improper fetching configurations amplify ORM performance problems (e.g., N+1 queries), causing slow queries and service failures — so-called ORM smells.

Objective

General-purpose smell detectors cannot capture such domain-specific problems. We design a tool to detect ORM smells and to provide tooling and data support for subsequent empirical studies.

Method

HBSniff is a static analyzer built on JavaParser. It detects 14 Hibernate ORM code smells and computes 4 mapping metrics.

Results & Conclusions

HBSniff ships with thorough tests and documentation; its results are manually validated, and it generates highly readable, customizable reports per project. Because static analysis requires no compilation, it also scales to large repositories, benefiting mining-software-repositories research.

Authors: Zijie Huang, Junhua Chen, Jianhua Gao
Keywords

code smell; JavaScript; cohesion; coupling; class

Background

Code smells are symptoms of poor design or implementation. Detecting them guides refactoring and improves reliability, and smell metrics quantify design problems. JavaScript is among the most used languages; its class idiom calls for high cohesion and low coupling.

Objective

Existing studies of coupling/cohesion smells in JavaScript operate at the fine-grained level of functions and statements. They yield refactoring advice for implementations but cannot reason about system-level design.

Method

For three class-level smells — Feature Envy, Divergent Change, and Blob — we propose JS4C, a static approach working on both client- and server-side programs. It traverses all classes and combines textual-similarity and structural features to identify smells and their severity. Structural detection uses extended object type inference and a relaxed coupling-dispersion metric (NSCDISP) to mitigate missing type information in a dynamic language.

Results & Conclusions

An evaluation over six open-source projects shows that JS4C detects cohesion/coupling design problems effectively.

Authors: Zijie Huang, Junhua Chen, Jianhua Gao
Keywords

maintainability; web application; layered architecture; code smell; domain modeling

Background

The domain layer of a layered web application consists of domain models. A model that only stores data without behavior is an anemic domain model; its state is maintained by classes in non-domain layers, causing their bloodshot (over-enriched) counterpart. Both symptoms impair maintainability.

Objective

Arguments about anemia/bloodshot have largely relied on subjective experience. We empirically quantify their impact on layered web application architecture.

Method

We measure the severity of three smells — Feature Envy, Blob, and Data Class — as proxies for anemia and bloodshot, then correlate them across layers and versions.

Results & Conclusions

Experiments on 91 Java web projects from a public dataset and 10 open-source Java web applications across multiple versions show that at least 75% of projects suffer from domain-layer anemia and service-layer bloodshot; these symptoms are rarely resolved; their severities correlate across classes, and severity increments correlate across successive versions of the same project.