@article {SAN17,
	title = {Empirical Study on Refactoring Large-scale Industrial Systems and Its Effects on Maintainability},
	journal = {Journal of Systems and Software},
	volume = {129},
	number = {C},
	year = {2017},
	month = {jul},
	pages = {107{\textendash}126},
	abstract = {We examine hundreds of manual refactoring commits from large-scale industrial systems.We study the effects of these commits on source code using a maintainability model.Developers preferred to fix concrete coding issues rather than fix code smells.A single refactoring had only a small impact (sometimes even negative effect).Whole refactoring process has significant beneficial effect on the maintainability. Software evolves continuously, it gets modified, enhanced, and new requirements always arise. If we do not spend time occasionally on improving our source code, its maintainability will inevitably decrease. The literature tells us that we can improve the maintainability of a software system by regularly refactoring it. But does refactoring really increase software maintainability? Can it happen that refactoring decreases the maintainability? Empirical studies show contradicting answers to these questions and there have been only a few studies which were performed in a large-scale, industrial context. In our paper, we assess these questions in an in vivo context, where we analyzed the source code and measured the maintainability of 6 large-scale, proprietary software systems in their manual refactoring phase. We analyzed 2.5 million lines of code and studied the effects on maintainability of 315 refactoring commits which fixed 1273 coding issues. We found that single refactorings only make a very little difference (sometimes even decrease maintainability), but a whole refactoring period, in general, can significantly increase maintainability, which can result not only in the local, but also in the global improvement of the code.},
	keywords = {Antipatterns, coding issues, ISO/IEC 25010, maintainability, refactoring, select:quality, software quality},
	issn = {0164-1212},
	doi = {10.1016/j.jss.2016.08.071},
	url = {http://www.sciencedirect.com/science/article/pii/S0164121216301558?via\%3Dihub},
	author = {Sz{\H o}ke, G{\'a}bor and Antal, G{\'a}bor and Csaba Nagy and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
@article {USH15,
	title = {Performance Comparison of Query-based Techniques for Anti-pattern Detection},
	journal = {Information and Software Technology},
	volume = {65},
	number = {C},
	year = {2015},
	month = {sep},
	pages = {147{\textendash}165},
	abstract = {Context Program queries play an important role in several software evolution tasks like program comprehension, impact analysis, or the automated identification of anti-patterns for complex refactoring operations. A central artifact of these tasks is the reverse engineered program model built up from the source code (usually an Abstract Semantic Graph, ASG), which is traditionally post-processed by dedicated, hand-coded queries. Objective Our paper investigates the costs and benefits of using the popular industrial Eclipse Modeling Framework (EMF) as an underlying representation of program models processed by four different general-purpose model query techniques based on native Java code, OCL evaluation and (incremental) graph pattern matching. Method We provide in-depth comparison of these techniques on the source code of 28 Java projects using anti-pattern queries taken from refactoring operations in different usage profiles. Results Our results show that general purpose model queries can outperform hand-coded queries by 2{\textendash}3 orders of magnitude, with the trade-off of an increased in memory consumption and model load time of up to an order of magnitude. Conclusion The measurement results of usage profiles can be used as guidelines for selecting the appropriate query technologies in concrete scenarios.},
	keywords = {Anti-patterns, Columbus, EMF-IncQuery, OCL, Performance measurements, refactoring},
	issn = {0950-5849},
	doi = {10.1016/j.infsof.2015.01.003},
	url = {http://www.sciencedirect.com/science/article/pii/S0950584915000051?via\%3Dihub},
	author = {Ujhelyi, Zolt{\'a}n and Sz{\H o}ke, G{\'a}bor and Horv{\'a}th, {\'A}kos and Csisz{\'a}r, Norbert Istv{\'a}n and L{\'a}szl{\'o} Vid{\'a}cs and Varr{\'o}, D{\'a}niel and Rudolf Ferenc}
}
@conference {SNF14,
	title = {A Case Study of Refactoring Large-Scale Industrial Systems to Efficiently Improve Source Code Quality},
	booktitle = {Proceedings of the 14th International Conference on Computational Science and Its Applications (ICCSA 2014)},
	series = {Lecture Notes in Computer Science (LNCS)},
	volume = {8583},
	year = {2014},
	month = {jun},
	pages = {524{\textendash}540},
	publisher = {Springer-Verlag},
	organization = {Springer-Verlag},
	address = {Guimar{\~a}es, Portugal},
	abstract = {Refactoring source code has many benefits (e.g. improving maintainability, robustness and source code quality), but it takes time away from other implementation tasks, resulting in developers neglecting refactoring steps during the development process. But what happens when they know that the quality of their source code needs to be improved and they can get the extra time and money to refactor the code? What will they do? What will they consider the most important for improving source code quality? What sort of issues will they address first or last and how will they solve them? In our paper, we look for answers to these questions in a case study of refactoring large-scale industrial systems where developers participated in a project to improve the quality of their software systems. We collected empirical data of over a thousand refactoring patches for 5 systems with over 5 million lines of code in total, and we found that developers really optimized the refactoring process to significantly improve the quality of these systems.},
	keywords = {refactoring, Software engineering, software quality},
	doi = {10.1007/978-3-319-09156-3_37},
	url = {https://link.springer.com/chapter/10.1007\%2F978-3-319-09156-3_37},
	author = {Sz{\H o}ke, G{\'a}bor and Csaba Nagy and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
