91–100 of 224 posts
There was a discussion a couple of years ago on this article with 500+ comments, for those interested: https://news.ycombinator.com/item?id=22022466
No thanks, we're doing it all over again here. This time will be better!
Acest articol este interesant
"first you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Kent Beck
Yes, Uncle Bob :)
Math code also seems way more amenable to being consumed as passed-in functions that are consumed as a black box, then those things call the math functions and get the result, and really don't care how the math was done. But it's then good to signal (debug logging) what math function was passed in and why. Here, you can have OvalSpecialCaseMathFunction() along side the regular ones too.
I'm probably falling into the same pit as the author here, but it doesn't seem like duplicating every "kind" of code has the same cost/benefit.
0. Existing code is probably working fine, and making changes (for any reason) risks adding a bug. Worse, reviewing code with a bunch of reformatting is tedious and the reviewer may assume you’ve only done reformatting and not notice the accidentally-changed behavior either.
1. You have to merge, a lot. And “fixes” that do little except reformat or redo are a pain to deal with when all you really care about is getting functionality in. This multiplies across branches and team members, and might require multiple manual merges.
2. There is a decent chance the code you’re not pleased with will be ripped out entirely as part of some bigger change, at which point all effort to fix unclean parts is moot.
3. Far more people than you are familiar with how it used to be, warts and all. The “cleaned” version now looks alien to everyone else and might slow them down.
That said, there is a time to clean things up; it just has to be at a well-defined point in the project. It involves a combination of things from the article (e.g. talk to the team) and the above (e.g. do it when many features are merged in and there are few branches to deal with).
Uncle Bob fooled many developers to join his sect. I am much happier since I've discovered that there's not only "one true path" and OOP, SOLID and Clean Code are not the means to everything in software.
This post is not related to Uncle Bob's book, which is not even mentioned. The term "clean" here is subjectively interpreted by the writer of the post.
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…
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.
When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. I don't think assuming people who disagree with you lack confidence and are "compensating" is an effective way to reach an audience. Rewriting your teammate’s code There should be no such thing as "your teammates code", there is only your team's code. If the changes were…
You should 100% talk to the original author before rewriting though. Not doing so communicates that you think you know better than them, so much better than them that you don't even need to talk to them to understand why they wrote it the way they did, and the tradeoffs. This is very arrogant and would most likely bother the original developer, which is bad for team dynamics.
I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..