Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Building software that is easy to change is the holy grail for software developers, simply because requirements evolve so quickly on most projects. A great way to reason about the changeability of your codebase is to discuss things in terms of connascence.
I've already discussed this topic at length in Practicing Ruby 1.24, so be sure to check that out for details and some practical examples. The basic idea behind connascence is that whenever you have multiple components where a change in one necessitates a change in the others, those components are considered connascent with one another. To make it easier to change things, it is necessary to take code with strong forms of connascence and convert them to weaker forms.
The examples from the article linked above include the following scenarios:
- Making function arguments easier to change by replacing ordinal arguments with either hash-based arguments or an arguments object.
- Making functions more flexible about what kinds of objects they can work with by replacing
respond_to?, or just calling the expected method and rescuing
NoMethodErroron failures (i.e. introducing duck typing).
- Making it easier to change 'magic values' in codebases by introducing well named constants and methods rather than hard coding data.
- Making it easier to change algorithms in code by extracting commonly used methods rather than implementing them in multiple places (i.e. keeping things DRY)
The easier your software is to change, the more likely it is that it you'll be able to maintain it indefinitely rather than reaching a point in which every step forward causes two steps back. While connascence is just one concept related to changeability, it's a good foundation to start from.
Turn the page if you're taking the linear tour, or feel free to jump around via the sidebar.