Clean Code Sucks?
Vložit
- čas přidán 22. 05. 2024
- Prime's tweet: ThePrimeagen/stat...
Let's answer the burning question: Why are thousands of people agreeing that clean code sucks? Does clean code suck? Should we invest time in trying to implement clean code within our systems?
Connect with me on 'em socials:
Twitter: / amantinband
LinkedIn: / amantinband
GitHub: github.com/amantinband - Věda a technologie
Thanks for the quality videos Amichai, I have learned a ton from your videos! I would love to see a video or series about logging, potentially in the context of clean architecture, as it is one of the most important aspects of programming and there is a lot of controversy around it
I neeeeeed this too!!!! PLZ
What actually sucks is tech debt because we didn't have time to "overengineer it" in the first place.
I agree, although it is a fine line between laying a good foundation and spending too long overengineering a POC that may not go anywhere if not delivered on time.
@@amantinband There is the danger yet of a highly engineered codebase that satisfies possibilities that turn out never to be needed, and simultaneously fails in an aspect you forgot to account for. All that structure can be a burden.
High performance requirements is usually the argument used against clean code - if you can get a significant performance boost at the expense of readability, maintanability or extendability. But in my opinion, it should only apply to niche industries like tripleA game develelopment, ultra high frequency trading, maybe spacial, ie. not many developpers
I agree with that as standard readable code is preferred over unreadable slightly better performing code, but instead of limiting high performance code to specific areas, I think the limit is time. When you have enough time you could create a high-performance code, after ensuring it runs perfect with testing, create a readable abstraction over it and reap the benefits of both.
But yes, if you can just choose one, most of times better readability is preferable.
@@dusrdev lets face it "Fast inverse square root" is not a clean code trick and some very simple blur image treatment algorithm I used to implement in the early 2000 to be able to implement // are probably still used in low level graphic card architecture
The moment you have to do anything a little bit more complicated than "getUserById(x)", all that "clean code" goes straight into the toilet. If you're doing anything with a lot of concurrent processes and state changes, you're just hamstringing yourself by tring to make it "cleaner" by writing more lines, creating more classes and random design patterns
This is the point they dont understand, yes abstractions are costly!! However, they make life way way easier down the line. Code is for people to read, and then for machines to run!
Hi Amichai, thanks for the video it was a great watch! One of the reasons I have chosen 'Clean Architecture' (and other things like DDD, CQRS) is because I assumed that it/they are somewhat defacto standards and this would make onboarding of new developers easier. Would you say that my assumption is flawed in this regard? Thanks!
1:48
Good point about the confusion that people make about clean code against:
- Clean Architecture,
- Command Query Separation,
- Command Query Reasonability Segregation
- Domain Driven Design
- Railway oriented programing
@amantinband, thank you for this instructive video ! Regarding problem space and solution space, it's sometimes not so easy to find the right balance during implementation phase. For example, I like to use CQRS + clean architecture + DDD patterns because I see the scalability of solution and give to other developers a way to add features. But sometimes I feel like I overengineer the solution :)
I agree and think sometimes it is over-engineering and not necessarily worth the effort & ceremony. Other times, it's crucial for the development experience in the long run
I guess the most important is to first understand what is happening and see if we're even able to solve the problem itself on a simple and intuitive manner you can always refactor on a later stage, often too much abstraction and architecture planning is so confusing, specially for us that are still learning and have to try to fit our logic and reasoning inside a framework built by others.
Are you considering making a series on Clean Code Architecture for WPF Applications ?
Hey, enjoy your videos, just a little feedback about the audio.
The mic you are using should be spoken to in the front and not from the side. You can angle it at the side of your mouth to avoid plosives. You'll get better vocal clarity and less room noise.
I'd also advise normalizing the audio levels to -16LUFs. There are various Youlean Loudness Meter is a popular one, though Adobe has a tool which will do it for you. This helps the audio levels be more consistent with other levels, but also allows people to hear your audio in noisy environments where they have to max the volume. Another thing it prevents is the case of someone having to turn their volume all the way up for your video, and then when going to another video being deafened. As a good example, compare the audio of this against the latest Nick Chapsas video.
Wow Nate, thanks for taking the time and commenting! I’ll apply your suggestions for the next video.
I replaced the MV7’s pop filter with the SM7B’s which really helped with the plosives, but it’s still not great so I hope the mic placement will help 🙏🏼
How would you rate the audio overall? Anything else I can improve?
@@amantinband Overall pretty good, just those two minor items.
Below are two youtube video titles that give some pretty good details about LUFS mic placement.
Volume vs Loudness - LUFS & LKFS for Measuring Loudness for Video
Speaking Off Axis Into Mics, The Real Deal - Sound Speeds
I'll check them out. Thanks again, Nate!
Instead of normalizing, I would suggest applying a slight (3-5:1 ratio) compression, with a threshold so the attenuation is around 6-8dB. Plus you could add a high pass filter (you don't need anything below 100Hz), and a slight boost around 4-5kHz. HPF should be applied before the compression.
amichai your channel is a golden tressure. i have learned a lot since i subscribed to your channel. may i know if you will upload the live or not?
Do you think that in the future you will start making videos on other programming languages too?
Such as DDD, but in GoLang, or TS or maybe Rust ?
Hi @Amichai Mantinband , sorry to be off topic, is it possible to get a NET MAUI tutorial
Is there a specific topic you’d like me to cover?
The future is SUBJECT-ORIENTED PROGRAMMING. No OOP. No classes.
It's good that you've put up a video and explained it the right way. Unfortunately seems as Prime has gained a lot of popularity in recent times and whether as a joke or honest belief, he says some pretty dumb things that many of his followers choose to believe blindly just because he said them.
The tweet is great clickbait. To be fair, i agree with a lot of his thoughts here: czcams.com/video/IqHaGd9J42s/video.html
When I saw this video title, what I had in mind was the kind of thing in that Prime youtube video. (I had never heard of him until today) and I think that summarizes a lot of the criticism of clean code. While the values of Uncle Bob laid out in the book are generally good advice, like all things it's easy to get too dogmatic about them and over do it. I think I really agree with that Prime video, despite really following Uncle Bob early in my career.
Context is king.
I wish I could use hakai right now.
This is the whole point of TDD and ATDD perhaps most of us in the industry lost. The fact that you have to refactor your test and code after your correct code passes the failing test forces you to use the most simplest (and never the simpler) abstraction necessary. So definitely if you do TDD after upfront design of your Domain, you are surely not going to setup more complex and over-abstracted code. So no your TODO app won't be loaded with abstractions thanks to those tests.
Hi Amichai, thank you very much for your videos. Did you think about your own telegram channel? I think it would be interesting
I do think that when people say something like "Clean Code sucks" they mean the things Uncle Bob put in his book. Most of his rules are unworkable and actively make the code worse and he doesn't even use his own rules in his code examples.
Examples in the book are granular atomic and over abstracted but ideas and statements are good. In most cases you will just follow Clean Architecture + DDD and be fine. You don't need atomic code structure and call func func func to get field. Gamedev rely more on programming methodologies and hacks. You don't want to write clean code from Uncle Bob's book. You want to define modules/entities/components responsibilities and hack your way through to optimize ms for framerate and parallelize things.
I agree. I think the solution should be tailored to the problem.
This is precisely the reason why AAA games have so many bugs and need hours of manual testing. Good design would have saved them, but those people are more interested using chainsaws without proper handles and safety googles just so they can squeeze out 5 more CPU cycles in a 7 year old CISC processor.
@@swagatochatterjee7104 Ummm. Sorry, but it is oranges and apples. AAA games have bugs because boss needs to launch new title every 3 years. But feature scope is way too big for that timeframe. It is not business app where main goal is to calculate wallet balance for millions of people and the cost of error is too high with simple + - operation. It is software that is dealing with all hardware up to game objects and eating not so much resources sometimes in comparison to enterprise servers. Deterministic networking, sound and modulation, skeletal and static meshes, lightning, asset loading and preparations, animations, physics, developer tools, scripting systems, build system for multi-platform and this is only game engines, not games. And in most cases you will need to go through high level abstractions to low and back. Games are super complex software in terms of underlying systems. And if you done something wrong it won't even start. And it is synced to frame delta (well game and render thread at least). And it must be done in 16 milliseconds maximum because it will look way too janky on new 144hz monitor. As you can see a lot of foot guns here. Clean code will be harmful here. Language idioms and paradigms and most of unused patterns of enterprise software (say no to singletons, di, UoW and say yes to flyweight, fsm and pda) will be enough in terms of single abstraction. Then you are stepping into cross module interaction and this is another long story. And yeah, everything in 16 ms on both threads. 😁
Yes
there's an implicit assumption being made that CleanCode makes your code more readable and maintable... well it doesn't, it just forces you to jump like a monkey down a rabbit hole every time you need to understand how a piece of functionality works. There's a reason if CleanCode is loved by junior devs and middle managers: they don't know any better. All the greatest names in IT don't write CleanCode think about that
Prime was talking about the book, right?
Yeah, the tweet was in the context of a blog post talking about the book
No he is talking about clean code overall and excessive inheritance. He makes videos every week talking against it.
He does come from using languages such as Go, Node, and Rust where OOP is implemented lightly. Also doesn’t help his job is from Silicon Valley where “enterprise” is stigmatized lol
I think clean code is great thing, but you shouldn't make it a religion. If there is an option - make code as clean as possible, or make it less clean, and significantly improve performance - you should go with the second one.
I write C code. And don't give a damn about hipster "Clean Code Cult".
"Clean architecture" I still very dumb, how design programming languages that allow you to get away with as many optimizations as you, but still allows for the code to remain maintainable, & also teaching people to be able to read, & comprehend optimized code in the first place, instead of teaching them, this bloated, bug written, slow as molasses corporate nonsense, that is highly subjective anyway.
No, "clean architecture" is not good at all.