Amanda Sopkin - The Refactoring Balance Beam: When to Make Changes and When to Leave it Alone

"Speaker: Amanda Sopkin
Many developers struggle to find the balance between striving to improve existing code and letting good enough alone by accepting certain shortcomings. As a new developer to a team it can be difficult to understand existing strategies and patterns that are sometimes flat out bad (and often openly acknowledged as such). Often the result of tight deadlines or unclear specifications, even the best developers write code they later look back upon with shudders. So how do we decide when refactoring is worth it? Come learn strategies for refactoring with minimal impact, methods for working with bad code you can’t change, and strategies for knowing the difference between what is fixable and what is better left alone.
Slides can be found at: speakerdeck.co... and github.com/PyC..."

[@bloodgain]

Good overview of refactoring in Python.
I would note that "-er" names are often a code smell for object-oriented abstractions. Common ones are "SomethingManager" and "ServiceProvider" -- and in your examples, "Such-and-such Handler" and "Info Provider". Often, if you just drop the "-er" word, that's the abstraction you really wanted. Note that there are exceptions to the "-er" rule, as sometimes they represent a real thing, such as the "Insurance Provider" in one of your examples. Like you pointed out, a code smell doesn't always mean there's actually a problem with the code.