Hackable Projects – Pillar 1: Code Health
In this blog post, author Patrik Höglund talks about how over the years, software development can become stressful to deal with and fix constant issues. The way he suggests to resolve this issue is by making the software more “hackable”; not in the sense of making the software more vulnerable to attacks, but making it easier to modify from a developers stand point. Höglund goes on to say that a hackable project is one that includes easy development, fast builds, good and fast tests, clean code, easy running and debugging, and “one-click” rollbacks. Höglund then goes on to describe the three main pillars of hackability, which are code health, debuggability, and infrastructure.
This post focuses solely on the first pillar of hackability: Code Health.
The first thing Höglund covers are tests that you should use. He says that “unit and small integration tests are probably the best things you can do for hackability” rather than using end-to-end testing. The other thing to testing is that if you have poorly tested legacy code, the best thing to do is refactor it and add tests along the way. Even though this can become time consuming, it’s work it in the end because it leads to a more hackable system in the long run.
The next thing that should be done is to make sure that your code is readable and goes through code review. This means that there should be a reviewer who looks over the code changes to make sure that the new code is consistant with the rest of the code. The changes should also be small and coded cleanly so as to make it easy if a rollback is necessary. Another thing that will help with hackability is making sure that all of your code is submitted in a constistant format.
To reduce risks even more, you should try to consistantly have a single branch for your project. This not only decreases the possible risks, but also reduces the expense of having to run tests on multiple branches. This could possibly back fire though if, as Höglund writes, “Team A depends on a library from Team B and gets broken by Team B a lot.” Höglund suggests that “Team B might have to stabalize thier software for them to use this method and have hackable software.
The last things that Höglund focuses on for Code Heath is making sure that your code has loose coupling, testability, and ways that you can aggressively reduce technical debt.
From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.
