Clean Code: Be The Hero - Ben Dechrai - NDC Oslo 2023
HTML-код
- Опубликовано: 6 июл 2023
- As developers, we are often under deadlines to get features and bug fixes out the door. We all know the story - we have to release, and time is pressing.
We've all been there. We've skipped a test, or forgotten to update some comments in the code to reflect the changes. Of course we know we shouldn't, and we always vow to come back later and clean it up. Sometimes we even keep our promises!
And then someone talks to you about clean code, and you think "I don't need another thing to slow me down - it works, I have other things to worry about, just let me code, okay?" Or maybe the concept of clean code is new to you and you want to know more.
In this session, we'll go through some of the core principles and advantages of a clean code philosophy, and delve into some code samples to see how this works in real life. Pro tip: clean code could actually allow you to be a lazier developer and be the hero in your team.
Check out our new channel:
NDC Clips:
@ndcclips
Check out more of our featured speakers and talks at
ndcconferences.com/
ndcoslo.com/ 
Наука
The sheet amount of excellent, high quality, interesting and newsworthy talks coming from this one single event is amazing. I should visit NDC sometime 😅
Agreed. Wonderful content, and a privilege to be able to view it!
I'm not sure how breaking one slightly ugly block of code out into many separate functions is supposed to increase readability and/or maintainability.
And what's more, there's a performance penalty to every piece of abstraction. Depending on your context, that may not be acceptable. "Clean Code" certainly sounds good, but does it actually deliver on its promises?
There's been a lot of criticism of late, from many devs that are much more skilled than I... but I figure if I have already noticed "cracks" in this supposed "Clean Code" concept, then they should be obvious to a great many more people.
The number one benefit I have experienced from clean(ish) code is testability. Breaking a large complex block into smaller simpler blocks with fewer inputs makes it easier to write unit tests covering most execution paths and edge cases; and consistency makes it easier to write those tests.
I have been saved numerous times with a good coverage of tests. Plus, well written tests provide truthful documentation what we can expect the code to do.
Wholly support clean code initiatives. It's a big deal when working on large enterprise integrated solutions.
When it comes to nested code, you can Always re-factor it to make the cyclomatic complexity less than 7 +/- 2 (how many things fit in your head). One potential problem with this is having too many helper functions.
If there is low amounts of repetition in your nested code, you will be forced to have many helper functions to reduce the cyclomatic complexity, however if there is alot of code repetition, you can write higher order functions to simplify things.
The problem with the HOF approach is that you will quickly run into code like this:
f(g(a(b(c(...(x))))))
The solution is the pipe operator to denest it.
x
|> ...
|> c
|> b
|> a
|> g
|> f
I like how he's talking about casing consistency and yet I'm sure he mentioned he'd worked in PHP at the start of the talk.
21:00 "average = sum / 3" ???
22:44 "what getFullName() returns, if FirstName is Nothing"?
"average = sum / 3" : that's the purpose of good naming :) you spotted a bug just by reading the code, because you know that a method called "CalculateAverage" should return the average of two numbers.
"what getFullName() returns, if FirstName is Nothing" : probably an exception, but the point was about consistent naming, not preventing errors.
@@waltergaldarian7675 "you spotted a bug just by reading the code", which I would also have done if the entire function body would have been "return (x + y) / 3". Naming the function according to what it does is surely meaningful, the rest just wastes my time when reading code, meaning I can read less code within the same time and that makes me less productive.
30:10 there is another bug in my opinion. You are checking for not undefined but not for not null. This can be accomplished with a normal equality check for null.
Have you ever heard about trousers? No pun intended.
Congratulations on not making a pun 🎉
I’m currently working in the field of healthcare insurance and billing, and unfortunately it’s horrifically complex and byzantine just by its nature. This fact has manifested in a codebase that is, I would say, MUCH MORE complex, even out of proportion to how challenging one might expect such a codebase to be. Over time, inherent complexity combined with a very dismissive attitude towards code quality and also generally unclear requirements has produced a codebase that’s very hard to work with, very slow to work on, and also VERY stressful to the developers stuck working on it, in large part because the company has committed to bolting a scaled agile process onto a legacy codebase that’s frankly incompatible with that approach. I’d argue that there’s no way that a developer can reliably estimate work in a codebase that’s not so much poorly designed as NOT designed, and yet, business folks are deeply invested in the idea that work is predictable and deadlines are hard.
Additionally, it’s stunningly difficult to dig out of the pit, because the worse the code is, the more difficult it becomes not only to determine what the code is doing, but the more difficult it becomes to determine whether any specific line of code is, it self, an intentional representation of correct behavior or just a bug. Re-architecting out of a hole like that becomes an intractable problem of deciding whether to retain behavior that could be entirely incorrect; the users may rely on it for some reason that’s not apparent to developers or to product owners. Ignoring what might seem like unnecessary edge cases might in fact be protecting against serious regulatory risks.
Realistically, companies that are dug deeply into a tech debt hole are more likely to get out of that hole by going out of business than anything else. Due to internal politics, most companies will never commit to the LARGE lift needed to wrangle code that’s working, and if anything, they commit only to band-aids that make the code even worse. For better or worse, it just leaves an opportunity for newcomers to the market to implement something from scratch that’s a much less terrible user experience than the buggy, slow, obsolete state of work of entrenched companies that have given up on effective software engineering.
I've been in a company like that before.
Sounds like you need a new job!
@@igelineau You’re absolutely right. I’m a little hesitant to do it right now because the job market for devs isn’t in a great spot, but I definitely feel this job encroaching negatively on my mental health. I’ve started dreaming longingly about being a plumber or something.
20:50 Yeah, the function name tells you now what it does. But if the two numbers would be named x and y and the result still result, I would also know it calculate the average by the function name and that the result thus is the average. Renaming those three variables added nothing to the story, but it means more typing when writing the function and, more important, way more reading when reading it. firstNumber and secondNumber are completely stupid names and the correct way to write that function would have been "return (x + y) / 2"
What many people also don't consider is, that people with ADHD and/or reading and writing difficulty, have more and more Problems with reading code. I think naming the function so you know what it does is important and i do it myself. But naming the number, made it imposible to understand the code quickly and see it all at once. Which i was able to do one the first example.
Nice skirt?
Yeah, it looks cool.
Looks like a utility kilt
@@nickr753 Sure is 😁
You're absolutely correct ❤
Here is how I would simplify the process loan application code using maybe from a functional library:
const { Maybe, fromNullable } = require('folktale/maybe');
const calculateLoanPercentage = (normal, maximum, discount = 1) => {
return Math.round((normal / maximum) * 1000 * discount) / 100;
};
const fetchUser = async (uid, URL) => {
const response = await fetch(URL, { method: "POST", body: uid });
return response.json();
};
const handleCustomerType = async (application, URL, discount = 1) => {
const user = await fetchUser(application.uid, URL);
return application !== undefined
? calculateLoanPercentage(application.normal, application.maximum, discount)
: Maybe.None();
};
const processLoanApplication = async (loanApplication, response, URL, discount) => {
const maybeLoanApplication = fromNullable(loanApplication);
const loanPercentage = handleCustomerType(loanApplication, URL, discount);
response.send({ success: true, percentage: loanPercentage.getOrElse(0) });
};
It is not much longer than the original, but far more readable and maintainable.