By Kate Gregory
When we design before coding, we create abstractions: classes, member variables, functions, etc. The designer must understand the domain the program models: business, finance, science, or the rules of a game. Often, we must ask users deep questions about what they do, so the software is more likely to meet their needs. Something similar happens when we design major new functionality for existing applications.
There’s another entire kind of abstraction design that we do not teach explicitly. It happens when refactoring working code. These 5 variables seem to go together; let’s put them in a class. These hundred lines of code seem to be doing a single thing; let’s make them a function. This abstraction work doesn’t draw on a deep knowledge of the business or science – it uses cues within the code itself.
This talk will show you those cues and patterns, and how to make code readable and maintainable when you don’t necessarily know how it works and don’t have a deep understanding of the domain it models. You can recognize these patterns in your own code as you write it, or 20 year old code you’ve never seen before: either way your code will be better with a little more abstraction.
Advertisement
