This thesis deals with a methodology for PHP web applications refactoring. The main objective is to propose such a methodology, and to apply it on a real project. The first chapter contains objectives, restrictions and contributions of the thesis. The research of the existing literature on similar topics follows in the second chapter. The third chapter comments on selected software development methodologies' approach to refactoring. The fourth chapter describes known code smells, and adds some new ones appearing particularly in PHP. Specifics of PHP refactoring are also described. The fifth chapter deals with the methodology proposal itself. It sums up requirements, deployment assumptions, the methodology principles and general characteristics. The next part contains the recommended procedure of PHP web applications refactoring with its parts commented farther on. These parts are mainly code smells identification techniques, prioritization and finally best practices. The chapter ends with this methodology deployment recommendations. The sixth chapter shows a practical usage of the proposed methodology when refactoring a real web application. The performed steps are explained in terms of the methodology. The chapter closes with observations gained during this refactoring.

Context: Test-Driven development (TDD) is a software development approach where test cases are written before actual development of the code in iterative cycles. TDD has gained attention of many software practitioners during the last decade since it has suggested several benefits in the software development process. However, empirical evidence of its dominance in terms of internal code quality, external code quality and productivity is fairly limited. Objectives: The aim behind conducting this study is to explore what has been achieved so far in the field of Test-driven development. The study reports the benefits and limitation of TDD compared to TLD and the outcome variables in all the reported studies along with their measurement criteria. Additionally, an experiment is conducted to see the impact of Test-driven development (TDD) on internal code quality, external code quality and productivity compared to Test-Last development (TLD). Methods: In this study two research methodologies are used specifically systematic literature review according to Kitchenham guidelines and controlled pilot experiment. In systematic literature review number of article sources are considered and used, including Inspec, Compendex, ACM, IEEE Xplore, Science direct (Elsevier) and ISI web of science. A review protocol is created first to ensure the objectivity and repeatability of the whole process. Second, a controlled experiment is conducted with professional software developers to explore the assumed benefits of Test-Driven development (TDD) compared to Test-Last development (TLD). Results: 9 distinct categories related to Test-driven development (TDD) are found that are investigated and reported in the literature. All the reported experiments revealing very little or no difference in internal code quality, external code quality and productivity in Test-Driven development (TDD) over Test-Last development (TLD). However, results were found contradictory when research methods are taken into account because case studies tend to find more positive results in the favor Test-Driven development (TDD) compared to experiments possibly due to the fact that experiment are mostly conducted in artificially created software development environment and mostly with students as a test subjects. On the other hand, experimental results and statistical analysis show no statistically significant result in the favor TDD compared to TLD. All the values found related to number of acceptance test cases passed (Mann-Whitney U test Exact Sig. 0.185), McCabe’s Cyclomatic complexity (Mann-Whitney U test Exact Sig. 0.063), Branch coverage (Mann-Whitney U test Exact Sig. 0.212), Productivity in terms of number of lines of code per person hours (Independent sample Ttest Sig. 0.686), productivity in terms number of user stories implemented per person hours (Independent sample T-test Sig. 0.835) in experiment are statistically insignificant. However, static code analysis (Independent sample T-test Sig. 0.03) result was found statistically significant but due to the low statistical power of test it was not possible to reject the null hypothesis. The results of the survey revealed that the majority of developers in the experiment prefer TLD over TDD, given the lesser required level of learning curve as well as the minimum effort needed to understand and employ TLD compared to TDD Conclusion: Systematic literature review confirms that the reported benefits of TDD development compared to Test-Last development are very small. However, case studies tend to find more positive results in the favor of Test-Driven development (TDD) compared to Test-Last development (TLD). Similarly, experimental findings are also confirming the fact that TDD has small benefits over TLD. However, given the small effect size there is an indication that (Test-Driven development) TDD endorses less complex code compared to Test-Last development (TLD). / Systematic literature review confirms that the reported benefits of TDD development compared to Test-Last development are very small. However, case studies tend to find more positive results in the favor of Test-Driven development (TDD) compared to Test-Last development (TLD). Similarly, experimental findings are also confirming the fact that TDD has small benefits over TLD. However, given the small effect size there is an indication that (Test-Driven development) TDD endorses less complex code compared to Test-Last development (TLD). / hassanmunirr@hotmail.com, mm1844@gmail.com

Software is an integral part of our everyday lives, and hence the quality of software is very important. However, improving and maintaining high software quality is a difficult task, and a significant amount of resources is spent on fixing software defects. Previous studies have studied software quality using various measurable aspects of software, such as code size and code change history. Nevertheless, these metrics do not consider all possible factors that are related to defects. For instance, while lines of code may be a good general measure for defects, a large file responsible for simple I/O tasks is likely to have fewer defects than a small file responsible for complicated compiler implementation details. In this thesis, we address this issue by considering the conceptual concerns (or features). We use a statistical topic modelling approach to approximate the conceptual concerns as topics. We then use topics to study software quality along two dimensions: code quality and code testedness. We perform our studies using three versions of four large real-world software systems: Mylyn, Eclipse, Firefox, and NetBeans. Our proposed topic metrics help improve the defect explanatory power (i.e., fitness of the regression model) of traditional static and historical metrics by 4–314%. We compare one of our metrics, which measures the cohesion of files, with other topic-based cohesion and coupling metrics in the literature and find that our metric gives the greatest improvement in explaining defects over traditional software quality metrics (i.e., lines of code) by 8–55%. We then study how we can use topics to help improve the testing processes. By training on previous releases of the subject systems, we can predict not well-tested topics that are defect prone in future releases with a precision and recall of 0.77 and 0.75, respectively. We can map these topics back to files and help allocate code inspection and testing resources. We show that our approach outperforms traditional prediction-based resource allocation approaches in terms of saving testing and code inspection efforts. The results of our studies show that topics can be used to study software quality and support traditional quality assurance approaches. / Thesis (Master, Computing) -- Queen's University, 2013-01-08 10:10:37.878

Keeping the code quality high and ensuring high security in a softwareproject is a common challenge. To address this challenge a system calledQuality Assurance System (QAS) has been implemented. QAS usesfour third-party testing tools to evaluate software projects in regards tocode quality and security, without adding more work for each separatesoftware project. QAS was tested on real world software projects andmultiple potential misconfigurations and errors was found. QAS can notreplace testing, but it is a starting point by adding some basic tests thatlooks for security vulnerabilities, misconfigurations, etc.

Context. There is a need for developers to write clean code and code that adheres to a high-quality standard. We need developers not to introduce technical debt and code smells to the code. From a business perspective, developers that introduce technical debt to the code will make the code more difficult to maintain, meaning that the cost for the project will increase. Objectives. The main objective of this study is to gain an understanding about the perception the developers have about clean code and how they use it in practice. There is not much information about how clean code is perceived by developers and applied in practice, and this thesis will extend the information about those two areas. It is an effort to understand developers' perception of clean code in practice and what they think about it. Realization (Method). To understand the state-of-the-art in the area of clean code, we first performed  literature review using snowballing. To delve into developers' perception about clean code and how it is used in practice. We have developed and sent out a questionnaire survey to developers within companies and shared the survey via social networks. We ask if developers believe that clean code eases the process of reading, modifying, reusing, or maintaining code. We also investigate whether developers write clean code initially or refactor it to become clean code, or do none of these. Finally, we ask developers in practice what clean code principles they agree or disagree with. Asking this will help identify which clean code principles developers think are helpful and which are not. Results. The results from the investigation are that the developers strongly believe in clean code and that it affects reading, modifying, reusing, and maintaining code, positively. Also, developers do not write clean code initially but rather refactor unclean code to become clean code. Only a small portion of developers write clean code initially, and some do what suits the situation, while some do neither of these. The last result is that developers agree with most of the clean code principles listed in the questionnaire survey and that there are also some principles that they discard, but these fewer. Conclusions. From the first research question, we know that developers strongly believe that clean code makes the code more readable, understandable, modifiable, or reusable. Also, developers check that the code is readable using code reviews, peer reviews, or pull requests. Regarding the second research question, we know that developers mostly refactor unclean code rather than write clean code initially. The challenges are that to write clean code initially, a developer must have a solid understanding of the problem and obstacles in advance, and a developer will not always know what the code should look like in advance. The last research question showed that most developers agree with most of the clean code principles and that only a small portion of developers disagree with some of them. Static code analysis and code quality gates can ensure that developers follow these clean code practices and principles.

Stora och komplexa kodbaser med bristfällig kodförståelse är ett problem som blir allt vanligare bland företag idag. Bristfällig kodförståelse resulterar i längre tidsåtgång vid underhåll och modifiering av koden, vilket för ett företag leder till ökade kostnader. Clean Code anses enligt somliga vara lösningen på detta problem. Clean Code är en samling riktlinjer och principer för hur man skriver kod som är enkel att förstå och underhålla. Ett kunskapsglapp identifierades vad gäller empirisk data som undersöker Clean Codes påverkan på kodförståelse. Studiens frågeställning var: Hur påverkas förståelsen vid modifiering av kod som är refaktoriserad enligt Clean Code principerna för namngivning och att skriva funktioner? För att undersöka hur Clean Code påverkar kodförståelsen utfördes ett fältexperiment tillsammans med företaget CGM Lab Scandinavia i Borlänge, där data om tidsåtgång och upplevd förståelse hos testdeltagare samlades in och analyserades. Studiens resultat visar ingen tydlig förbättring eller försämring av kodförståelsen då endast den upplevda kodförståelsen verkar påverkas. Alla testdeltagare föredrar Clean Code framför Dirty Code även om tidsåtgången inte påverkas. Detta leder fram till slutsatsen att Clean Codes effekter kanske inte är omedelbara då utvecklare inte hunnit anpassa sig till Clean Code, och därför inte kan utnyttja det till fullo. Studien ger en fingervisning om Clean Codes potential att förbättra kodförståelsen. / Summary: Big and complex codebases with inadequate understandability, is a problem which is becoming more common among companies today. Inadequate understandability leads to bigger time requirements when maintaining code, which means increased costs for a company. Clean Code is according to some people the solution to this problem. Clean Code is a collection of guidelines and principles for how to write code which is easy to understand and maintain. A gap of knowledge was identified, as there is little empirical data that investigates how Clean Code affects understandability. This lead to the following the question: How is the understandability affected when modifying source code which has been refactored according to the Clean Code principles regarding names and functions? In order to investigate how Clean Code affects understandability, a field experiment was conducted in collaboration with the company CGM Lab Scandinavia in Borlänge. In the field experiment data in the form of time and experienced understandability was collected and analyzed.The result of this study doesn’t show any clear signs of immediate improvements or worsening when it comes to understandability. This is because even though all participants prefer Clean Code, this doesn’t show in the measured time of the experiment. This leads me to the conclusion that the effects of Clean Code aren’t immediate, since developers hasn’t been able to adapt to Clean Code, and therefore are not able to utilize its benefits properly. This study gives a hint of the potential Clean Code has to improve understandability

As software systems grow in size they will also grow in complexity. If the increased complexity is not managed the system will be increasingly difficult to maintain. The effect of unmaintainable software is even more distinct when using a agile development process. By increasing the maintainability of the system these problems will be dealt with and the system can be extended with sustained efficiency. This thesis will evaluate the development process of a modern, agile company in order to find changes that will promote increased maintainability. The result is an modified process that will increase the maintainability with the smallest possible overhead for the development organisation. The result is based on earlier studies of development technologies that have proven to increase the maintainability. The implementation of these technologies are adjusted to fit the development team, and some of the technologies that are not suitable for the team are rejected.

Reaktiv programmering är ett programmeringsparadigm som har utvecklats för att underlätta byggande av händelsedrivna reaktiva applikationer. Dess förespråkare hävdar att det kan leda till ökad kodkvalitet, men få studier har utförts för att underbygga dessa påståenden empiriskt. Denna studie syftade till att undersöka skillnaden i kodkomplexitet och kodläsbarhet mellan traditionell imperativ programmering och reaktiv programmering. En fallstudie utfördes där koden för ett befintligt öppen källkodsprojekt omstrukturerades, vilket resulterade i en imperativ version och en reaktiv version av samma kod. Verktyg för statisk källkodsanalys användes för att undersöka om några förändringar i kodläsbarhet och kodkomplexitet kunde upptäckas. Vidare diskuteras huruvida resultaten av den senaste teknikens läsbarhetsmätvärden ger en exakt förutsägelse av kodläsbarheten i reaktiva kodbaser, eller om kanske dessa mätvärden behöver modifieras för att göra dem tillämpliga på det reaktiva paradigmet. Våra resultat visar att läsbarheten påverkades negativt av reaktiv programmering när den mättes med senaste teknikens läsbarhetsmätvärden, men kodkomplexiteten minskades betydligt. / Reactive programming is a programming paradigm that has been proposed to facilitate building eventdriven reactive applications. It is claimed by its proponents to increase code quality, but few studies have been performed to substantiate these claims empirically. This study aimed to explore the difference in code complexity and code readability between traditional imperative programming and reactive programming. A case study was performed where the code of an existing open source project was restructured, resulting in an imperative version and a reactive version of the same code. Static analysis tools were used to investigate if any changes in code readability and code complexity could be detected. Furthermore, it is discussed whether the results of the state-of-the-art readability metrics give an accurate prediction of code readability in reactive code bases, or if perhaps these metrics need to be modified to make them applicable to the reactive paradigm. Our findings show that the readability was negatively affected by reactive programming when measured with state-of the-art readability metrics, however code complexity was decreased significantly

Much of software engineering research and practice is concerned with improving software quality. While enormous prior efforts have focused on improving the quality of programs, this dissertation instead provides the means to educate the next generation of programmers who care deeply about software quality. If they embrace the culture of quality, these programmers would be positioned to drastically improve the quality of the software ecosystem. This dissertation describes novel methodologies, techniques, and tools for introducing novice programmers to software quality and its systematic improvement. This research builds on the success of Scratch, a popular novice-oriented block-based programming language, to support the learning of code quality and its improvement. This dissertation improves the understanding of quality problems of novice programmers, creates analysis and quality improvement technologies, and develops instructional approaches for teaching quality improvement. The contributions of this dissertation are as follows. (1) We identify twelve code smells endemic to Scratch, show their prevalence in a large representative codebase, and demonstrate how they hinder project reuse and communal learning. (2) We introduce four new refactorings for Scratch, develop an infrastructure to support them in the Scratch programming environment, and evaluate their effectiveness for the target audience. (3) We study the impact of introducing code quality concepts alongside the fundamentals of programming with and without automated refactoring support. Our findings confirm that it is not only feasible but also advantageous to promote the culture of quality from the ground up. The contributions of this dissertation can benefit both novice programmers and introductory computing educators. / Doctor of Philosophy / Software remains one of the most defect-prone artifacts across all engineering disciplines. Much of software engineering research and practice is concerned with improving software quality. While enormous prior efforts have focused on improving the quality of programs, this dissertation instead provides the means to educate the next generation of programmers who care deeply about software quality. If they embrace the culture of quality, these programmers would be positioned to drastically improve the quality of the software ecosystem, akin to professionals in traditional engineering disciplines. This dissertation describes novel methodologies, techniques, and tools for introducing novice programmers to software quality and its systematic improvement. This research builds on the success of Scratch, a popular visual programming language for teaching introductory students, to support the learning of code quality and its improvement. This dissertation improves the understanding of quality problems of novice programmers, creates analysis and quality improvement technologies, and develops instructional approaches for teaching quality improvement. This dissertation contributes (1) a large-scale study of recurring quality problems in Scratch projects and how these problems hinder communal learning, (2) four new refactorings, quality improving behavior-preserving program transformations, as well as their implementation and evaluation, (3) a study of the impact of introducing code quality concepts alongside the fundamentals of programming with and without automated refactoring support. Our findings confirm that it is not only feasible but also advantageous to promote the culture of quality from the ground up. The contributions of this dissertation can benefit both novice programmers and introductory computing educators.

The importance of software code quality is increasing rapidly. With more code being written every day, its maintenance and support are becoming harder and more expensive. New automatic code review tools are developed to reach quality goals. One of these tools is SonarQube. However, people keep their leading role in the development process. Sometimes they sacrifice quality in order to speed up the development. This is called Technical Debt. In some particular cases, this process can be admitted by the developer. This is called Self-Admitted Technical Debt (SATD). Code quality can also be measured by such static code analysis tools as SonarQube. On this occasion, different issues can be detected. The purpose of this study is to find a connection between code quality issues, found by SonarQube and those marked as SATD. The research questions include: 1) Is there a connection between the size of the project and the SATD percentage? 2) Which types of issues are the most widespread in the code, marked by SATD? 3) Did the introduction of SATD influence the bug fixing time? As a result of research, a certain percentage of SATD was found. It is between 0%–20.83%. No connection between the size of the project and the percentage of SATD was found. There are certain issues that seem to relate to the SATD, such as “Duplicated code”, “Unused method parameters should be removed”, “Cognitive Complexity of methods should not be too high”, etc. The introduction of SATD has a minor positive effect on bug fixing time. We hope that our findings can help to improve the code quality evaluation approaches and development policies