Imagine you’re a software developer working on a financial application. One day you’re assigned (or, if you’re agile, you pick yourself) to implement changes to the overtime computation logic so your company can sell the application in France. In France, the official work week has 35 hours (lucky them) instead of the 40 hours in the US. Being new to the team, you’re not sure where to begin, so you start searching the codebase for the keyword “overtime.”
Let’s see the search results. No, no, no, maybe, no, no, maybe. Hmmm. OK, looks like it’s in this file, and then in this other file as well. Let’s take a look inside.
I see final static int HOURS = 8. What’s that? Looks like eight hours per day…maybe? Then final static int WEEK_HOURS = 40. Looks like 40 hours per week…maybe? Or maybe it’s in this method called getOvertime? I’m not sure where to find the logic I’m looking for.
This is a typical scenario when the meaning of the code is unclear. And it’s a time suck.
What would help you as a developer when modifying and fixing existing code? It’s easy to complain about code written by someone else, but what about the code you write yourself? What do you include so you can help the maintenance programmers who’ll come after you?
The simple answer is that you have to document your code?so your logic is clear, easy to understand, and easy to change.
This article will explain how to do that. We’ll explore what software maintenance is. Then we’ll talk about how to document our code so we can help the other developers who’ll be fixing and modifying the code we write. And since we often get to fix and modify our own code, this will be an article about how we can help ourselves, too.