How to reduce downtime for programmers
In large development projects it is common for there to be long periods of time when programmers can not physically work, since the code is being compiled. This problem is known and you can even find jokes about it.
These periods are lost time since, although the programmer could continue working, there is a high risk that the compilation detected a problem 10 minutes later.
To avoid this, there are several things that can be done: from improving our processes to using tools that limit the need to compile so often. We are going to focus on the Java world, although it can be extended to other languages.
Compilation in Java
In Java, the compilation is no longer done by hand but with a builder like Maven, Ant or Gradle. These tools not only compile, but also run tests, package or perform another series of tasks that we may not need. Specifically, Maven runs two life cycles, two different compilations: clean), which erases all files produced by a previous build; and install), which generates code, compiles it, runs tests, creates JARs, copies them to our library repository … Many of these steps do not add value in development time, so the first thing we can do is use the right command at all times, normally “mvn clean compile” is enough.
Of course, if we only launch this command, the tests are not executed and we will not know if we are introducing problems in the code. Fortunately, any IDE, such as Eclipse, is capable of running those tests in isolation, so do it! Do not wait for Maven to run the whole battery of tests to see if you’ve broken anything.
Pay attention to the plugins. Maven is based on plugins. In our configuration there may be automated plugins within the life cycle, possibly making the build longer than necessary. This can be avoided if instead of executing “mvn compile” we execute “mvn compile: compile”.
Nowadays, all projects are composed of multiple modules. Another way to save time is to compile only the modified modules. Correct, but now we lose the integration tests that verify that two modules behave well together: execute the right test at the right time. Integration, regression, end-to-end, etc., tests are not designed for every small code change. Each test is designed for one phase of the development cycle. Specifically, the integration tests make sense in Continuous Integration (CI) and Continuous Deployment (CD). Execute them then!
It is logical to want to test your application simulating the production environment, for example with Web Logic, and it can be done, but deploying an application in Web Logic is slower than doing it in Tomcat or JBOSS. In addition, the server can be integrated into the IDE so that the deployment is automatic.
In cases very specific, very controlled, knowing what is done, to test local server, and s can save time if we ignore the tests to deploy, for example, Cargo, adding a parameter -DskipTests our Maven.
Not only Maven
We’ve talked a lot about Maven but there are alternatives. Maven is not to run builds often, or when we want to customize it. Gradle for example, allows creating different build cycles based on graphs, so they can be executed incrementally, that is, those modules that have not changed do not need to be recompiled, saving a lot of time.
Once we have put all these recommendations into practice, we can still improve with auto-updatable virtual machines (Java forces the machine to restart to load the changes). There are alternatives such as JRebel or DCEVM that automatically upload new classes to the machine, if necessary.
In any case, analyze well what you do, may the needs, interfaces with other services, etc., are not well defined or that the design of the solution is not correct. In these cases, introducing a tool such as JRebel will only momentarily cover the problem and may reappear.