Quality control code in the future development of the project
Surely everyone is familiar with the situation when the development of a project rests on some kind of wall, the introduction of new functions becomes more and more time-consuming and financial. And, unfortunately, such moments are not rare when the scales with the price begin to significantly outweigh the possible benefits from the realization of one or another function.
This is a fairly standard and, in many ways, the usual course of events. With experience, we are trying to make disparate attempts to improve the situation, and not to allow the mistakes of the past. But often, it’s not enough to collect everything in a heap to organize any sane system. And, to find any universal solution, up to the present, was not easy enough.
We have developed code quality control automation, which already works in our company and in some others. This implementation was created for the PHP language. Previously, it was only for Java and C #. However, the principles and approaches are applicable to all modern languages, therefore we invite you to discuss this important topic.
So, having analyzed a lot of different projects, the Software Improvement Group (SIG) specialists have developed a set of simple principles and rules, following which you can greatly improve this state of things. These principles were outlined in the Building Maintainable Software, Java Edition book guide : Ten Guidelines for the Future-Proof Code (ISBN print: 978-1-4919-5352-5, ISBN eBook: 978-1-4919-5348-8).
')
All the elements necessary to build a stable system in support are surprisingly simple and straightforward. They can easily be used for applications of any complexity. The greatest effect of this approach can be achieved if it is used from the very beginning of development, especially of complex software systems. However, using this guide already at later stages, it is possible to achieve a noticeable improvement in performance for new modules and a persistent reduction in the rate of complication of the system being created as a whole.
I will take the liberty to summarize the main points of this guide.
Some of these principles can be easily controlled automatically, for this purpose special software tools have been created for languages ​​such as Java and C #. We offer the simplest implementation of automatic control for PHP development in the form of a code sniffer. We have implemented the control of the following basic principles:
After the introduction of such control in our company, the quality of development has improved significantly. The code has become much easier to understand and support.
We offer you a basic solution for automatic control. The standard is easily integrated into the version control system. We recommend using it in conjunction with other stylistic standards adopted in your company.
We are fully aware of the fact that the introduction of even these several rules that we have integrated into the control system, especially in the early stages, will cause difficulties for programmers. These difficulties will be much easier to overcome if you are familiar with the content of Robert Martin’s Clean Code: Creation, Analysis, and Refactoring. Also in this book, the theoretical foundations of the above principles are described in sufficient detail. Most likely, for many the book is well known, it will perfectly complement the “Building Maintainable Software” manual.
It is very important, in my opinion, especially at the beginning, to carefully control the quality of the output code. It is necessary to avoid mechanical crushing of the code into the rules satisfying the pieces. Separation of functions and classes should occur according to all the rules of the OOP using design patterns, where necessary. One of the most important principles in this aspect can be considered the "Principle of sole responsibility". I would especially like to note the importance of the correct choice of names that clearly characterize the purpose of functions and classes. Such an approach, as we have noticed, quite quickly and effectively allows you to improve the level of programmers and the quality of their code.
We have laid out the full description on GitHub and will improve it further, implementing more and more principles.
Option 1.
The easiest option is to set the standard through the composer:
After installation, you can start checking the code. Suppose the files to be checked are in the src folder:
Option 2.
You can install the sniffer globally along with standard php sniffers. In a Linux environment, this can be done through PEAR. In the beginning, we set the basic standards, if they have not yet been established:
Find the directory with installed extensions (/ path / to / pear):
Go to the standards folder:
Clone standard:
You can set it as default:
Now the same check as in option 1 will look like this:
This verification from the command line is easy to use on the side of any continuous integration system.
When used on the programmer’s side, to control the quality of your own code, it is convenient to supplement the sniffer with another standard adopted by the project. To do this, you need to make changes to the ruleset.xml file located in the standard folder. There is a commented line in this file:
You can uncomment and insert your standard instead of PEAR, for example:
In this case, both standards and Secl and Symfony2 will be checked. In integrated development environments (IDE) with PHP_Sniffer support, such as PHPStorm, you can set up an automatic check in visual mode with emphasis on non-standard methods and classes, and error messages.
After such a setting, non-standard code will be underlined.
And when you hover the mouse cursor over the underlined line, a message about the violated rule will appear.
After correcting the situation, the underscore will disappear.
If desired, you can change the error policy to a warning policy for all, or part of the rules. This is done quite simply if you dig into the code of the sniffer. In this case, you can evaluate the code more gently, based on the permissible number of warnings. Perhaps this approach will be implemented in the future, but so far we do not see the need for such a solution.
This implementation is quite simple, but nevertheless it carries a good utility for the further development of the project. We have developed it for ourselves, we know that some companies have similar code quality control systems, but not public ones.
Use on health and write the correct code!
Ps . Our school is about to launch a five-month training course from the author of the article “I want to become Junior PHP Developer!” And “Symfony 2. Agile development . ” To enroll write to info@digitov.com
PPS To receive our new articles before others or simply not to miss new publications - subscribe to us on Facebook , VK and Twitter .
The authors:
Sergey Kharlanchuk, Senior PHP Developer, SECL Group Company
Nikita Semenov, CEO, SECL Group Company
This is a fairly standard and, in many ways, the usual course of events. With experience, we are trying to make disparate attempts to improve the situation, and not to allow the mistakes of the past. But often, it’s not enough to collect everything in a heap to organize any sane system. And, to find any universal solution, up to the present, was not easy enough.
We have developed code quality control automation, which already works in our company and in some others. This implementation was created for the PHP language. Previously, it was only for Java and C #. However, the principles and approaches are applicable to all modern languages, therefore we invite you to discuss this important topic.
So, having analyzed a lot of different projects, the Software Improvement Group (SIG) specialists have developed a set of simple principles and rules, following which you can greatly improve this state of things. These principles were outlined in the Building Maintainable Software, Java Edition book guide : Ten Guidelines for the Future-Proof Code (ISBN print: 978-1-4919-5352-5, ISBN eBook: 978-1-4919-5348-8).
')
All the elements necessary to build a stable system in support are surprisingly simple and straightforward. They can easily be used for applications of any complexity. The greatest effect of this approach can be achieved if it is used from the very beginning of development, especially of complex software systems. However, using this guide already at later stages, it is possible to achieve a noticeable improvement in performance for new modules and a persistent reduction in the rate of complication of the system being created as a whole.
I will take the liberty to summarize the main points of this guide.
The importance of simpler business support
- The timing of the introduction of new features is significantly less. The product is one step ahead of the competition.
- The time to fix bugs is significantly reduced. Customer and customers to win.
- Ease of introduction to the project of new developers. Risk diversification.
- Optimization for any other parameter of the system requires changes in the project code.
- Well supported code, as a rule, works much more stable. Changes in it have fewer side effects.
Features of implementation
- Maintainable code base is provided by the implementation of simple manuals.
- These guides should be followed from the very start of the project, the contribution of each developer is important.
- Some violations are much worse than others.
The list of recommendations
- Write short methods
- Write simple methods
- Write the code only once
- Try to create small interfaces for methods and constructors.
- Distribute tasks by module
- Create weakly coupled components
- Balance the components
- Try to write less code.
- Automate testing and deployment
- Write clean code
Some of these principles can be easily controlled automatically, for this purpose special software tools have been created for languages ​​such as Java and C #. We offer the simplest implementation of automatic control for PHP development in the form of a code sniffer. We have implemented the control of the following basic principles:
- The length of the functions should not exceed 15 lines of code;
- The cyclomatic complexity of the function should not be more than 5;
- Functions must not take more than 4 input arguments;
- A class must not contain more than 15 methods;
After the introduction of such control in our company, the quality of development has improved significantly. The code has become much easier to understand and support.
We offer you a basic solution for automatic control. The standard is easily integrated into the version control system. We recommend using it in conjunction with other stylistic standards adopted in your company.
We are fully aware of the fact that the introduction of even these several rules that we have integrated into the control system, especially in the early stages, will cause difficulties for programmers. These difficulties will be much easier to overcome if you are familiar with the content of Robert Martin’s Clean Code: Creation, Analysis, and Refactoring. Also in this book, the theoretical foundations of the above principles are described in sufficient detail. Most likely, for many the book is well known, it will perfectly complement the “Building Maintainable Software” manual.
It is very important, in my opinion, especially at the beginning, to carefully control the quality of the output code. It is necessary to avoid mechanical crushing of the code into the rules satisfying the pieces. Separation of functions and classes should occur according to all the rules of the OOP using design patterns, where necessary. One of the most important principles in this aspect can be considered the "Principle of sole responsibility". I would especially like to note the importance of the correct choice of names that clearly characterize the purpose of functions and classes. Such an approach, as we have noticed, quite quickly and effectively allows you to improve the level of programmers and the quality of their code.
We have laid out the full description on GitHub and will improve it further, implementing more and more principles.
How to use a sniffer?
Option 1.
The easiest option is to set the standard through the composer:
$ php composer.phar require --dev secl-group/phpcs-secl-standard:~1.0.0 After installation, you can start checking the code. Suppose the files to be checked are in the src folder:
$ bin/phpcs --standard=vendor/secl-group/phpcs-secl-standard/secl-group/phpcs/Secl --extensions=php src/ Option 2.
You can install the sniffer globally along with standard php sniffers. In a Linux environment, this can be done through PEAR. In the beginning, we set the basic standards, if they have not yet been established:
# pear install PHP_CodeSniffer Find the directory with installed extensions (/ path / to / pear):
# pear config-show | grep php_dir Go to the standards folder:
# cd /path/to/pear/PHP/CodeSniffer/Standards Clone standard:
# git clone https://github.com/SECL-Group/phpcs-secl-standard Secl You can set it as default:
# phpcs --config-set default_standard Secl Now the same check as in option 1 will look like this:
$ phpcs --standard=Secl --extensions=php src/ This verification from the command line is easy to use on the side of any continuous integration system.
When used on the programmer’s side, to control the quality of your own code, it is convenient to supplement the sniffer with another standard adopted by the project. To do this, you need to make changes to the ruleset.xml file located in the standard folder. There is a commented line in this file:
<!--<rule ref="PEAR"/>--> You can uncomment and insert your standard instead of PEAR, for example:
<rule ref="Symfony2"/> In this case, both standards and Secl and Symfony2 will be checked. In integrated development environments (IDE) with PHP_Sniffer support, such as PHPStorm, you can set up an automatic check in visual mode with emphasis on non-standard methods and classes, and error messages.
After such a setting, non-standard code will be underlined.
And when you hover the mouse cursor over the underlined line, a message about the violated rule will appear.
After correcting the situation, the underscore will disappear.
If desired, you can change the error policy to a warning policy for all, or part of the rules. This is done quite simply if you dig into the code of the sniffer. In this case, you can evaluate the code more gently, based on the permissible number of warnings. Perhaps this approach will be implemented in the future, but so far we do not see the need for such a solution.
This implementation is quite simple, but nevertheless it carries a good utility for the further development of the project. We have developed it for ourselves, we know that some companies have similar code quality control systems, but not public ones.
Use on health and write the correct code!
Ps . Our school is about to launch a five-month training course from the author of the article “I want to become Junior PHP Developer!” And “Symfony 2. Agile development . ” To enroll write to info@digitov.com
PPS To receive our new articles before others or simply not to miss new publications - subscribe to us on Facebook , VK and Twitter .
The authors:
Sergey Kharlanchuk, Senior PHP Developer, SECL Group Company
Nikita Semenov, CEO, SECL Group Company
Source: https://habr.com/ru/post/313104/
All Articles