This blog post has been making the rounds, and I have a bunch of problems with it.
The first issue I have is that the elision of the duplicated code in the examples means that we can’t draw any meaningful conclusions from the code.
If the code was present in totality then we could see *what* is being duplicated as well as see if there are any better refactorings that we could apply.
The second is that the drawn conclusion of eschewing clean code is not the right one.
This blog posts tells the story of choosing the wrong abstraction in order to make the code more DRY, but then concludes that clean code isn’t worth it and is just a “phase”.
This is dangerous thinking, and will cause some people to disregard important texts, such as “Clean Code” by Uncle Bob Martin.
@maxdeviant He's not saying that clean code is a phase, he's saying that obsessing over clean code is a phase. I would tend to agree about that. There's many other things to care about when programming, it's a balancing act.
@maxdeviant I strongly agree about the "maintaining a high quality codebase". But it's been more effective for me to build that into the team culture than having one person obsessed about it. I think that's what was the main point of that blog post. Also, code quality != clean code. Testing, code structure, documentation, team culture and practices also play into code quality. And it's much easier to have high code quality when it's a team effort and not one person gatekeeping.
@maxdeviant I have to say tho, I've seen places where the approach you're mentioning was the only one that worked, which is unfortunate :(
@electret You’re very right about high quality being more than just clean code.
Unfortunately, at my work we have no automated tests, no documentation, poor code structure, a culture of copy/paste coding and quick hacks, and an adherence to a horrendously outdated style guide.
These are all things that I’ve been working incredibly hard to fix over the past six years at the company.
@maxdeviant It's hard work to change these things, and sometimes even if some engineers in a team know what to do, they can't get enough traction to achieve it. Before Christmas I went to a new client that lacked good testing practices and spent most of the week to guide them through it before moving on to anything else. Something that can be a good first step is to set up a basic CI. Building on top of that slowly and getting people into it :) Once you have CI + test, clean code can follow :)
Merveilles is a community project aimed at the establishment of new ways of speaking, seeing and organizing information — A culture that seeks augmentation through the arts of engineering and design. A warm welcome to any like-minded people who feel these ideals resonate with them.