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

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

Background: With the development of software, its quality is increasingly valued by people. The developing technical ability was absolutely taken to underpin the performance of the developer, and code quality was raised as being related to developer performance, thus code quality could be a measure of developer performance. Developer performance is often influenced by multiple factors. Also, different factors have different impacts on developer performance in different project types. It is important for us to understand the positive and negative factors for developer performance in a certain project. If these factors are valued, developers will have better performance and project will have higher quality.   Objectives: The objective of our study is to identify how factors (developer experience, task size, and team size) impact the developer performance in each case. Though understanding how factors impact the developer performance, developers can have a better performance, which is a big benefit to the quality of project.   Methods: We decided to use the characteristics of commits during the Gerrit code review to measure the committed code quality in our research, and from committed code quality we can measure  the developer performance. We selected two different projects which use Gerrit code review as our cases to conduct our archive study. One is the legacy project, another is the open-source project. Then we selected five common characteristics (the rate of abandoned application code, the rate of abandoned test code, abandoned lines of application code, abandoned lines of test code and build success rate) to measure the code quality The box plot is drawn to visualize the relationship between the factor experience and each characteristic of the commits. And Spearman rank correlation is used to test the correlation between each factor and characteristic of commits from the statistical perspective. Finally, we used the multiple linear regression to test how a specific characteristic of commits impacted by the multiple factors.   Results: The results show that developers with high experience tend to abandon less proportion of their code and abandon less lines of code in the legacy project. Developers with high experience tend to abandon less proportion of their code in the open-source project. There is a similar pattern of the factor task size and the factor amount of code produced in these two cases. Bigger task or more amount of code produced will cause a great amount of code abandoned. Big team size will lead to a great amount of code abandoned in the legacy project.   Conclusions: After we know about how factors (experience, task size, and team size) influence the developers' performance, we have listed two contributions that our research provided:  1. Big task size and big team size will bring negative impact to the developer performance.  2. Experienced developers usually have better performance than onboarded developers. According to these two contributions, we will give some suggestions to these two kinds of projects about how to improve developer performance, and how to assign the task reasonable.