The Hooker Design Pattern

Once I was reviewing a patch of a teammate, everything was more or less well, except for a particular ugly, long, misterious class.

-"Oh, yep. Da' Hooker".
-"What!?"
-Yeah, the hooker. That's the nickname we gave it in team. Is the class that all of us touched at some point.

Hooker classes are interesting case studies. For psychologists. They produce fear, respect, depression, and from time to time, catastrophes.

But what is a HC? Well, basically is an ubber class (hundreds or even thousands of LOC) where lots, lots of things happen. A HC tend to centralize multiple responsabilities: transformations, business logic, utility methods, handlers, magic mistery methods. Whatever. Even worst. HC usually does not have decent tests, so trying to refactorize it is, at least, dangerous.

...so? Any ideas?

Let me summarize some points:

1. DONT TRY TO BE A HERO. Do not try to fix it "once and for all". Its dangerous. And your good intentions may end up with your boss kicking your ass.

2. Is HC plenty of tests? If thats the case, you are a lucky one. If not, analyze who's using HC. Try of identify the responsabilities. And finally start creating tests for the HC.

3. Only once you have a good amount of tests, start refactoring it.

4. Ask for multiple code reviews. Specially from devs that had a touch and go with it.

5. Let your manager, technical leader, product owner, etc. know what you want to do. Ask for permission. Ask for a user story to handle "technical debt".Avoid shadow development. Is risky and people will blame on you if somehing goes wrong.