Let's call a spade a spade. That's all bullshit! Yes, don't be afraid of the word.
If you're a developer, your job is most likely taking problems and solving them using a bunch of classes and/or functions.
What does all of the above mean in this context? Nothing. Even the architecture doesn't mean so much. You pick one and follow it, bam, done.
But you know that you're missing something. That magic thing, that will prevent your code from getting overly complex, your project from becoming an unmaintainable mess.
Ok, so what causes the mess? What causes the complexity? Why do so many projects fall into legacy stage?
- lack of tests
- long classes
- long methods
- bad names
- leaky abstractions
- broken encapsulation
- Should I name this class/function/variable A or B?
- Where should this function go?
- Should I use this or that pattern? Perhaps none?
- Have I covered all cases with my tests?
- Is this piece of code readable?
- Does it fit conceptually?
- Does it represent the domain correctly?
- How may it evolve in the future?
Now, these are real problems. That's what matters. That's what decides if your project will succeed or fail. That's what you should pay most attention to. Don't forget that. Good luck!