Getty Images/iStockphoto
5 ways to write maintainable automation code
Development teams can ensure the automation code they write is maintainable if they're careful about their tooling and the processes they adhere to. Consider the five rules below.
One of the oldest challenges in software creation is how best to balance ease of development against writing maintainable code. Organizations struggle to achieve an equilibrium, and both goals often end up being compromised.
Automation tools can help teams strike the right balance -- but only when development teams use them correctly. When developers don't, these tools can make things worse.
To write maintainable code, try following these five rules:
- Involve all development teams in tool selection.
- Take advantage of reusable elements.
- Be hierarchical in your thinking.
- Include your automation optimization practices and tools in code review and testing.
- Establish a feedback process from each step in development/maintenance to earlier steps.
1. Involve all development teams in tool selection
Establish best practices for tool selection across all dev teams. The first rule in tidy automation code is the most important, and the hardest. The best approach is to gather a lead developer from each team and ask them to lay out the rules. These rules should be based on their experiences with the areas where automation is most likely to be of value and the ways that standardizing the way code automation is done would benefit both current coding and later maintenance.
Also, this is a good opportunity to look at static code analysis and code review strategies and tools. Many users like to run a de-lint tool to check for basic problems even before code review. However, the value of de-linting will depend on the programming language. Interpretive languages such as Python or JavaScript benefit from more casual de-linting, where full static code analysis is more useful for compiled languages.
2. Take advantage of reusable elements
Make frequently used elements reusable. Accordingly, select tools to address each type of element or each point in your development process. Through both practices and tools, a team can introduce reusable modules, templates, design patterns and other concepts.
The areas that the lead developers believed could benefit from code automation are the obvious targets here. It's important to be able to identify code elements that should be made available as separate modules or classes, design patterns that should guide code structure, and templates that will help speed up the getting-started process. Each of these code elements may require their own tools, but the goal is always to make them useful enough to justify requiring developers to learn and use them.
Specific tool examples here relate to maintaining templates, boilerplate and snippets. Check out Angular and React, with the former more useful for dynamic web applications and the latter for specific JavaScript. Your chosen IDE may also have plugins to manage snippets.
3. Be hierarchical in your thinking
Tools should match a team's strategy. Start your code automation and code maintainability planning early. Link tools and steps as tightly as possible, with tool-level coupling or best practices. A lot of code automation initiatives get bogged down because the tools and practices don't dovetail, making them harder to learn and remember. Your strategy should fit, and your tools should enforce both practices and the flow between them.
Tools that help in hierarchical code automation typically target the DevOps or CI/CD markets, meaning that they're broader development, testing and deployment packages. In most cases, organizations will have this framework of tools in place. Try to work both practices and tools into your existing framework, unless doing so is too difficult. It's probably unwise to pick a different DevOps or CI/CD framework just for code automation, but if you cannot integrate code automation easily, you might want to see if something better can be found.
4. Automation optimization practices and tools
Include automation optimization practices and tools in code review and testing processes. Many code automation projects never consider anything beyond the initial development of the code and leave a mess behind for those who review things later. You should expect to prototype your strategy and ensure that the code automation improves references to the code that occur later in the development lifecycle.
When choosing a code review tool, be sure to consider other factors besides code automation. Look at your current practices and tools; see how well code automation fits. Many companies rely on procedures rather than tools for code review. If you're in that situation, look at tools that fit with your code management and repository strategy (GitHub). Popular tools include the open-source Review Board, Phabricator and Gerrit. Read up on the tools carefully before you begin a trial; each may be a best fit for different development/review models.
5. Establish proper feedback processes
Establish a feedback process from each step in development/maintenance to earlier steps. You may get it right the first time, but you probably won't. Development teams often report that people learn to accept code-automation problems, particularly right after a change in tools or practices, just to be able to get on with things. Early feedback can tune things gradually and ensure that you get an optimum outcome.
This feedback is easiest to provide using your overall development pipeline tools, but it benefits from strong collaboration support. If you think your chosen tool doesn't offer that, it may be time to try a different tool.
Above all, be careful how you manage that tradeoff between development and maintenance. You never want to compromise one to benefit the other. It pays to be even-handed.
