How do we improve the quality of code produced by our industry? That's what I want to see happen. It's a young industry which is largely trying to figure out how to produce high quality code.
It's fairly effortless to make a computer do something. This is where most engineers sit. They don't have the experience or those with the experience around to know better ways.
It took me almost two decades to finally understand.
Most of the industry writes procedural code. I don't care if you organize it in constructs called "objects". It's still procedural code.
I refer to this as Procedural Object Programming. It's not Object Oriented Programming; it's very procedural.
If you have a 20 line method; it's gonna be pretty procedural. The 100+ line methods can't be described in any polite fashion... they are procedural.
If you're writing procedural code; you're writing the code wrong. Exceptions being those who need to write procedural code; please continue.
If you don't think you're writing procedural code; then you're one of the developers writing procedural object code. You're doing it wrong.
When developers talk about how to write maintainable code; they talk about the principles software development should apply. These principles are the high level objectives we should have in mind while developing software. Write SOLID code and Use Patterns; Emergent Design - but... How? Emergent Design can seem pretty diametric to Use Patterns. Once you dig into the details of the two; clearly they are not.
I think "Use Patterns" is bad advice. You don't "use" patterns; you recognize that a pattern's emerging and CAN (not must) refactor to a known better form of the pattern - IF APPLICABLE. That's a topic for another time.
I've found the style of µObjects to be a process that forces many of the practices into existence.
Having been pounding the keyboard for a bit on this post; I find that there's a lot that can be expanded from the few µObjects guides I have.
These really come from the Single Responsibility Principle.
Classes should do a single thing.
This is a very strict rule for µObjects; it's the whole principle behind the practice. It's a narrow focus than I've understood from any other Object Oriented Programming guide or style.
Methods should be a single line.
Clearly not all methods can meet this; but if they do A SINGLE THING; they should come pretty close. A µObject shouldn't have a lot of methods; they're doing one thing, it should have very few public methods (defined in an interface). My bigger classes have a 7ish single line private methods. These are all doing a piece of some transformation.
The public method; it calls maybe two, maybe 3, of these methods. They only exist as this large of private methods because I haven't found enough to know how to tease an object out successfully.
The µObject itself is still doing one thing; in these cases it's extracting data from a JsonObject. Not parsing the json; that's another class - but utilizing the parsed JSON into a specific form.
What I've found by having other developers work and apply the µObject style is that it brings up questions where other practices can be discussed as solutions; and the why of these solutions. By using µObjects, we're having discussions about the practices we can employ to produce highly maintainable code. We're not taking a dictate from a book, which is a one way communication. We must now have conversations.
Conversations about why we don't use nulls; how switch/else are evil. That if's are only guard clauses (and the most frequent violation of the single line).
The practice of µObjects forces developers to have discussions about how to develop software. We can't learn in isolation; yet that's how almost all developers work - Pair programming solves isolation; but without a model to drive the conversation; we'll just pair on producing low quality code.
µObjects is a model of software development to drive conversations. We have a very clear approach of what the final code should look like.
Classes do a single thing. Not a single job (as more traditional OOP is) but a single thing.
Methods are a single line If it's a single line; it's probably doing a single thing.
If you have these as the guiding principles for the finished code; you'll have a lot of discussions about how to accomplish that.
There's a few other key rules that need to be followed in µObjects to do them correctly; but utilizing Test Driven Development will force a enough of them into existence that the resulting code will be good enough OOP to increase maintainability.
Follow these two principles as strictly as you can; and watch the discussions abound. Don't focus on writing code; focus on writing good code.