How to assess Code Quality without reviewing code?
How to assess Code Quality without reviewing code?
When you join a new team, or a new developer joins yours, the expectation is quite the same - a good quality codebase that will help us understand the product without having to bug others.
In this episode of the Snowpal Podcast, Krish delves into the crucial topic of code quality. He begins by exploring the multifaceted nature of code quality, emphasizing the importance of maintaining high standards in a codebase. Krish then navigates through the process of quantifying code quality, outlining assumptions and considerations for evaluating a Node.js project developed by a team. He discusses the initial steps in assessing code quality, focusing on analyzing directory structures, file names, and the significance of consistency. Krish further examines the starting point of an application, highlighting the importance of concise and well-structured initial files. Throughout the discussion, he emphasizes the role of consistency in understanding and maintaining code quality. Krish concludes by stressing the importance of these principles in ensuring the longevity and effectiveness of software applications.
Summary
Introduction
Introduction to the podcast and its focus on code quality.
Definition and interpretation of code quality.
Quantifying Code Quality
Discussion on quantifying code quality.
Assumptions made regarding a Node.js project developed by a team.
Assessing Code Quality
Initial steps to assess code quality.
Analyzing directory structure and file names.
Importance of understanding the structure and naming conventions.
Examining Initial Files
Focus on the starting point of the application.
Ideal characteristics of initial files.
Analysis of routes and their significance.
Consistency and Understanding
Importance of consistency in the codebase.
Drawing conclusions about the application’s functionality without running it or reading documentation.
Podcast
Transcript
0:00
Hello hey, this is Krish. Hope you're doing well and welcome to Snowpal Podcast. Manage your projects on snowpal.com, be efficient, be organized and be happy. In this podcast.I want to talk about code quality.
0:18
It's another broad topic, but let's see how much of it I can cover or which what aspects of it I can cover in this podcast Now, Code quality?What does that mean?Probably it can be interpreted a few different ways, even though we all understand what it is.
0:38
Code quality essentially means you want to make sure that the quality of your code that becomes part of your code base stays is of the highest quality, right?So you want to maintain that code quality.But sure, right?That's a given.
0:54
But to quantify, how do you quantify code quality?We're going to have to make some assumptions as always so we understand the problem and we can, you know, get to what I'm trying to say here.So let's say you're working on a on a Node project, right.
1:12
So there's a Node application, It's, it's not terribly big, not too small either.So let's say it's it's decent sized application and it was built over a period of time, maybe 12 to 18 months by say 5 to 6 developers, right?
1:27
Give or take.These are all assumptions.Now the team.Let's also assume that the team had a code review process.But let's say they implemented that process a few months down the road after they got started.And let's say that the process has always changed and improved during the course of this time.
1:49
Like it, It happens everywhere, right?We have a process and then we get started and then we make the adjustments based on the team team's concerns and team's interests and and then the team's strengths and weaknesses as well.Now so I'm just summarizing a traditional team, right a 5 to 6 dev developer team.
2:09
How do you, what does code quality mean in the context of this team?How, how what?How the terminology evolves and how you can make sure that your code is is prim and proper and stays pristine in pristine condition or you fix what's not so clean and make sure it's good.
2:28
That's a lot of things.But let me go back to the beginning of this.What I said 2-3 minutes ago, code quality.And how do you quantify code quality now forgetting the platform, the language, the framework, everything.If somebody gave you a piece of code, let's say a number of classes, and let's say it's not, it's very small.
2:48
Let's say they give you like 2 to 5000 lines of code, right?Something you can review in a in a reasonable amount of time.How do you assess the quality of that code?Now again, we don't want to talk languages, frameworks and whatnot, but I might take some examples if I don't realize that I've stated the assumption that assumption.
3:07
So the first thing is you clone that repository, right?You could do these reviews like say on GitHub or other tools.I think Atlassian has one called is it Crucible or Fisheye or one of those things right?But but you could do it on GitHub.
3:23
Or you could clone and then use your editors to to look at the code as well.If you're doing different comparing commits, then you probably can use one of these other tools.But if you're just trying to assess the quality of a code based in entirety, then you obviously want to clone that repo and then check it out.
3:39
The first thing is the structure, the directory structure.Now, some frameworks mandate a structure and enforce that, while others don't, right?So let's assume that this code base that you're reviewing is built on a framework that does not our platform that does not enforce this this directory structure.
3:59
Now there is a good and bad there, right?If it if it were a framework that enforce the structure, then at least you know what you're looking for or where you're looking for those things.But if it's one of those other frameworks, the ones I generally like, that give you all the flexibility, then it's a double edged sword because that team could have implemented it very differently.
4:18
So you need to understand how the structure is now.That's all right.So the first thing you're going to assess is the structure, How?How you live direct, where you live, directories, where it starts out, what's underneath that, how many levels of hierarchy hierarchy there are within these directories, how many files there are.
4:37
Just sort of a rough analysis right before you look at the code itself, just saying, OK, is it 10 directories, is it 2025, is it 2 levels, 3 levels, 5 levels?Is it 20405080 hundred, 150 files?Right.So that gives you just the size of that.
4:53
How however those 5000 lines of code are broken down into it gives you a good sense.Now you want to make a mental note or even better, use a tool like pitch to to help you with this analysis, right?So in any case, so you that's the first set of things you're going to look at and once you have an idea, you now look at the the directory names.
5:14
That should tell you enough.If something is called models versus collections versus routers versus helpers versus utils and they all should hopefully mean not something dramatically different from what they are stating right So now OK, you you looked at those directory names and then you look at the file names and remember till this point I've not actually looked at a single line of executable code.
5:38
I'm just looking at the file names and I I want to make sense out of those file names.That the directory structure, the names of directories, and the file names should give me enough indication about what this product does.If they do, then I know that I'm looking at a pretty good code base, something that was written and designed well.
5:57
If I does not give me answer all of those initial questions, then you know that there is room for improvement and then how much room there is for improvement we'll know as we dig deeper.So at this point we know the structure, the names of directories and names of files.
6:13
Now we're going to start looking at the files.You want to start with the first file, right?That defines.That is the starting point for this application.And typically that file should not be more than 10/15/20, maybe 50 lines long.
6:29
It shouldn't be more than that because all that it's the primary purpose or the sole purpose of that piece of code or that file is to kick start your application, right?It's like sticking your key in your car and in those days are pressing the button or having it in the pocket these days.
6:45
Maybe it's a terrible analogy, but essentially the starting point for your application should be pretty small, right?I try to keep it under 10 lines of code, and again, I like to see more methods, more files, but fewer lines per method per class, because it's much easier to maintain.
7:04
We'll get to those aspects of it at some point.So given that, I don't want to see more than 10/15/20 lines, maybe 50 lines tops in those initial files that get the app going.Now I find that file and I know that's where the app starts running.And at this point I'm not even running the app right.
7:21
I don't even want to run it till I get a sense for this application.Then you look at, OK, sure, the app.This is the starting point for the application.What is it calling out too, right?Are there filters, controllers, routes, whatever that particular platform calls it, It doesn't matter.
7:39
They mean slightly different things in different platforms, but the underlying fundamental concepts are not quite not very different from each other.So you go look at those initial files as starting points, you look for the, you look for the routes.You to give you a sense for, OK, how many different routes there are in this application.
7:57
That might tell you a little bit more about the pages and the dependencies between the pages, the routes, the the views, controllers, models and everything else, right?So the routes is is kind of important and essential, where it's defined, how it's defined.The syntax can change between platforms, but but the notion of those routes and definitions does not change.
8:18
So you look at those routes, and from what you've even looked at thus far, you should have been able to tell how consistent this code base is, even though we've not looked at any real code yet.Except for the routes, the directory naming, whether it's camel case or sneak case or underscores or whatever, it is right?
8:40
You want to make sure that all of them are quite consistent.If they're not, then you know that there are some.Those are items that need fixing and refactoring.But if they are consistent, and if you're looking at a code base that thought through all of these items and define them well enough, then you should have a pretty darn good picture about what this application might be doing, even without anyone telling you anything about it.
9:05
I don't have to read any documentation.I didn't have to run the application.But just by looking at these things it gives me a pretty good picture.I I try to I want to keep these podcast under 10 minutes and realise that I don't always manage that this one's just about 10 minutes.
9:22
I'm going to end this one here.I'm going to follow this up and and other podcast because there's a lot of items I want to talk about in terms of code bases and quality of code bases and how we can go the extra mile and making sure that you you actually maintain that quality as your application and your needs grow.
9:40
Yep, talk to you soon.
Thank you.
Snowpal Products
Backends as Services on AWS Marketplace
Mobile Apps on App Store and Play Store
Education Platform for Learners and Course Creators