7 Habits of Highly Effective Maven Users
One of the biggest leaps forward in my productivity and satisfaction as a developer was experienced when I learnt about and adopted Maven for my Java projects.
If you aren’t familiar with it, Maven is a tool for managing the life-cycle of a Java project. Think compilation, testing, packaging, releasing, deployment, generation of documentation etc – all of the ‘stuff’ that comes between writing code and actually delivering it into an environment or release.
It’s subtle, but having applied Maven and seen the benefits that it’s brand of ‘project automation’ can bring first hand, I think you can take a number lessons from it into your more general approach to software development and work.
Or to put it another way, even when you find yourself working on platforms and projects that are not relevant to Maven, you’ll likely take a better and more structured approach for having used it.
I’m going to expand on these lessons and habits below.
The number one win with Maven is the scope for automation it gives you. Without writing a line of code or configuration, you’ll be able to do things such as download project dependencies, build project artifacts, run test suites, deploy, and generate documentation, all by running a single command.
Being able to carry out these diverse tasks without any manual steps is a real eye opener to how automating can save time and effort, and I’ll now look to automate judiciously in any technical and development work I do.
- Time spent automating is nearly always worth it – especially when the results of the automation are shared across the team;
- Being able to execute steps in an automated and repeatable way means they can happen more often – improving quality and responsiveness of the team (think testing and regular releases);
- Automation reduces the key man syndrome – for instance, the situation where only a single person knows how to build an installer or configure the software;
- It’s worth becoming comfortable with an ad-hoc scripting language and script out anything that you are likely to need more than once.
By various means, Maven goes to great lengths to give you repeatable builds and processes. Typically, if a build and install works on one developers machine, it will usually work one other developers machines and the continuous integration servers.
This sounds like a simple thing, but it’s very hard to get right – all too often, development teams have lots of hidden environmental issues and special bits of knowledge that they need to know to go from source code to released artifact. Using Maven to eradicate these specifics can make processes flow much smoother in my experience, and I now strive for repeatability much more than previously.
- Repeatability leverages your investment effort. One person does the setup work, and everyone else in the team benefits from that time and time again;
- Repeatability aids planning and removes surprises. Over time you’ll learn how long a test suite or a release takes, and you’ll have worked out the kinks in the system such that they can be executed reliably at crunch points in the project;
- ‘It works on my machine’ is not a valid definition of done! Your responsibilities extend beyond this!
Maven has specific phases of it’s life cycle explicitly for running tests, and by convention, specific places for storing tests in your code base. If you don’t have unit tests, Maven will make you feel guilty each time you see that phase of the build whizz by. If you do have them, they better be up to scratch because by default, it will fail the build if your tests fail.
Maven won’t make a team write good tests, but it’ll certainly raise their visibility as first class citizens of the software development process.
- Prefer developer testing over a reliance on QA;
- Automated testing is infinitely preferable to manual testing;
- Unit tests and integration tests are separate, but equally important parts of your automated testing strategy;
- Testing and verification is a first class part of the development life-cycle;
- Tests should act like a gatekeeper that must be passed before the software can progress. The development team should buy into this attitude and not leave failing tests hanging around.
Maven encourages you to structure code into small, loosely coupled, standalone components, which are bundled, managed, and released as separate artifacts.
More projects should do this anyway, but it is easy to put off modularizing and setting subsystems boundaries. Indeed, I’ve seen many a code base evolve to the point that splitting it would require too high an investment.
Mavens conventions here have undoubtedly driven me into the habit of structuring code as independent and reusable modules.
- Component based development with clear boundaries between each improves reuse, and results in better software design and higher software quality;
- Decide on component boundaries early as they can be difficult to introduce later on.
Consistency and Standardization
Maven encourages consistency, standardization, and convention over configuration. This is great for developers who use Maven, in that you can instantly open up a Maven project and understand how it is structured, how it is built, tested, released etc. This can save a lot of time ‘getting up to speed on the build’ when joining new companies or projects.
In addition, Maven very much takes a ‘convention over configuration’ approach, assuming sensible defaults for nearly everything (whilst giving you the power to customize if you need to.)
- Software is complex enough. Remove the burden on the team by adopting standards and conventions as much as possible in relation to the more ‘mundane’ and process stuff;
- Prefer ‘convention over configuration’. Don’t place lots of configuration effort on developers or users, who usually, just want to get the job done;
- Watch out for ‘not invented here’ syndrome – there’s lots of arguments for custom, but standardization and off the shelf should be the default choice;
- Breaking from a standard needs to be heavily justified as this results in ongoing costs.
Maven incorporates a ‘site’ feature which allows you to automatically build automated documentation for your project. It’s a rare developer who enjoys writing documentation, but the site can generate a lot of automated reports and information about the code base, such as unit test reports, Javadoc, and code coverage analysis. It’s also generally really simple to integrate Maven with code quality tools such as coverage and static analysis tools, and route these into your site.
Using the Maven site demonstrated to me how documentation can really lead to improvements in code quality, and extra transparency for other stakeholders of the development projects.
- Developer documentation is genuinely valuable.
- Sensible use of documentation can really make a development project more transparent to the stakeholders;
- Look at how to automate the development project to produce artifacts that are useful to other stakeholders – e.g. automated test results and documentation;
- Static analysis tools aren’t as useful as you would expect, but still have some value relative to the time it takes to set them up.
Release Management & Versioning
Maven puts a lot of structure around releases management and versioning, introducing a version number scheme for each component, a SNAPSHOT system when developing between versions, and a declarative dependency management system which will allow you to specify which versions of which components in your system are compatible with one another.
A ‘mvn release’ command can then use this information to prepare and build the entire release, tagging source code files and pushing artifacts to some centralized repository when they are ready.
- Automate the entire development process right up to packaged release artifacts;
- Make use of centralized enterprise repositories to share components across the business;
- Make it really simple to rebuild previous versions of the software for debugging or investigation.
So that’s it. A number of ways in which using Maven has improved my approach as a developer – making
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)