I have to be honest, by seeing this title I first thought you were talking about the clean code architecture by Uncle Bob lol.
Regardless, you are quite on point through this whole post. For example, I have recently been working on a project which tries its best to do abstraction. But through trying to make sure the project has "Clean Code" it has been over abstracted through and through such that you cannot have people comfortably settle into the project or even comfortably make changes.
Clean code is not about abstraction and he who promoted that in your poor codebase should indeed read uncle bobs book(s). Its about maintainability and leveling your codes intent with the amount of abstraction you possibly introduce. People are so black and whlte its scary.
The red green refactor is a good tool in clean code. Make it work, then make it read better. Then when someone else makes changes, they do the same. Code should be possible to be used in discussion, hencr hiding an ugly for loop in a function makes sense (get filtered posts function speaks better than the for loop on line 13 where we filter posts, for an example)
Other abstractions like factories, visitors and observer, these are terms that lets people talk about code like you and me can talk about cars, drivers and mechanics. We all know the meaning without having to describe how each one works in the world esch time it is mentioned.
These are, imo, the main intents of clean code. Using these methods any senior dev can use any language features as much as he wants to leverage it for performance. If he actually is good, that is ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have to be honest, by seeing this title I first thought you were talking about the clean code architecture by Uncle Bob lol.
Regardless, you are quite on point through this whole post. For example, I have recently been working on a project which tries its best to do abstraction. But through trying to make sure the project has "Clean Code" it has been over abstracted through and through such that you cannot have people comfortably settle into the project or even comfortably make changes.
Clean code is not about abstraction and he who promoted that in your poor codebase should indeed read uncle bobs book(s). Its about maintainability and leveling your codes intent with the amount of abstraction you possibly introduce. People are so black and whlte its scary.
The red green refactor is a good tool in clean code. Make it work, then make it read better. Then when someone else makes changes, they do the same. Code should be possible to be used in discussion, hencr hiding an ugly for loop in a function makes sense (get filtered posts function speaks better than the for loop on line 13 where we filter posts, for an example)
Other abstractions like factories, visitors and observer, these are terms that lets people talk about code like you and me can talk about cars, drivers and mechanics. We all know the meaning without having to describe how each one works in the world esch time it is mentioned.
These are, imo, the main intents of clean code. Using these methods any senior dev can use any language features as much as he wants to leverage it for performance. If he actually is good, that is ;)