- In this video I'm talking with Cody from Web Dev Cody,
and we're gonna be talking all about
how you can use TypeScript inside of a real world project
and the struggles you run into as a team
when you're converting from JavaScript to TypeScript.
So welcome, Cody.
- Hey, thank you so much for having me.
Yeah, so I'm Cody.
I have a YouTube channel I kind of do on the side for fun,
but outside of that I have a full-time job.
I've been working as a web developer for almost 10 years now
and the project I've been on, like he mentioned,
is a JavaScript project
that we've been slowly trying to convert
to a TypeScript project.
So I got a little bit of a perspective
on like our techniques that we've done
to like be successful with that.
- Yeah, that's awesome, and do you kind of want to talk
a little bit about that project?
Maybe how many people you have on your team,
how long the code's been around for
so we can kind of get an idea
of how large scale this project is
and how many people are touching it?
- Yeah, sure,
so this project started back in 2018 I believe.
So it's been in development for about five years,
and it's been in production
for almost like three or four years now.
We have, at all times there's been like 9 or 10 developers
working full-time on the project.
So every day we're making PRs,
adding features, fixing bugs, and yeah,
I think right now we have over
like 300 something thousand lines of code.
A lot of that was JavaScript,
and recently we've been slowly converting that
to TypeScript.
Anything else about the project you wanna hear about or?
- No, no, that makes sense.
So it's a pretty decent sized project.
I mean nine full-time developers is a lot
working on one specific project,
especially one that's been around
for as long as you've had it been around for.
So I'm sure you have really old, nasty code in there,
and you know, some jQuery stuff I'm sure shoved in there
that's an absolute pain to work with.
So it's a really good kind of example of a project
for how you go about upgrading a project to, you know,
newer technology to upgrading to TypeScript,
stuff like that.
So I guess we can kind of jump right in
to talking about that.
What was the reasoning your company
or the people that made the decision to move to TypeScript,
what was that reason for that?
- Yeah, so when we first started the project,
a lot of people were not kind of excited about TypeScript.
It was back when TypeScript wasn't as robust
as is now, I believe.
But it, you know, for my YouTube channel
I've been playing around with TypeScript
just to try to learn more about it.
And me and another developer
are really trying to push forward
like converting the project to TypeScript.
'Cause when you have like, you know, 200 endpoints
and you need to go and edit
some additional existing functionality,
it becomes very hard to like change code.
So refactoring becomes a little bit scary
without typed languages,
especially when you onboard new developers.
Let's say you hire someone
who's only been within the industry for like a year,
and now they have this giant project
that's 300,000 lines of code
and you tell 'em to fix something,
it's gonna be very hard for them to do.
So that's the main push
as to why we're trying to push to TypeScript
just so we get that additional IntelliSense
when we're like modifying code.
It's very, very useful, and I highly recommend,
like there's like a camp
that people like dynamic-type languages,
but I would strongly recommend just starting with TypeScript
even if it's a little bit harder
to hit the ground running with,
it's gonna pay off big bucks later on
when your project grows to like enormous sizes.
- That's pretty much what I always recommend people.
I mean TypeScript, like you said,
it's a little bit hard to get the ball rolling
right at the beginning,
but I find even on like a small to medium sized project,
the benefits you get from that IntelliSense
save you all the time you lose at the very beginning
when you're first getting stuff set up.
And the big point that you mentioned
is like when you bring on a new developer,
if you don't have any types,
and most internal projects, let's be honest,
have pretty terrible documentation if any at all,
it's really easy to make mistakes and not even realize it.
So having those types
kind of gives you a little bit of a safety rail
that prevents people from absolutely destroying your code
if they don't know what they're doing.
- Absolutely, yeah, I definitely agree.
- So when you finally did decide, okay,
we're gonna start converting things over to TypeScript,
I mean you had hundreds of thousands
of lines of code at this point.
Where did you like choose to start with that conversion?
Did you say, okay, we're gonna start with
the most active part of the project,
we're gonna start with some more
like smaller scale version of the project?
Like what was the kind of starting point?
- The way we did it is we started with
like the business logic side of things.
So like we have a react single page application
in the front end that's built up with the ES build,
and on the backend we have Express,
which is like deployed to Lambda,
but we do a bunch of like clean architecture stuff
so it's a lot more complicated.
But we decided to focus on the business entities,
and you can call them interactors or controllers,
like the actual like,
the thing that controls the business logic.
We wanted to focus in on that, 'cause obviously that's like
one of the most critical parts of your system,
and adding type safety to that
I think gave us the biggest bang for our buck.
If you heard of something called like business entities,
I would highly recommend starting with your entities first.
We were doing a bunch of like old JavaScript prototype
constructor ways of like making classes,
and switching those over to TypeScript classes
just made it a lot easier.
And now we're at the point
where like basically all the backend code's
been refactored into TypeScript.
Now we're slowly trying to get
all the react code transitioned over to TypeScript as well.
- And that makes a lot of sense
because the nice thing about business logic
is a lot of times it's kind of really clean.
Not necessarily the code itself is clean,
but the actual types that go into business logic
is usually relatively clean as opposed to like
when you start dealing with the front end,
you get a lot more ambiguity
'cause you have like client input and stuff like that,
but on the back end you have a lot more structured types.
So I feel like that's a pretty smart move.
And like you said, it's like the core,
most important part of your entire application
was that business logic,
and making sure that that is always correct.
When you were doing it, were you specifically focusing on
just like all of the business logic at once,
or were you maybe only diving
like let's focus on like payments
if you have that for example,
'cause that's the most crucial.
Like did you have a specific section in there
you started with, or is it just kinda like
whatever makes the most sense?
- I think the way we did it was we started with
like some of the easiest lowest hanging fruit.
'Cause when you have a bunch of developers
and only a few of them know TypeScript,
it's better if you slowly introduce these things
and like try to teach the team as you're converting entities
and converting controllers to use TypeScript,
and like every week
you'll have like a little brown bag lunch
and kind of like talk about like this is what a type is,
this is what an interface is,
this is the approach that we're trying to take.
So I would say start small, and to me I kind of held off
on like some of the most complex things
because I just didn't have like the mental capacity
to really refactor one of these large objects
that has like 50, 60 methods on it.
So start small,
and then just try to knock some out every so often.
I think it would be a mistake
to try to refactor everything at the same time
'cause you're not gonna be able to ship features or bugs
or fix bugs if you try to do that approach.
- That makes sense,
and kind of another thing that you run into
when you're choosing what you wanna refactor first
is you almost get like a bottom up or a top down approach
is kind of how a lot of people look at it,
because you can either start with something
that's at the very bottom of your stack,
like a utility function for example,
and you can start typing that out,
or you can maybe start with some of the higher level stuff
where it's like this is the thing
calling all of the other stuff.
It's like the first thing that you hit.
When you were doing your refactoring,
were you focusing more on those like
smaller building block pieces,
or were you thinking, okay, we're gonna try to refactor
this one particular part of business logic,
and then everything it touches we're just gonna
slowly work our way down?
- Yeah, I mean, I think we try to focus
on the building blocks.
Like for example, we have a business entity
that's used literally in like every single controller.
So if you start with that most used thing
and you add typing to it, as you start going out
and like typing the controllers,
you'll get all that IntelliSense
as you're trying to convert the controller
and like stuff will just highlight red automatically.
We tried going the other approach earlier on,
like start with the controller
and then go down into the business entity.
But then like you just get a bunch of anys, right?
You have an implicit return of any on everything.
So it's like this isn't really helpful.
So definitely start with the building blocks
and then work your way out.
- Yeah, I kind of agree I like doing that as well
because if you start, like you said, with the top level,
you don't really get any of the benefits of TypeScript
until you have the entire thing typed,
and then you no longer have those anys.
But if you start from the bottom and work up,
you at least have that type safety
as you're starting to work up,
and it makes it a little bit easier for me at least.
- Yeah, I definitely agree.
- I guess another thing that a lot of people run into,
especially when you're converting a code base
from JavaScript to TypeScript
is how do you deal with new code,
like brand new features, you need to write brand new code.
Are you writing that in TypeScript
or are you still writing it in JavaScript?
- Yeah, I mean at some point
you need to kind of have a discussion with your team
and say, "Hey, from this point forward,
all new code needs to be TypeScript."
And then you can also like add things
to your CICD build pipeline to basically,
if more TypeScript errors are introduced,
you can fail the build,
which I think another developer added in our project,
which is really useful because you don't want developers
to continue writing JavaScript when you've decided like,
hey, let's use TypeScript,
and also let's not keep on introducing
more TypeScript errors.
I think we had at one point,
this might be a separate question or topic to talk about,
but when we started doing the refactoring,
at one point someone decided
to rename every single JSS file "2.TS".
And the moment you do that you get,
I think we had like 14 or 15,000 TypeScript errors.
So one approach we've been doing is every week
just try to reduce that error account,
and after a few months,
like it went from 15,000 down to like 5,000.
We still have tons of errors,
but like it's in a much better state than it used to be.
- Yeah, also I kind of,
you mentioned renaming from JavaScript to TypeScript,
I find that kind of interesting 'cause I generally,
when I'm upgrading something from JavaScript to TypeScript,
I'll leave the JavaScript files as like .JS files
'cause that way they don't show any TypeScript errors.
I can clearly see, okay, this has not been done,
and then if I want to convert something to TypeScript,
I'll rename it to TS
and try to fix as many errors as I can.
Obviously when you have some JavaScript,
some TypeScript it could be difficult
but like what was your idea behind, I don't know,
maybe you don't know this, but like why did you convert
everything to a .TS extension at that time?
- Yeah, so another engineer kind of led that effort.
At first I was very hesitant
'cause I was kind of doing that approach
of like going through every file, refactoring it,
renaming it, and then get that committed.
Especially with Git, if you just rename a file
and then you do a bunch of changes in that same commit,
it's gonna delete all your Git history,
so you kind of have to synchronize as good
or you're gonna like remove
all the connecting history of Git.
But his idea was like when you have nine developers
all modifying code all the time,
at some point you have to just be like,
"Listen, like this is the week
that no one's gonna try to like modify anything.
We're gonna just rename all the files.
We're gonna get this merged in and make sure that you pull,
because when you do pull these changes,
you might have a lot of breaking changes."
I think, I don't know,
I think both approaches can be done well.
I think renaming everything requires a lot more
like team synchronization versus just individually
as you're kind of going through change stuff.
- Yeah, yeah, that makes a lot of sense.
And then like you mentioned,
obviously by renaming everything
you get thousands of TypeScript errors.
How do you make sure that the TypeScript error,
like you're actually being able to check
for TypeScript errors that are new when you're in code,
like I know you can do some CD stuff
to make sure that you're not adding new errors,
but if you fix 10 errors and introduce 9 errors,
you know, you're still reducing the error account by one,
but maybe those nine new errors are actual errors
while the 10 that are from just renaming files
are just because you haven't added good TypeScript yet,
how do you make sure
that you're not introducing TypeScript errors
into your code base, you know,
by doing this since you already have so many errors?
- Yeah, I mean, I'm sure there's ways to set up checks,
but I think it just boils down to like
you just have to have discipline.
Like when you're writing new code in a TypeScript file,
when you start seeing those red squigglies,
start traversing your code and refactor things
to really reduce those errors as you can.
Sometimes you just can't get past that.
Like you'll change one file to a TypeScript file
and then you'll introduce 1,000 new bugs.
So that's a good question.
I don't really know what the answer is to that.
I know one thing that we did is the TS config file,
it's very configurable, right?
So you can, at first you can allow
like explicit anys or implicit anys everywhere
and that's, I think, what we are doing now
is like we just allow, you can use anys wherever you want,
but at some point we're gonna flip that Boolean to false,
and like now you actually have to go
and fix all those implicit anys that we have
and tons of arguments and passing it around, et cetera.
- Yeah, yeah that makes a lot of sense.
I generally recommend people
when they start a brand new TypeScript project
to do TypeScript of strict being set to true
because that, you know, removes all the implicit anys
and all those other things.
But when you're converting from JavaScript to TypeScript,
especially on a large project,
if you start out with strict true,
you're gonna have tens of thousands,
hundreds of thousands of errors.
So like you said, it kind of makes sense
to disable certain TypeScript features to get your code
to the point where, okay,
I finally have gotten rid of some of those errors,
I finally got it working.
Now that I have it in a good place,
I'm gonna start enabling those different things,
and then it at least gives you something
to focus on when you refactor
so you can kind of have small wins along the way.
- Yeah, definitely.
- Let me think here.
So you kind of focused on going with the bottom up approach,
which is generally what I like to do.
You focused on the core business logic of doing this.
I guess another thing, how long have you been working
on this TypeScript conversion?
I'm guessing it's been quite a while.
- I mean, I think it's been over a year now,
probably even more than that.
But it hasn't been a full-time effort, right?
It's like, we still have a client
who wants features and bugs fixed,
and we still have to deliver value to that client.
And if we tell him,
"Hey, we're just gonna spend three months
refactoring everything into TypeScript,"
I don't think the client would be very happy,
especially when it's very hard
to like break down the technical value behind TypeScript
to other developers.
Imagine breaking down that value to a client
who's paying you to deliver features.
It's very hard, so you know,
we have like this this 20% rule,
excuse me, this 20% rule where every sprint,
I dunno if you guys do Agile or Scrum,
but every sprint you do 20% of the day of your sprint,
so like 2 days out of a 10 day sprint,
it's spent just on refactoring.
So those are your two days,
you can go through wherever you want in the system,
refactor things, make things better,
and then of course you can add more days,
you just talk to your manager or whatever,
and be like, "Hey, we need more days
to like really improve this part of the system."
And that's the approach we've been kind of doing.
So if you imagine you have 10 developers every sprint
spending 16 hours just refactoring code,
it's not super fast but you get stuff done.
That's the approach we've been kind of doing.
- Yeah, and I mean, honestly 20% is is a pretty good number.
There's companies out there where you're lucky
if you get 1% of your time
to be able to spend on refactoring
'cause it's constantly pushing new things all the time.
So, and that's kind of encouraging to see
because that 20% of time you spend now, like you said,
it's obviously not helping the clients at all,
but a year from now, two years from now,
that 20% that you spent now
is going to save you 40% hopefully in the future
where now you have all these extra features of TypeScript
so you're not gonna have as many bugs,
there won't be as many feature requests
to fix those bugs and stuff like that.
- Yeah, tech debt is real,
and I think it's good for engineers
to really convince clients and product owners and managers
like there's a big issue
with the way the system is architected
and we have to fix this, because like you said,
if you don't fix it now, it's just basically debt
you're gonna have to pay up some time.
So make sure you always spend time
just trying to refactor code and really fight for your,
it's like a professional thing you need to do,
just keep that clean.
- Yeah, and slightly off topic,
but speaking of tech debt,
one thing that a lot of people don't realize
is like there's no perfect way to write your code.
When you write your code, it may be perfect at the time
but in three, four years from now,
the features are gonna change,
the requirements are gonna change,
and that code that you wrote
that was perfect three years ago is now tech debt to you.
So like trying to make sure you're constantly keeping up
and refactoring your code as you go,
just always setting aside 10, 20%,
whatever it needs to be to do refactoring
is going to make sure that your tech debt doesn't pile up
because converting an entire code base, like you said,
from JavaScript to TypeScript is very hard.
But if you started that, you know,
only one year into the project instead of multiple years in,
it would've been a much easier and smaller process.
Obviously, TypeScript wasn't as big back then,
like you wouldn't have known to do that,
but if you can do that kind of refactoring along the way,
it saves you a lot of time in the future.
- Yeah, definitely.
- And kind of speaking of refactoring,
like let's say that you need to
maybe not necessarily add a new feature,
but you need to touch on an existing feature.
What do you do when you do that?
So you come into that code base, it's written in JavaScript.
Do you automatically say,
"Okay, when I change the code,
I'm going to update it to TypeScript,"
or is it a case by case basis?
Like how do you handle that?
- Oh, for adding a feature
to existing JavaScript files you said?
- Yeah, yeah, so like maybe you either need to add a feature
or do something that requires you
to change existing JavaScript code.
Do you use that as an opportunity
to update that code to TypeScript or case by case?
What do you do for that?
- Yeah, I feel like that's more of a case by case.
Like leave it up to the developer who's adding the feature.
Like some people like to just focus in on the feature
and then on the side they'll do their little refactoring.
That's the kind of developer I am.
I wanna focus on fixing the bug, and then after it's fixed,
I'll make a separate like branch or something
and try to do some cleanup.
Other people like to do, what's it called,
like the campsite roll,
or like as they're touching code, they try to improve it.
I have seen that really eating the time,
and again, it really boils down to
you're trying to get features delivered for your users
and your client, and if you go off on a two week tangent
'cause you're trying to like refactor too many files,
you know, all the stuff is like connected like a spider web.
So I like to like allocate some time
just specifically for refactoring, and that works for me.
Did that answer your question?
- Yeah, no that makes a lot of sense 'cause I know,
like you said, some people really like to be like
the leave it better than you came to it kind of thing
where it's a campfire rule,
you try to make it better as you go.
But as you said, one of the big downsides to that,
especially if you're converting
from JavaScript to TypeScript
is if you change one thing,
now all of a sudden it spiderwebs into 10 more things
and those each spiderweb into 10 more things.
So like what you thought was a 10 minute project
is now a two week long project,
and if you're just trying to fix a bug,
you don't wanna wait two weeks to fix a bug,
you wanna just get it fixed immediately.
So I think it's good to weigh it,
like you said, pros and cons.
If it's an urgent bug fix,
obviously don't worry about trying to convert it,
but maybe if it's something
that you can have a little bit more time with
or maybe the refactoring doesn't take that long,
then sure, go ahead change it over to TypeScript,
that makes sense.
- Yeah, and that exact scenario
actually happened like today and yesterday at work.
Like we change one function to instead of throwing an error,
it returns undefined
if they can't find something from the database.
And that basically caused us have to refactor
like 30 different functions
that were all calling that function.
So it's like one of those trade offs.
Can you estimate how much time it's gonna take
to fix all the places that the function's being used?
Is it worth doing right now?
How eager is the client to get that feature deployed?
It's all case by case really.
- Yeah, definitely, and the thing I'll suggest for everyone
is that if you think it's going to take you
an hour to refactor something,
it's probably gonna take you at least double that.
Refactoring I find always takes at least twice as long
as I actually think it's going to
because there's always some spider, you know, web effect
where something that you change breaks everything else,
and then it just takes all of your time to fix that.
Another question I have here
related to kind of the whole TypeScript JavaScript thing is,
have you found any benefits yet?
Like you said,
you're about a year into converting over to TypeScript,
have you found benefits where TypeScript has saved you time,
it's found bugs for you,
like it's made it so you have less bugs in production.
Have you found that benefit yet,
or are you still trying to get to that point?
- I mean, I think the IntelliSense alone
is like is the biggest benefit.
There's been some small bugs that it's helped us find.
For example, I think there's like some some icon in the UI
that wasn't showing up because someone wasn't returning
a certain property on an object.
If we had types, you know,
that would've lit up red instantly,
he would've known, "Oh, it's missing this Boolean,
and if I don't set this, you know,
we're not gonna have the UI show what's needed."
So we've had small wins like that,
but overall it's just the IntelliSense
really makes you feel like you can move faster.
'Cause obviously if you don't use a type system,
what you end up doing, at least what I end up doing
is you'll look at a function,
you have no idea what it takes in and no idea what it turns.
So then you go and you look at the implementation,
and then if you don't have JS docs
on top of the functions that you're using,
you then have to kind of like read through all the code,
figure out where those options are even used.
Is the options a number? Is it an object?
I'm sure people who code in JavaScript
kind of know that same pain point.
You get really good at it.
But when you start using TypeScript, you realize,
"Wow, I don't actually need to do this.
I just hover over the function
and it tells me exactly what I need to pass in."
So yeah, we've seen immediate benefits
with the IntelliSense alone.
- Yeah, that makes a lot of sense.
Like I definitely notice that
when I'm working with a library
that has TypeScript definitions versus one that doesn't,
it's a huge pain
if you don't have those TypeScript definitions
'cause you're constantly referencing the docs
if they have any, otherwise like you said,
you're looking at the source code,
and having to read through source code just to write code,
it really slows you down
'cause it's like you really have to flip your brain almost.
'Cause reading and writing code
almost takes like two different brain modes at least for me.
So it's constantly flipping between those two,
just slowing you down, not fun in my experience at all.
- Yeah, and I will say some people argue
for just using JS docs and like JS docs is good enough,
but from what I've seen, JS docs can quickly go outta date.
Like you need to go in and quickly fix a bug
or refactor something, you forget to update the JS docs
and now you have wrong definitions,
versus TypeScript, it literally updates for you,
so, different talk though.
- And I find that the problem, like you said,
with JS docs is you update something quickly
and now you have the wrong documentation.
That's almost worse than having no documentation
because now you're misleading people,
and they not only need to read the source code,
but they also need to know
that what you've written as the types is incorrect.
So yeah, I kind of really like TypeScript for that
because it forces everything to be correct really.
And you said that you've recently
or soon going to be moving on
to doing the front end portion.
Have you already finished the entirety of the backend,
or do you still have backend work to do
but you're now also adding on the front end
since you're kind of getting
to a good stopping point on the backend?
- I mean, in all honesty, there's gonna be holes.
I don't think we've completely finished the backend,
but we've fixed the places which are the most useful.
Again, anytime you're coding,
and like you hover over something and it says any,
you start getting into this habit of like,
"Oh, I wanna make this better for myself
so I don't have anys everywhere."
And you go and you start fixing that.
But yeah, I think we got the backend
in a like good enough state,
and now we're kind of moving on to the front end,
which we've refactored a lot of code.
Unfortunately we're using like a different type
of state management library that not many people use.
So we've had to like wrap our head around,
how do you actually type
all these additional library functions
that they're giving us?
Yeah, I'm not sure if I answered your question,
but it's a process.
- It kind of sounds like you've gone
with more like the 80/20 principle where you're like,
"Okay, I've taken the 20% of backend code
that comprises 80% of the uses of my application,"
and that's a really rock solid,
bulletproof for the most part TypeScript code,
and then the other, you know,
80-ish percent that's not used as much.
It's got some TypeScript,
maybe it doesn't have any TypeScript,
but it doesn't matter as much
because it's not really super important
and it's not something that's used all the time.
It's like you almost went ahead and you're like,
"Okay, here's my Stripe payments workflow,
that's gonna be rock solid TypeScript all the way through."
And then when it comes to like changing the profile image,
you're like, "Whatever, that's not super important.
People don't do it very often,
so that's okay if it's a little bit spotty
and kind of dodgy."
Does that kind of sound correct?
- Yeah, I mean, I'm not a very strict type of person.
I think, do the things that make sense.
If you found yourself wasting two full days
because of like a simple type error, just put an any on it.
Like if you could have solved the problem in five minutes
by putting an any but you decide that you wanna be,
you know, strict, everything has to be typed 100%
and you literally wasted 16 hours
trying to to get something perfect,
really reconsider like what you're doing
and like what your overall goal is,
and that's delivering value.
I don't think wasting all that time on one little thing
is very valuable to your clients or your systems,
but other things, you know, you have to weigh it out.
Some things are way, way more important
to like make sure everything is typed,
like you've mentioned your Stripe payment stuff.
- Yeah, yeah, you don't want the payments to go wrong.
That'll get you a phone call real quick from the CEO.
- Absolutely.
- I guess I don't really have any
other major questions.
Was there anything you wanted to add,
especially when it came to like maybe file structure
or anything like that that you've ran into
when it comes to TypeScript?
- As far as file structure and folder,
like directory structure and stuff like that,
I like trying to do, what's the word, co-location I guess.
So like some people like putting
a bunch of types in like a file.
Like they'll have like a types.TS file
and just throw everything in there.
I would rather types and interfaces be in the same file
of the function that's like needing them.
And then I like to just import those
other places in my system.
If it's a type that's used everywhere, then yeah,
maybe you can have it in like a shared types file.
But I think co-locating your code,
which is why like using NextJS,
which has like the file system kind of built out for you,
it kind of forces your hand in like,
if you wanna make a page,
everything in that page is usually gonna be a file
that's related, or sorry, everything in that folder
is gonna be related to that page.
When you get to a system that I'm talking about,
like really large, the tree browser almost becomes obsolete.
There's too many files, and you end up using fuzzy searching
for literally everything,
and especially depending on the file structure you chose.
In our project we use directories based on types.
So like all of our business entities
would live in an entities directory.
All controllers would live in a controllers directory.
I would recommend never doing that, it's become a nightmare.
There's also like the features approach
that you've heard of, I mean,
I consider it the same as like,
you have a folder for your page,
and inside of a subdirectory you'd have another folder
which you put all the components related to that
inside of that folder.
I think that's all I have about types and file structure.
I think the last thing I'll mention, which is kind of,
you didn't really ask this,
but for doing the refactoring over the TypeScript,
if you don't have a bunch of tests over your system,
we have a ton of integration tests, end-to-end tests.
That has been one of the main things
that has helped us be able to refactor,
'cause obviously if you're changing a bunch of code,
you know, you increase your chances of breaking stuff.
So I'm a big advocate of like test your code,
unit testing, integration testing,
end-to-end testing, smoke testing.
Some people say testing's kind of pointless.
Our company and our project think the otherwise, so.
- Yeah, no, I 100% agree on testing.
A lot of people think that, "Okay, I have TypeScript code,
which means I don't need to test
because TypeScript is testing for me."
But that's a huge fallacy.
Like TypeScript is doing a static check.
It's great for getting a few different types of edge cases,
like you typed your code incorrectly.
Like if you wrote your code incorrectly,
TypeScript will check that,
but TypeScript won't check to see
if your code has bugs in it because it was, you know,
written in a way that introduces bugs.
It just checks,
did you type in your variable name correctly?
That's really all it's doing for you.
- Yeah, I mean, a good example of that
is like imagine you have a business entity
that takes an email,
but TypeScript is just gonna say colon string, right?
You can put literally anything inside that object,
but if you want it to be in an email format,
you still want to have some type of test to verify
if you pass in a bogus string,
your test will throw an error or throw an exception, so.
- Yeah, no, that's great.
Anything else before we wrap this up?
- No, I think that's all I got.
- Awesome, well, hey,
thanks very much for taking your time, Cody.
I really appreciate this
and I hope everyone watching
also gets a ton of value from this.
I mean, I've already gotten a ton
of value just from talking with you.
- Oh, cool, appreciate it. Thanks for having me on.
- Yeah, no problem.