51–60 of 224 posts
"Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Co…
Earlier quoted context omitted.
Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.
The student said to the teacher: "This fence is in the way and obstructing the flow, it should be removed" The teacher said to the student: "If you can tell my why someone made the fence in the first place, I will allow you to remove it." Note that this has nothing to do with "code ownership". If you worked for me and randomly changed code that you did not like, I would fire you.
Ha ha ha. That's not how it works with me.
I've been a bit of an apologist.
I thought maybe people just took clean code a bit too far, that people were being too dogmatic about what was basically sound advice. Then I found Uncle Bob's old website the other night and I can no longer deny he's had a finger in this.
> _Anything not testable is useless._
> Here's the thing. If you can't test it, you don't know that it works. If you don't know that it works, then it's useless. If you have a requirement and cannot prove that you have met it, then it is not a requirement.
- http://www.butunclebob.com/ArticleS.UncleBob.AgilePeopleStil...
If these are the vibes you're putting out, your followers are going to be zealots. They're going to be frothing at the mouth whenever someone proposes alternative paradigms.
Earlier quoted context omitted.
Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.
The other developer usually has reasons why they designed it that way. If you just rewrite other people's code, it makes it seem like you think there is One True Way to writing code and that you're smarter than them. I'd ask first if they agree with a certain improvement. It shows I value them as an engineer and they might bring up critical information that I'm missing, making my "improvement" actually worse. It does…
This article really buries the most important lesson about refactoring: > I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to e…
"My code traded the ability to change requirements for reduced duplication, and it was not a good trade. For example, we later needed many special cases and behaviors for different handles on different shapes."
The reason for my choice of this point is that provides a direct, technical counter to one of the simplistic technical rules on which the Clean Code movement is founded, and so might make a impression on someone who has, heretofore, regarded the case made by Clean Code proponents as irrefutable.
That's also why I say "in this particular context", as in the broader scope of software development practices generally, the interpersonal dynamics of the organization are almost always more important than coding style.
This article really buries the most important lesson about refactoring: > I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to e…
Probably not the best time to refactor someone else's code that currently works.
The famous book about Clean Code was a big Oxymoron, because the examples in it pages was in Java.
"first you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Kent Beck
Premature abstraction is the root of all evil.