Video nenà dostupné.
OmlouvĂĄme se.
This Is What Clean Code Means Today
VloĆŸit
- Äas pĆidĂĄn 14. 08. 2024
- Discover the secrets to crafting clean, high-quality code in this insightful video! đ Dive into the world of clean code and learn how to write software that is not only efficient but also easily understood and maintained by your team. Master the five key principles that every developer should know:
1ïžâŁ Independent Code: Learn how to write modular, self-contained code that minimizes dependencies, making it more reusable and easier to test. Say goodbye to tangled, messy codebases!
2ïžâŁ Readable Code: Understand the importance of writing code that is easy to read and comprehend. We'll share practical tips and best practices to enhance your code's readability and make collaboration a breeze.
3ïžâŁ Predictable Code: Discover how to create predictable code by following consistent patterns and avoiding surprises. Write code that does what it's supposed to do, making it more reliable and easier to debug.
4ïžâŁ Observable Code: Explore the art of crafting code that is easy to monitor and debug. Learn how to implement logging, error handling, and other techniques to ensure your code is observable and maintainable.
5ïžâŁ Writing the Right Code: Dive into the mindset of solving the right problems with the right code. Avoid over-engineering and premature optimization to create efficient, effective solutions that truly address your project's needs.
Whether you're a seasoned developer or just starting out, this video will help you level up your coding skills and make your software development projects a success. Don't forget to like, comment, and subscribe for more expert programming tips! đđ»
đ¶ââïž FOLLOW ME đ¶ââïž
Join Our Discord - / discord
Twitter - / codyengeltweets
TikTok - / codyengeltalks
Medium - / membership
Subscribe To My Newsletter - www.engel.dev/
đĄGet 20% Off Of Brilliant - brilliant.sjv....
đ„ My CZcams Gear - kit.co/CodyEng...
đ„ My Desk Gear - kit.co/CodyEng...
đ” My Background Audio - www.epidemicso...
*The above links are affiliate links.
đ RESOURCES đ
Clean Code - amzn.to/3n5ZGUX
The Clean Coder - amzn.to/41Wq4iM
Clean Architecture - amzn.to/3HhH23i
Clean Agile - amzn.to/3oH3QTL
Design Patterns (GoF) - amzn.to/3oGviAV
Design Patterns Website - refactoring.gu...
â° TIMESTAMPS â°
0:00 - Clean Code in 2023
1:27 - Writing Independent Code
2:48 - Making Your Code Readable
4:07 - Writing Predictable Code
6:46 - More Observable Code
8:48 - Making Sure It's The Right Code
#CleanCode #SoftwareDevelopment #ProgrammingTips
Great advice, this I believe is good for beginners, and seniors alike.
"i like crashing the application"
This is my camp.
Fail fast, fail hard.
I have 100% confidence in my ability to quickly find and fix bugs with a crash dump.
I'm aware that it doesn't work for all application scenarios, but it will always remain my favorite failure method.
Yep, it works great for finding issues earlier and as long as you can fix the crashes, leads to a more stable application.
Solid advice đđ
Thank you thank you đ
Do you think it is possible to catch all edge cases of an application?
It depends on how new application is, and how large it is. In theory, yes it is. Practically speaking though, it's unlikely that would happen, but doesn't mean we can't get rid of as many of those edge cases as possible.
I was previously a QA and I have always believed it is very hard and also impractical to be 100% bug free (this includes catching all the edge cases). 100% is not a metric one should strive for in my experience as it is also very contextual (it is only 100% at that point in time); however, this can greatly depend on the domain the application is within. The clean code series discusses this a bit I want to say. The higher risk the company, the more effort that should be given to this. Another comment mentioned start ups previously that I commented on about as well. I think TDD can go a decent way to suss out a lot of the edge cases. So yes catching them is possible. Catching also all the corner cases to get to 100% bug free? That is where I start to draw the line a bit.
One should strive to find the highest risk bugs first and work down from there. The highest risk being the areas where your customers spend the most time, or if that part of the app breaks, affects customers the most. As Cody mentioned, the larger the application, the harder this will be. It is possible, but not as practical given what I just mentioned.
So I suppose ask yourself: how does the application domain and size dictate the risk? how does the business' stage dictate the time to deliver? Use that as a gauge to the possibility of the need to find all edge cases, but yes it is possible, just difficult and improbable.
What you said is being told in the mentioned Books as well
Yup, some of the points in this video are also covered in Clean Code. Wouldn't be surprised if other points were covered in some of the other clean books (admittedly haven't read those one, and haven't read Clean Code cover to cover). I don't really recall observability or predictability being major points of Clean Code but could be misremembering.
Yes they are all mentioned in the book and additionally in Clean Coder, which is more about how the programmer/developer/etc presents themself in the day to day.
I have read both and intend to read the others at some point even if they are getting stale. I think the ideas still hold up regardless of Uncle Bob's Twitter nonsense lol and are generic enough most of the time to apply today. However, as with anything you read especially on the internet, never treat it as the law or as something to be revered like a religious text. Take ideas from it that make sense, apply them, see if they work, and iterate on it.
Re startup and ugly code: It's probably worth a comment or mention in a doc block of sorts at a minimum. Even if the dev reading it later, hopefully picks up on it being bad, they can glean some context as to why it was written bad.
Sir how much do you earn as a software engineer? Plz reply. Thanks a lot.
I've posted several videos on this already.
Generally I agree with the message in your video. However, in the end when you discussed "the right code" you said something in lines with (I'm paraphrasing here) "Sometimes the right code is really bad code and then it is good to make sure for yourself and future engineers that this code is not to be reused", well chance are that if it is "the right code" you and future engineers are going to want to reuse it and then the risk is that this bad and ugly code will be reused and might be "immortalized" and create technical debt. I have a background in Scientific computing and worked with physicists on research code and I can tell you that this exact mentality is a huge problem in that field. A physicist might think that "I need to do this particular calculation for my paper, I do not have time to write it well so I do a "quick and dirty" version" and then it turns out that that calculation is the "money shot" of the paper and suddenly you end up with a massive many-fermion code written in all versions of Fortran since Fortran 66 with 4 letter variable names based on Russian and French physics term and nobody truely knows what it does but everyone asserts that it is the most efficient code possible, so no one is willing to refactor it. The "right code" is always ambiguous and depend on what time reference you have. I personally think that code that creates technical debt is never the right code; it might seem to be at the moment, but down the line it will cause problems that is not necessarily trivial to deal with.
That's a fair point and I was probably a little over the top with that part of the explanation, admittedly watching it back while editing I thought "wow that's a little extreme, but it's the only take I did for this so I suppose it'll have to do".
I do think there's something to be said though about writing code that isn't meant to be reused. It's meant to get the job done and then be thrown out, or at the very least it's not meant to be extended any further. A recent example of this for myself is breaking architecture guidelines on a project that was in crunch mode. We usually separate out business logic from our views and make sure it's all tested. Since we're in crunch mode I just included all of the logic in the view because when we go back to write unit tests, at that point we can just do TDD to create the view model from scratch as opposed to working around the bad code I wrote. The view itself will probably remain largely the same, but whoever works on the tests will have the freedom to also create the view model.
...Or that code will last for years and someone will be very upset with me when they check the git-blame.
@@CodyEngelCodes "getting the job done" is an interesting concept I've struggled with at times being a newer developer at a more startup stage company. Couple that fact with the additional one that I come from a QA background, and you can really see where the struggle comes into play. However, overtime I have seen the value in it, given that quality is taken into account as best it can be. Document decisions, and make sure your team knows that you need to rectify this in the near future. I'd prefer documenting it within the code itself, because I feel like tickets tend to get lost or never prioritized, but do what is best for your team.
Agree with the original comment though, depending on the domain, I suppose you have to be careful. The definition of "right code" is not the same for everyone/business. Decisions and tradeoffs must be had in one fashion or another.
Don't let casey miatori hear you say all that, he'll block you.
Oh no đ
Google's furiously... ooo he has a Substack and series about making games!
Again a nice video, although I am not always in agreements, I do love the nuance you added at turnend with âthe right codeâ.
I think uncle Bob is just an evangelist and o say that because he has no S.M.A.R.T objective way to measure âwhat is cleanâ.
He was hired to give a lecture at the bank I freelance at. And I wasnât very impressed. As itâs not very useful what he preached when youâre not in business software or non-heavy frontends. Since he obviously only deals (dealt) with business software it seems. Thatâs trivial to make âunderstandableâ.
Also âreadable and understandableâ is very relative. I tend to have noticed that code complexity is reduced to the lowest common denominator in your team.
Tricks like lists with function pointers to a void long switch cases or if blocks (ugh). Is something uncle Bob finds unreadable but when you explain a n00b what it is and how it works (which I think should be common knowledge), itâs like âoooooh that prevents a lot of extra code! And we can easily test those!â Yup!
Predictable is perfect, when the process and input are predictable. Again with lower level software, interrupts or parallel threads can make predictably very complex. And thereâs a lot of code to handle things in the right order to prevent race conditions. That orchestration code is always rather technical and complex if you donât really know exactly what interrupts and why/when hebt are triggered. Or what threads run and what has priority over others.
This is only where technical documentation comes into play.
And throwing exceptions is really the best way to make code behave unpredictable. I donât like exceptions for that reason. I think Rust and Zig have found the best way of dealing with them with just an Ok or Error enum that you can unwrap. Not catching the rights error and it can bubble all the way to the top and crash or misbehave. But recovering is also comped.
Especially testing that, that always took us the most amount of time, creating the actual twat scenarios where the specified errors (server down, network down, power outage, wrong entry, etc etc etc) were simulated and tested and reported as part of the certification. And I soon learned that exceptions in C++ looked like a vid send but it turned out to be a devil in disguise đ
There was one thing I praise Bob for. And thatâs code comments. People donât read those, the only time you actually read them is when the code isnât immediately clear. And I have to say thatâs the truth.
Commenting code came from the days we wrote assembly (I still do at times), and there it makes sense. But C/C++, C#, Java etc are so highlevel that generally you see with a glance what it is meant to do.
Thanks as always for the thoughtful comment! The Right Code in a way felt like a cop out but I think that's almost a necessary asterisk for almost everything we do. You can extract commonalities and find ways to say "9 times out of 10 this is the way to do this thing" but there will always be at least 1 exception to the rule.
Also avoiding exceptions wherever possible is what I aim for. I like to use them when there is a missing product/business requirement that we just can't recover by showing a "Whoops something went wrong, try again." message. Ideally there would never be a missing requirement or if there was it'd be easy to get an answer for it, but that's not always the case đ
@@CodyEngelCodes yeah the requirements on exceptions are rarely discussed. The only places where they were brought up and thought through were situations where you have certification needs. So in cases of healthcare or trading commodities.
And those exception situations often were the most difficult to write. And causing very complex code paths and sometimes very weird looking code as a result.
This is when I realized that all programming languages are actually very linearly goal oriented. And that not a single language actually has a nice defer, in case of errors that you can just define and it would undo the stack and changes automatically. That would be so lovely!
Zig had an errdefer which is hands but itâs still up to the developer to know what to role back and how to get to a previously consistent state.