What is Quality Code

[00:00:00]
>> Francesca Sadikin: So what is considered quality code? When I was learning how to code, I knew my code sucked, but I thought I was going to learn what quality code looked like when I was joining a big company and I was gonna be paid to code. But you might be surprised that the code you see in companies, big and small, can sometimes suck for many reasons.

[00:00:23]
So you can't use what you see as a good pattern to copy. So this is my question for you all, what is considered quality code?
>> Speaker 2: It meets the user's needs,
>> Francesca Sadikin: Meets the user's need, okay?
>> Speaker 2: Somewhat flexible to expanding use cases, its performance.
>> Francesca Sadikin: Yes, are these your answers or [LAUGH] answers for this?

[00:00:48]
>> Speaker 2: Yeah, they're my answers. It's subjective, right?
>> Francesca Sadikin: It's subjective, okay.
>> Speaker 2: Yeah, so different people have different opinions on it, but. Yeah, I think, the first thing that Mark said was good where does it solve the problem at hand.
>> Francesca Sadikin: Yes, definitely important.
>> Speaker 2: I'll read a few from online.

[00:01:08]
>> Speaker 3: I think the very first thing is, he has to solve the problem. And then the second thing is, he has to be readable. You have to comment it out so that people can see what you're doing. Other people can work on your code.
>> Speaker 2: Yeah, that's online.

[00:01:24]
Folks said, self-documenting, easy to understand by a new person, not spaghetti like logic, jumping around everywhere. They're a lot focused on writing code that will be read by people. It's easy to read, maintain, and extend, yeah.
>> Francesca Sadikin: That's a lot of- Yes, a lot of great answers, and I hear the answer that I was going to give also in there.

[00:01:55]
So essential I believe that at the heart of it, code is going to change. So good quality code, good code and I heard this answer as well, it's maintainable code, which means it's easy to keep stable and it's easy to change, so it's extendable. So I think that tactics such as readable code, unit tests, performing code and all of it, of course, solving the real requirements that was given.

[00:02:26]
These are all techniques to make it more maintainable. Maintainable code is also often simple and straightforward. So readable code will always trump clever code that is somewhat unreadable in a professional setting because it just makes it easier for others to come in, quickly understand what's happening and make modifications.

[00:02:47]
Let's not forget, working code is always going to be more important than clean and perfect code. And balancing the delivery of features and accruing technicals that is a delicate balance that every company and every team will be engaging in moving forward. So here's just a little rundown of some clean code basics.

[00:03:11]
A lot of these I learned through this book called Clean Code, a Handbook of Agile Software Craftsmanship by Robert C Martin, I think that's a very popular book for engineers. But for a few of you who may not have seen that before, just a few tactics are to use descriptive naming, lean into maybe even longer, more descriptive naming versus very vague things.

[00:03:38]
Writing decoupled code, so that just means that different parts of your code base are independent and don't rely too heavily on each other. Essentially, it helps you avoid a tangled mess where changing one part breaks everything else. Follow the single responsibility principle. That's a very fancy way of just saying that whatever size of code you're working with, whether it's functions or modules or libraries, each one should hopefully have a single responsibility.

[00:04:06]
Again, makes it easier for people to understand what this should do. Having a clear organization of code that applies to the way you're organizing your code and then also maybe in your folder hierarchy. My little rule that I follow is that things that change together should stay together.

[00:04:27]
So, for example, you have a React component, all of its tests and helper functions should stay in the same directory as it, that just makes it easier for engineers coming in. When they make a change here, they can quickly check the related files to make sure that there's nothing else that's gonna break unexpectedly.

[00:04:49]
Using comments appropriately, so comments should describe why the code is there and not what and how. Because ideally the code should be readable enough that people can read what's going on. The other reason is that when you describe what and how when people refactor their code, it's very easy for them to forget to update the comments and now we just have a very confusing thing for future engineers.

[00:05:20]
Avoiding code duplication, so this one's kind obvious. If you copy and paste things multiple places, it's very prone to human error, you're gonna forget to update things in all the different pace, right? And depending on your company culture, you should also be adding test coverage and writing good tests.

[00:05:43]
So a huge part of writing maintainable code is writing tests. So we're gonna talk about one of the biggest strengths in my own software skill set that helps me deliver good quality work, which is test driven development. If you don't know anything about test-driven development. Essentially, it just means you start with test before you write the feature code.

[00:06:05]
And so what that would look like in a process is that. Let's say you had a big project, you're gonna break that down into different conditions, and then so you're going to start with a single condition, write a failing test for it, and then make that test pass by writing the source code.

[00:06:24]
And then you just repeat this process over and over and over again, and every time you see an opportunity to refactor because a pattern has emerged, that's when you refactor, and then you do this until it's done. So that's really all it is.