Good abstractions are important for the code to be readable. An AbstractEventHandlerManager is probably not a good abstraction.
The original commenter said that their code was “generic with lot of interfaces and polymorphism” - it sounds like they chose abstractions which hindered maintainability and readability.
Is it possible that you just chose the wrong abstractions?
I do, and whether I have a good time depends on whether they have written their code well, of which the book’s suggestions are only one metric.
How do abstractions help with that? Can you tell, from the symptoms, which “level of abstraction” contains the bug? Or do you need to read through all six (or however many) “levels”, across multiple modules and functions, to find the error?
I usually start from the lowest abstraction, where the stack trace points me and don’t need to look at the rest, because my code is written well.
It’s only as incomprehensible as you make it.
If there are 6 subfunctions, that means there’s 6 levels of abstraction (assuming the method extraction was not done blindly), which further suggests that maybe they should actually be part of a different class (or classes). Why would you be interested in 6 levels of abstraction at once?
But we’re arguing hypotheticals here. Of course you can make the method implementations a complete mess, the book cannot guarantee that the person applying the principles used their brain, as well.
I never claimed it’s not important, I’m just saying it’s not relevant here, as there is no context to where this method was put in the code.
As I said, it might be top-level. You have to mutate state somewhere, because that’s what applications ultimately do. You just don’t want state mutations everywhere, because that makes bad code.
Clean code does not prevent writing bad code, it just makes it a bit easier to write good code.
OF COURSE you can follow the principles and still write bad code, because so much more goes into it, including skill.
A giant method with everything laid out, potentially mixing abstractions sounds like a nightmare to me. It leads to cognitive overload.
You’re nitpicking.
As it happens, it’s just an example to illustrate specifically the “extract to method” issues the author had.
Of course, in a real world scenario we want to limit mutating state, so it’s likely this method would return a Commission list, which would then be used by a Use Case class which persists it.
I’m fairly sure the advice about limiting mutating state is also in the book, though.
At the same time, you’re likely going to have a void somewhere, because some use cases are only about mutatimg something (e.g. changing something in the database).
And yet, outdated comments are far, far more common than outdated function names.
Also, if you’re changing a comment which explains the “what”, you should likely change the method name, as well.
It’s important for the client to know what the method does by looking at the name, so why would you duplicate your effort?
You’re talking about assembly in a thread about OOP…
Comments should never be about what is being done. They should only ever be about why it is being done.
If you write your code like suggested in the book, you won’t need to rely on possibly outdated comments to tell you what’s going on.
Any comment about “what is being done” can be replaced with extracting the code in question to a separate, well-named method.
It makes me sad to see people upvote this.
Robert Martin’s “Clean Code” is an incredibly useful book which helps write code that Fits In Your Head, and, so far, is the closest to making your code look like instructions for an AI instead of random incantations directed at an elder being.
The principle that the author of this article argues against seems to be the very principle which helps abstract away the logic which is not necessary to understand the method.
public void calculateCommissions() {
calculateDefaultCommissions();
if(hasExtraCommissions()) {
calculateExtraCommissions();
}
}
Tells me all I need to know about what the method does - it calculates default commissions, and, if there are extra commissions, it calculates those, too. It doesn’t matter if there’s 30 private methods inside the class because I don’t read the whole class top to bottom.
Instead, I may be interested in how exactly the extra commissions are calculated, in which case I will go one level down, to the calculateExtraCommissions() method.
From a decade of experience I can say that applying clean code principles results in code which is easier to work with and more robust.
Edit:
To be clear, I am not condoning the use of global state that is present in some examples in the book, or even speaking of the objective quality of some of the examples. However, the author of the article is throwing a very valuable baby with the bathwater, as the actual advice given in the book is great.
I suppose that is par for the course, though, as the aforementioned author seems to disagree with the usefulness of TDD, claiming it’s not always possible…
I think that would depend on the skill of the developers and the resources they are given.
A lot of us are only ever taught to be code monkeys and those would probably not naturally gravitate towards true agile practices (which most, I would argue, have never actually seen in a real project).
Another problem is a lack of access to domain experts, which is also crucial.
However, my current project doesn’t have any managers, or even business analysts, there’s only the developers and the Product Owner. We have access to some domain experts and we work with them to build the right thing.
It’s going great and the only problems we are facing are a lack of access to the right domain experts sometimes, as well as some mismanagement in the company around things we can’t do ourselves (like the company Sonarqube not working and us not being allowed to host our own due to budget constraints).
In conclusion, I think part of the problem is educating software developers - what true agile is and what the industry best practices are (some mentioned in my previous comment). Then you give them full access to domain experts. Then you let them self-organize. Basically, make sure you have great devs, then follow the 12 Principles of the Agile Manifesto to the letter and you’ve got a recipe for success.
Otherwise, results may vary a bit, as I think many would tend to continue doing the Fake Agile they were taught and continue producing the poor quality, untested code they were taught to produce.
Fair point!
I’m hoping for a 4-day 6-hour work week in my lifetime, but it seems the world isn’t ready for that quite yet, even though I’m 100% convinced productivity would not be impacted in any significant way, at least when it comes to software dev.
A part of it is horrible practices and a work culture which incentivizes them.
Who can be happy when the code doesn’t work half the time, deployments are manual and happen after work hours, and devs are forced to be “on-call”?
Introduce Test-Driven Development, Domain-Driven Design, Continuous Deployment with Feature Flags, Mutation Testing and actual agile practices (as described in the Agile Manifesto, not the pathetic attempt to rebrand waterfall we have in most companies) to the project and see how happiness rises, along with the project’s reliability and maintainability.
Oh, and throw in a 4 day work week, because no one can be mentally productive for that long.
IMO the biggest problem in the industry is that most developers have never seen a project actually following best practices and middle management is invested in making sure it never happens.
First part of the article sounds like what I’d expect.
The second part makes me wonder if this research was sponsored by some company which provides “Prompt Engineering” training.
Joplin itself is AGPL. Unfortunately, Joplin Server is under “JOPLIN SERVER PERSONAL USE LICENSE”.
While I really like Joplin, I’m thinking of making the switch to something fully open source.
Hopefully this will enrage the users enough to go and actually vote against Trump.
I feel like I’d believe it if the headline was about John McAfee.