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!
[deleted]
Goodbye, Clean Code (2020)
161–170 of 224 posts
Re: Goodbye, Clean Code (2020)
#162Earlier quoted context omitted.
You realise that everyone pushing changes to main several times a day is the definition of CI? and it's pretty much impossible to do with code review as a gate for pushing to main. Interesting how CI has become semantically diffused to mean literally the opposite of CI: tooling and processes that delay integration and make it easier to work in isolation. https://wiki.c2.com/?ContinuousIntegration " The most granular…
CI is more than that, at least in my understanding of the term. You have to have some sort of automated testing before doing the merge. We were doing the same shit (all pushing to the same branch) and it broke constantly before we introduced some tests and merges only after a successful test run on a separate CI server. Just pushing everything into the main branch without any checks is no CI, even if it technically c…
That's `automated CI` which is now or less interchanged with just `CI`, however at face value there is no requirement that all CI be automated, it is just usually better to do so.
Re: Goodbye, Clean Code (2020)
#163A good engineer uses Object Orientated Design/Design Patterns/Inversion of Control/Functional Types/Algebraic Types/Clean Code/New Buzzword Coming Off The Tech Press Soon. All of these ideas have good value but the tech industry seems to lack moderation.
The buzzwords are like catnip to most developers. They go absolutely crazy. Their fevered madness, detailed on medium.com. Their codebase, transformed. Conference tickets, bought. Once they've weaned themselves off one then another buzzword will come along and books will be bought and blog posts will be written and code will be refactored and job specs will be altered.
I live by "when you have a hammer, everything looks like a nail" now and try to stay wary of this year's transformative codebase panacea.
Re: Goodbye, Clean Code (2020)
#164Earlier quoted context omitted.
Ah, thank you. I never managed to put it quite clearly as that. But thinking back and considering the intuition I built around when an abstraction makes sense and when it's just going to be unhelpful cruft, boils down to this. Abstracting over behavior gets messy very quickly. Special cases will probably arise on the next requirement change. Unless they're already there and you missed the subtle interaction. And if y…
The abstraction is the standard case and should invite custom behaviour to be added dynamically. This extra behaviour should be added by the caller / user of the abstraction. Especially in a CRUD situation, every custom procedure will probably have a few basic steps that stay the same. All you usually need is a pre and a post hook.
See, but that's exactly what I'm saying does not work.
It's tempting to think that for e.g. a CRUD situation, pre- and post-hooks are all you need.
And it may be that way at the beginning, although hardly so, except for the simplest applications. But very soon, you start to run into things like (not an exhaustive list, but all are things I actually encountered while trying to do precisely what you're saying, many years ago):
* Transactions, when multiple things have to happen atomically. Your pre-hook must start a transaction, and your post-hook must commit it. But what if there's an error somewhere? Python and JS don't have RAII, so you need some kind of catch block to abort the transaction. Where does that happen?
* Tricky validation, e.g. needing to do queries against the data store to check the request is well-formed. So if you're using an event-based language, your pre-hook also needs to be asynchronous.
* Data transformations (what the user sends will hardly be what needs to end up in your data store), so your pre-hook needs to be able to return a new object.
* Tracing across service calls, so you need to pass some kind of request ID as well to your hooks.
* An "update" request needs to return something (e.g. an ID) to avoid another round trip. But sometimes it needs to return more stuff, so your post hook must be able to return data. Oh, but your ORM or DB usually returns the created object, so you'd like to use that instead of re-fetching in your post-hook, so now your post-hook must accept that as well.
These just keep coming up. The first three in particular are usually guaranteed to happen before the first release of the product, since requirements always change. Soon you have an unmaintainable monstrosity. A little copy-paste is tame in comparison.
Re: Goodbye, Clean Code (2020)
#165I'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..
It was reviewed the next day by his boss. How is pushing to master not a form of CI?
I was going to downvote you, but then you made me think - everyone pushing to a shared branch is the most continuous form of continuous integration I suppose.
I worked this way for years before we moved into full branched code review. I would never go back however.
That said, you should still have at least some review and automated testing before your code gets in everyone else's way.
Re: Goodbye, Clean Code (2020)
#166Earlier quoted context omitted.
You mailed the original developer, he didn't answer. And you were fired for doing your job right. What you must conclude is that they don't care about quality but about ego. They have a philosophy that don't favor quality. You should be glad they fired you.
I wasn't fired, just... the threat was raised. That original dev left soon after (in no way related to that - he'd been looking around for a while from what I heard). It was a strange situation because in the group of... 8 or 9 of us, I was the last one in, and got along OK with everyone, except him.
The point your parent post was making was that regardless of whether or not you actually got fired doesn't actually matter. The signal you should be paying attention to (which you are surely aware of, since you say this episode still bothers you) is that the environment was a toxic one so if they did fire you they would have been doing you a favor. At least from a silver linings point of view.
Re: Goodbye, Clean Code (2020)
#167I realize this a click-bait title, and the article plus the discussion is more nuanced (this is why I love HN!). But I think less experienced developers might take this as a license to just write pages and pages of spaghetti, then point to this article and say "Duplication is good!". Duplication is not good, it is the enemy of maintainability. However, sometimes under very complex software requirements (which hopefully aren't needlessly complex), there is no good abstraction and attempting to create one will just make your code confusing and inefficient. However, there are many things that you can easily abstract safely and practice doing this makes a developer better. If you are a junior developer I highly recommend taking this article with a huge grain of salt or outright ignoring it. Both an ill-fitting abstraction and duplication are going to lead to messy code, messy code is a fact of life, but only one of these practices is going to lead to good habits and help you develop as a software engineer (hint: it isn't duplicating your way out of problems).
Re: Goodbye, Clean Code (2020)
#168This blog is essentially a journey of self discovery arriving at https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction "duplication is far cheaper than the wrong abstraction."
[deleted]
Re: Goodbye, Clean Code (2020)
#169"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…
> While undeniably true, this feels completely orthogonal to the question of clean code. I think this mentality and the Clean Code Movement (with capital Cs) actually have a lot in common. Much of the Clean Code movement is occupied with the idea that there is one, single, right way of doing things. Anyone who does things differently is doing things the wrong way. There is a subset of programmers who are attracted to…
> Much of the Clean Code movement is occupied with the idea that there is one, single, right way of doing things
Well if this is the case then they certainly didn't get it from the Clean Code book itself. The books very explicitly makes the point that there's no one right way and that the guidelines in the book won't apply to every situation.
Re: Goodbye, Clean Code (2020)
#170Earlier quoted context omitted.
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.
> I would fire you Ha ha ha. That's not how it works with me.
Then I guess I would fire you :-)