25. One Job!

I like simple rules you can apply everywhere. "One Job!" is one of those.

Every class and every function in your codebase should do one thing. Not "sort of one thing". Not "mostly one thing". Just: One Job! ✅

Every class and function should do one thing! 🧠

If you can't explain a function in one short sentence without using the word "and", it's probably doing too much.

"This function fetches data and validates and formats and writes to the database…" That's not a function anymore, that's a mini framework.

Small, focused functions:

• are easier to read
• are easier to test
• are easier to reuse
• are less likely to break other things when you change them

No "God Classes" 🙅‍♂️

We all know them: that one class that knows everything and does everything.

• It talks to the database
• It handles business logic
• It manages UI state
• It also sends emails

A "God Class" may feel convenient at first ("nice and central"), but eventually it becomes a concrete block around your ankle. Every change is risky, every bugfix is scary.

If a class has more than one responsibility? Split it up! ✂️

Create multiple small classes with a clear name and a clear purpose. Better five small, boring classes than one "smart" monster class.

If a class does more than 1 thing? Split it up!

A few signals that your class is doing too much:

• The name keeps getting vaguer: Manager, Service, Handler, Processor
• You're scrolling forever in the file
• You have a lot of private methods that could easily live on their own
• You need way too many words to explain to a new developer what this class actually does

Slice it along natural boundaries:

• data layer vs. logic
• domain logic vs. UI/transport
• reading vs. writing
• validating vs. processing

Every new class gets one clear responsibility. One Job.

If a file is really long? Split it up! 📦

Overly long files are also a code smell.

If your editor can't show a good overview anymore… If you have to search where a class starts and ends… If you need three full scrolls to go from top to bottom…

Then it's time to cut.

Think in modules:

• group what belongs together
• split what clearly stands on its own
• create index/barrel files if you're worried about too many imports

Better ten small, logical files than one giant "everything" dump.

One Job as a reflex 🔁

Try to build "One Job!" into your daily routine as a reflex:

• Writing a new function? → Can I explain this in one short sentence?
• Reviewing a PR? → Does this class really do only one thing?
• Spot a monster file? → Where can I safely make the first cut?

Every time you make something smaller, clearer, and more focused, your codebase gets a bit healthier.

One Job! That's enough.

Do you recognize this? Are you also working in a codebase with "God Classes" and way too long files? How do you make sure your classes and functions really have just One Job?

🤝 Need help cleaning up your frontend or codebase, setting up better structures, and defining clear coding standards (for people and AI)? Feel free to send me a message.

👉 Follow me for more Developers Tiles of Wisdom.