Looking for dopamine to work out or free ourselves from the routine

image


Everyone who begins his career as a programmer has a huge reserve of enthusiasm that has supported the developer for many years. Every day, something new, new methods of solving problems, technology, and even a minimum of results - raises to the seventh heaven. But time goes on, your code "settles down" and all actions that used to be new to you become a chore. At such moments, in order to support motivation without introducing a new one, it is necessary to develop your own receptors for pleasure every day, one of the methods for this is to organize your workflow for maximum visibility of the result. About this under the cut.


About me


I’m a PHP developer with 5 years of experience, in my practice I managed to try a lot of different things in production, starting from the Zend Framework, ending with the Symfony-Laravel ecosystem, Memcached-Redis, MySQL-Postgres, MongoDB, RabbitMQ-Gearman, etc. Over time, the stack of technologies that capture you decreases, and with it a longing for that former sensation of knowledge is rolling. All my code and workflow went through mutations from editing self-written sites via FTP in production to a competent deployment approach and code analysis. In my experience, I have identified a list of what allows you to get the maximum motivation with a minimum of action.


Note : Do not take the information below as a standard for software organization, this information can only serve as an example for the study of such approaches in your ecosystem. Some things may not be applicable for a certain circle of systems, but even there the general principles remain the same.


Development convenience


This is not about orthopedic chairs and a dozen monitors (although it is unlikely to hurt if you have a budget), but about a very simple and at the same time important area - development tools. If you are seriously engaged in a project, you just need to configure your work environment as conveniently as possible. Ideally, use an IDE with integration and analysis, not only the syntax and logic of all the PLs that are used, but also with analysis at a higher level - at the framework and integration level. For example: developing on Symfony from under PhpStorm - greatly simplifies the life of Symfony Plugin + PhpAnnotations Plugin. Thus, part of the mental activity is outsourced in the IDE, and frees the brain for more serious work.


Code Analysis and Testing


Many developers are engaged in purely functional development, but, as practice shows, the basic coverage of unit tests is no less important. This is a fairly routine process, which can sometimes reduce your motivation to zero. Start small - cover the End-parts of your application with tests, for example - work with third-party Api, simple business logic at the I / O level, etc., this will show you this functionality on the other hand, it will allow you to realize what decisions were made right in a particular case, and which is better to immediately review. The stability and quality of the developed product will increase, and this is a big plus.


But how to get the share of well-deserved dopamine from this? Generate coverage + static code analysis. Output reports can be deployed on a test server (staging, for example) for constant availability to their developer (team). They turn the entire test coverage process into a kind of game, display classes that are covered by tests, and highlight what else needs to be covered, stimulating "to pass these levels" to minimize blocks of uncovered functionality. For example, for PHP projects for unit tests, they usually use PhpUnit, in the launch command of which you can add the --coverage-html parameter (it is better to look at --help for more detailed documentation), which will generate coverage in a human-friendly format. For static code analysis in PHP, you can use the following products - phplint, phploc, phpcs, phpcpd, phpmd.


CAUTION : When you deploy reports somewhere, take care to hide them from the outside world, because this is a storehouse of information about your product that may contribute to its compromise. Do not forget about safety in performing any actions.


Versions


No matter how banal it sounds - use version control systems! I know a lot of developers for whom these are "extra problems", although the systems they support have long exceeded CRUD. Version control systems at least allow you to backup your code, at a maximum - competently control code rolling, comparison, versioning and much, much more. How to make dopamine on this - each feature in its branch allows you to visualize the process of injecting code into the mainstream, tags - allow you to conduct your production by version and observe the progress from version to version. This, in fact, moves very much further.


Assembly and distribution


It just so happened that people are accustomed to consider a compilation of a program as an assembly, omitting in this concept the systems that the interpreter starts. In our century, a million PHP packages and a billion js libraries, the concept of assembly is no longer purely compiler, the number of actions on the system necessary to run it has long exceeded 1 dozen, so it is important to speed up the deployment process of a particular application by automating routine actions . There are many applications that build your product; for PHP, I chose Phing for myself, which can be easily installed via composer and describe assembly tasks in a fairly convenient format (even though xml, but it is intuitive even for a beginner using an example). The purpose of these manipulations is to reduce the scan of the product to the click of the "do everything well" button.


Pulling packages, delivering up-to-date configs, starting migrations, running tests, warmup cache - this is a small part of what the collector can do. Even if your code is not deployed yet, in the future, the presence of an auto-collector will greatly simplify the start of project development on a new machine and greatly simplify the deployment and software releases. Paired with Continuous Integration (CI) systems - all the routine goes to the shoulders of the machines, providing you with space for imagination and, directly, problem solving. Well, and at least we have less chance of forgetting to do something during the deployment.


How to squeeze a drop of dopamine from this - find a balance in automating the assembly of your product, start with simple things, and try to see how it works even in the sandbox, even with a minimal amount of hours spent, the feeling that the machine works for you is indescribable. For example, I use Jenkins as a CI system that has the Phing plugin installed. It is enough in the collector to choose the assembly step "Invoke Phing Target" - and everything will rustle, be assured, assemble.


General process visualization


The feeling of control over the system is very charged, so try to visualize the maximum of the products that you use. Starting with statistics on server loading, to visualizing various software that your product works with. For example - for RabbitMQ there is a Management Plugin, in the form of a web-interface for viewing statistics and the contents of queues, it helps a lot in debugging, and in production - for controlling the optimal operation of processes.


In general, there is a lot of software for visualizing logs that can be tailored to your needs, the main goal is to provide yourself with the maximum possible visualization of what is happening in your products (especially relevant for Service Oriented Architecture (SOA), where many components communicate with each other) . Information about your system will provide not only the ability to quickly debug what is happening, but also moral satisfaction from observing changes and dynamics. All narrow necks are immediately visible, all non-optimal parts of the system under your supervision.


Compatibility


If the product goes beyond the framework of one system, it will be a very wise decision to keep versions of each subsystem (module) and make maps of their compatible versions, updating them with each release. Such an approach will allow to get out of the head information on their features, what version was added there and whether it will break all the work. This way you can save yourself and other developers from the routine of digging commit stories to determine if everything is okay there.


Conclusion


In a world where there are so many technologies, where an ever-growing amount of information is pressing you from all sides, it is very important to have space for flexibility, both in your product and in your thoughts. The main message - look for something that allows you to visualize progress, save yourself from Monkey-job and then even the most boring tasks will bring great pleasure.


Conclusion


This post is intended primarily for developers above the novice who want to improve (or compare) their workflow. All the material presented is taken purely from my experience, if there are comments, I will listen with pleasure in the comments.


Also popular now: