CHAPTER 2 Writing Maintainable, Future-Friendly Code
This tends to happen because writing code is more fun than planning
to write code. Most of us are so anxious to get coding that we don’t stop
to think about what we are doing and how it might be used in the future.
What if you need to make changes? What if you didn’t anticipate the addi-
tional features that would be required? What if the project ends up going
in a different direction? Can your code adapt?
When we write code to implement features, we may not think much
about the future. We have deadlines to meet and so we write enough code
to successfully meet that deadline. However, someone is going to have to
maintain that code. That someone might be you next month or it might be
someone else next year, but someone eventually will need to maintain that
code. On a large project with many developers, the problem is magnified.
How can everyone work in the same codebase in such a way that making
changes in the future are easy? That’s what this chapter is about.What’s that Smell?
We will all have to work with someone else’s code at some point. Not all
code written by others is bad, even though our natural inclination is to
think so. How can you tell that the code you’re dealing with is a problem?
Here are a few signs:- Missing or incomplete documentation: there’s some part of the
code for which there isn’t a good reference to understand why it
exists and what it does. - Missing or incomplete tests: you can’t be sure that a change you’ve
made hasn’t broken expected behavior. - Fear of change: you genuinely feel fear when touching the code
because you’re not sure what the end result will be. - Fragile code: changing one seemingly isolated piece of code has
ripple effects throughout the software that are hard to predict.