Build Better Tech with a Linter, a Formatter, and Code Reviews (QA and Tech Debt Pt 2)

This series is about building quality tech products specifically geared toward tech startups.

The second step to reducing tech debt and saving your tech company is to include static code analysis and code reviews in your pipeline. Here Dr.Miles Aron will walk through a straightforward approach for any early-stage company.

Transcripts (the following transcripts are auto-generated and may have typos or inaccuracies):

so on the QA side we are talking about

what the users see right away and

putting that in place is going to save a

lot of pain for your users but it

doesn’t tackle the topic that I opened

the whole video with which is technical

debt it’s a form of debt it’s it’s it’s

really a quality problem but it’s not

the actual Tech itself necessarily

that’s the issue there it’s just

adhering to a style guide and making

sure your designs match and your user

stories match your actual product

so now we have to look under the hood we

have to look at the technology itself

and

um there are a number of things we can

do there the first

um obvious thing to do is that even if

you’re working with

um lower costs or less experienced

developers

um what you should do is have

um code review so just having a more

senior developer read through that code

every single pull request that comes

through you think about it it’s taking

them 10 minutes to read that to read

that and make they’ll make 10 comments

it’ll get pushed back to the developer

and they’ll fix it now there’s a

cultural reason that this is so powerful

and so cost saving which is that nobody

who writes code wants their code to be

sent back to them nobody wants to submit

something and have a senior developer

come in and say No it should be done

like this it’s really annoying to the

younger developers

um what I was developing it was the same

for me it was like oh man you’re going

to tell me to redo that function like

it’s it’s embarrassing it’s annoying so

the reason you want to do this is that

your developers are going to step it up

a notch so fast suddenly all your code

is going to come through at much higher

quality just because they want to get

The Passing Mark and the cost of those

code reviews is going to come down

because the code’s just going to go

right through it’s not going to take

that much time to review once you start

doing this so that one is the human

element now we’re going to talk about

the automated element what we can do

with code

on the code side the first thing you

need to do really in any project you’re

working in and look this applies to your

react and node apps it applies to

angular.net it doesn’t matter even PHP

you can you can integrate these

processes into any Tech stack so this is

not about the tech stack this is about

covering your technical debt and helping

your company save money and move faster

um and that first step on the technical

side and the automation side is to

install a really good linter with

industry best practices in there if if

you’re a JavaScript developer you’re

familiar with the es lint and TS lint

Community there are other linters in

every other language

um you can get sets of rules that have

been set by large companies that know

how to do this for example I think the

kind of standard for a long time was

using the Airbnb

um linting rules but what a linter does

is called Static code analysis so

um this means that it’s not going to run

everything that’s happening at um

compile like after compiles and you’re

at runtime because it’s not going to

know like if you’re doing all kinds of

dynamic logic if they’re async

asynchronous uh calls happening it’s not

going to be able to to handle all the

potential bugs that can happen there but

what it will do is look at anything that

you can analyze in in a in a static way

and what I would do is I would combine

your static code analysis your your

linter with a style linter as well and

so in the JavaScript world we typically

use prettier but there are many

Alternatives and ways to do this but the

reason here is to say look the tabs

versus spaces were lasted long enough

and nobody cares anymore we all use

Smart Ides

even the uh the Vim people who are all

think they’re cooler than everybody else

they even use their own you know style

add-ons and whatnot so

you want to just make sure that when

you’re when that code is getting

submitted there’s always the same number

of tabs and spaces there’s always a

space if you want spaces between

parentheses there’s always spaces

between parentheses

um if things should be camel case

um if objects should be camo case then

objects will be camel case Etc so you

want to make sure all your code just

visibly looks the same and while this

doesn’t impact the technology itself

what it does is it makes it extremely

readable and what is code code is

communication and so if your

communication is uniform what happens

your developers can read it faster they

all are speaking the same language they

understand when they open a file there’s

an expectation that the code’s going to

look a certain way and with the lending

rules there’s an expectation that if you

um

you know have some rule that says hey

there’s only one function per file for

example that when you open a file it’s

going to be one function and so I mean

there’s you know 100 rules that you that

you might follow but what they’re going

to do is they’re going to cut down that

Tech debt they’re going to increase

readability they’re going to increase

the quality of the communication and

they’re going to prevent a ton of bugs

now one tool you can use in the

JavaScript world to take this a step

further would be to to build with

typescript or some other static type

language so this goes beyond linters and

into just kind of choice of tech stack

but many languages come with this

feature unfortunately JavaScript was not

one of them in the early days so we have

a lot of spaghetti code with a lot of

weird bugs that nobody can track down

but um choosing something with static

typing is going to also improve speed

over time it might take a little more

time at first for developers to get used

to it but it tends to I believe the

statistic is that it cuts bugs that

you’ll find by 15 right out the gate

once you’re statically typed but more

importantly I think is the developer

experience of being able to to hover on

something in your IDE and get an

intellisense

pop-up some information back to that

developer that tells them some context

about it like hey this type is used in

these files this is what this type means

this

um you know this field on this object is

a string not a number or this is an enum

and here are the possible values so

you’re just basically giving your

developers superpowers when you invest

into using a static typing system Okay

so we’ve gone from QA to linting now

we’re going to go one step further in

the quality Direction and talk about

um testing there’s an old adage that

it’s not use that adage add a producer

Brown help me out I don’t know how to

say this all right so anyways there’s an

old say that um

that uh code will be Rewritten code is

temporary but architecture is forever

um and that’s something that I see

almost no early stage company nailing

um certainly there are exceptions the

more technical they are but many many

early stage MVPs and prototypes aren’t

really thinking about architectural

decisions at an early point they’re just

like hey let’s get this out I would

encourage you if you’re a CTO or

technical director to enforce some

architectural rules programmatically and

this is something I don’t see many

companies doing but I think it’s just

like a huge value add to the team if you

can pull it off it really only takes a

day to install and set up so there’s

just no reason not to do it

um but by architectural linting you’re

going beyond the static code analysis

and you’re actually looking at

dependencies you’re saying what files

are importing things from other files

and there’s a tool you can use called

dependency Cruiser that is actually

designed for doing exactly this kind of

thing you can set up architectural rules

that will enforce certain dependencies

to be used in a certain way

according to your folder or file

structure and the nice thing about the

tool is that it’s a completely Tech

stack agnostic because it’s really just

looking at files folders and imports

which pretty much every language is

using

so

um you can set up some rules that say

for example

um I don’t want you know I have this

folder of modules and in those

subfolders there’s all these different

modules that do different things I might

have you know authentication I might

have um you know a modal I might have a

slideshow whatever and I don’t want my

slideshow depending on my authentication

and I don’t want my modal depending on

my login button and whatever it is

you’re going to have tons and tons of

modules if you’re building an

application

the key here is is to set up your

architectural rules to

um

get your coupling under control and at

least make sure that your coupling is

known because a lot of people think hey

I went to static types I did the um the

static code analysis linter that you

recommended but my feature velocity is

still slow why is it so slow

well I’ll tell you I’ve seen behind the

curtains that a lot of these tech

companies and you’d be surprised how

many times there’s weird coupling

between all kinds of modules that have

nothing to do with each other and you

know coupling is an extremely

interesting and deep conversation

because things have to be connected at

some point things have to be coupled in

some way or they’re just completely

disjoint and and there needs to be

communication across them but where you

choose to make that coupling interface

is going to have a dramatic effect on

the speed at which you can develop

technology

um so

static code analysis plus architectural

linting plus QA Plus Code review now

you’re starting to look like a really

fast-moving smart tech company