Looking for dopamine to develop or rid ourselves of the routine

Everyone who begins his way as a programmer has a huge supply of enthusiasm that supports the developer for many years. Every day something new, new methods of solving problems, technology, and even a minimum of result - brings it to the seventh heaven. But as time goes on, your code is "fixed" and all actions that were previously new are becoming routine. At such times, to support motivation without introducing a new one, every day it is necessary to develop your receptors of getting pleasure, one of the methods of this is to organize your workflow for maximum visibility of the result. About this under the cut.

About me

I am a PHP developer with 5 years of experience, in my practice I managed to try in production a lot of different things, ranging from the Zend Framework, ending with the Symfony-Laravel ecosystem, Memcached-Redis, MySQL-Postgres, MongoDB, RabbitMQ-Gearman, etc. Over time, a stack of technologies that captures you is reduced, and with it rolls longing for that past sense of knowledge. All my code and workflows underwent mutations from editing samopisnyh sites via FTP in production, to a competent approach of deployment and code analysis. In my experience, I highlighted a list of what allows you to get maximum motivation with a minimum of actions.

Note : You should not take the information below as a benchmark of the organization of the software, this information can serve only as an example for studying similar approaches in your ecosystem. Some things may not be applicable for a certain range of systems, but even there the general principles remain the same.

Ease of development

This is not about orthopedic chairs and a dozen of monitors (although with a budget this is hardly harm), but a very simple and at the same time important area - development tools. If you are seriously engaged in the project - you just need to customize your work environment as conveniently as possible. Ideally, use 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 of frameworks and integrations. For example: developing on Symfony from under PhpStorm - greatly simplifies the life of the Symfony Plugin + PhpAnnotations Plugin. Thus, part of the mental activity is carried out on the "outsourcing" 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 of equal importance. This is quite a routine process, which can sometimes reduce your motivation to zero. Start small — cover the end-parts of your application with tests, for example, working with third-party Api, simple business logic at the I / O level, etc., this will show you this functionality, on the other hand, will let you know what decisions were made correctly in a particular case, and which is better to reconsider immediately. Stability and quality of the developed product will increase, and this is already a big plus.

But how to get from this share of deserved dopamine? Generate coverage + static code analysis. Output reports can be deployed on a test server (staging, for example) for constant availability to the developer (team). They turn the entire test coverage process into a kind of game, display the classes that are covered with tests, and highlight what else needs to be covered, encouraging them to “pass these levels” to minimize the blocks of uncovered functionality. For example, for PHP projects for unit tests, you typically use PhpUnit, in the start command of which you can add the --coverage-html parameter (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 reporting reports, take care of hiding them from the outside world, because it is a storehouse of information about your product that may contribute to its compromise. Do not forget about security in performing any action.

Versions

No matter how trite it may seem - use version control systems! I know a lot of developers for whom this is “superfluous problems”, although the systems they support have long gone beyond CRUD. Version control systems at least allow you to backup your code, as a maximum - to correctly control the rolling out of the code, comparison, versioning, and much more. How to capitalize on this dopamine - each feature in its branch allows you to visualize the process of pouring code into the mainstream, tags - allow you to conduct your production by version and observe the progress from version to version. It is, in fact, very much further.

Build and Distribute

It so happened that people are accustomed to thinking of compiling a program as an assembly, omitting in this concept the systems that the interpreter launches. In our century of a million PHP packages and billion js of libraries, the concept of assembly is no longer something purely compiler, the number of operations on the system required to launch it has long exceeded one dozen, so it is important to maximize the process of deploying 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 through the composer and describe the build tasks in a fairly convenient format (although xml, but even a novice can understand it intuitively). The purpose of these manipulations is to reduce the development of the product before pressing the button “do everything well”.

Pulling up packages, delivering up-to-date configs, starting migrations, running tests, warmup cache is a small part of what a collector can do. Even if your code still does not deploy anywhere, in the future, having a car collector will significantly simplify the beginning of project development on a new machine and significantly simplify deployment and software releases. Paired with Continuous Integration (CI) systems - the whole routine goes on the shoulders of machines, giving you space for imagination and, directly, solving problems. Well, and at least, we have less chance to forget to do something with a delay.

How to squeeze a drop of dopamine out of 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 the minimum number of hours spent, the feeling that the machine works for you is indescribable. For example, I use Jenkins as a CI system with the Phing plugin installed. It is enough to choose the “Invoke Phing Target” assembly step in the collector - and everything will rustle, make sure that it is assembled.

General process visualization

Very charged with a sense of control over the system, so try to visualize the maximum of the products you use. Starting with statistics on server load, to visualization of 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 content of queues, it helps a lot in debugging, and in production - to control the optimality of the processes.

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

Compatibility

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

Conclusion

In a world where there are so many technologies, where a constantly growing amount of information puts pressure on 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 the Monkey-job and then even the most boring tasks will bring great pleasure.

Conclusion

This post is intended primarily for developers above beginner who want to improve (or compare) their workflow. All the material presented is taken purely from my own experience, if there are any remarks - I’ll be happy to hear in the comments.