I recently started working in a codebase that I didn’t write. It’s not the first time I do this, but it is the first time it happens after embarking on my Software Craft journey. As the responsible apprentice that I am, I started going through the code while keeping all my recent learnings in mind. Here’s a list of what I tried to keep in my mind:
- Just because it’s different than how I would’ve done it, doesn’t mean it’s wrong.
- The code only tells part of the story. It can’t convey the entire circumstances behind its creation.
- Keep the white belt on. Even if this code is in your domain of expertise, this specific project is not. Don’t make any assumptions.
- Fight the urge to refactor everything.
That last one was specially useful, because that urge is strong. Very strong.
We are wired to react to unfamiliar things with the desire to make them familiar again. That’s pretty clear, and it happens with everything. We decide on the value of reality by comparing it to what we already know. And in Software Development, those things are the languages we feel confident in, the paradigms we use the most and the patterns we’ve used in the past. So, of course, when I, a Functional driven, mostly Javascript dev see JS code written by someone with a strong Java background, it feels like I should change it.
But I shouldn’t. At least not immediately. But I have a master plan that I’ll set in motion today. I call it:
Baby Steps
Like the TDD constraint, my plan will go slowly, one step at a time. However, I won’t be based around doing just one thing at a time. I intend to keep a couple ideas in mind and use them whenever I am working in any piece of code (or writing something new).
- Boy Scout Rule ➡ Leave things cleaner than you found them. In this case, refactor a bit here and there when I have to interact with any particular piece of code.
- Empathy ➡ If something seems really odd, try to find a reason why it was like that. Try to imagine myself in the shoes of the person who wrote this.
- Fill in Test gaps ➡ If I use something and can’t find a test for it, write one! Preferably before refactoring as well.
Those are the small things I plan to keep in mind when working in that project, but there’s one more thing that’s a bit bigger.
Common Ground
The first thing I plan on doing, is finding some common ground. It’s a small team, just me and a couple friends so compromising on a common set of rules and practices won’t be so hard. But I believe it's absolutely necessary as it sets the tone for the entirety of the project.
It feels good to find opportunities to apply what I’ve learned so far, especially when it comes to behavioural topics and practices like the ones I described above. I will report on how successful my approach is, and what changes I make to it as I go along so think of this as a practical experiment in working with legacy code.