Introduction

[00:00:00]
>> Welcome to this course on enterprise user interface development. When we talk about enterprise user interface development, enterprise is just a word that means big, right. Big and usually like long lived versus like, the little like side project for a weekend. And with that comes a lot of extra like bonus things to worry about, all right.

[00:00:29]
So let's talk about what this course is, this is a course on how to build infrastructure. How to build the infrastructure needed to manage a large code base supported by a team of contributors. That means ideally, not just you. Usually, to the point where any code base over a long enough period of time, it's gonna get a few unique qualities to it.

[00:00:54]
It is probably going to get big, it is probably going to have a series of choices that probably seemed reasonable and good at the time. And, in the fullness of time, turns out to maybe have its edge cases, right? And there's lots of reasons for that, and we'll talk about it.

[00:01:15]
But let's kind of talk about some of these situations where, if any of these statements resonate with you, then this course might be for you. So hypothetically, maybe you've inherited an older code base, right, who doesn't love that? Maybe that code base has been through let's call them, changes in product direction, right?

[00:01:40]
What it was initially supposed to do, maybe it's a different thing now. Some of the most fun code bases that I've had the pleasure of working in are usually the ones where. Let's build this like proof of concept like demo app that we definitely shouldn't bring to production.

[00:02:04]
What's that the CEO wants to make the next big thing and it's got to be out in a week, and we're gonna bring it to production, right? So you have some of those, you have ones where maybe you were going one direction and then you did like a pivot in the direction now.

[00:02:16]
It's a totally different tack that you're taking out and now you have that kind of original foundation that may no longer be serving you. Yeah, maybe you're looking to migrate from an older framework, I'm looking at you backbone to whatever the new hotness or whatever the hype cycle is these days.

[00:02:36]
And you want to be able to like do that without like, having your pager go off from now until the end of eternity, right. Or maybe and like I have been lucky enough to get to do this one once or twice. Maybe you are breaking ground on a brand new project, with no tech debt whats so ever and you just want to start things off on the right foot.

[00:03:01]
No matter what there is something in the generalized strategy of this course that would kind of appeal to that, right? The code base I work on now it's not two years old yet it's 17, 18 months maybe 19 months, right? Even as I was preparing for this there are already things in the code base that is not particularly old and not.

[00:03:27]
Saddled with too much legacy, where there are already things that like some of the strategies that we're talking about this workshop already applied to the thing that I work on every day, right. And there's always reasons there are the initial plans you had even 18 months ago are no longer, some of the things you're doing now.

[00:03:46]
I was, for some reason decided to use a pre -⁠1.0 framework, so that came with a fun, set of things to learn as well. And then there's just the little mistakes that don't seem like a big deal at the time, for instance, not failing the build on lint errors and just getting warnings, or the same thing for accessibility.

[00:04:06]
Then when you go to actually turn them on, you realize that, over the course of six months, a bunch of well -meaning changes, saddled you with a bunch of debt that you need to pay down, right? So even in a relatively new codebase, but especially, let's say pleasure.

[00:04:21]
Let's say I've had the pleasure of working on like some front end code bases that are like a decade old, right? There are a lot of those become really difficult to manage and difficult to maintain. And we're gonna talk a little bit about what the word like maintenance means, and how do you maintain something and some of the parts around that.

[00:04:42]
But first, I should probably introduce myself. My name is Steve, I work on the frontend engineering team at a company called Temporal. When I started, I was the frontend architect, which at a startup is a fancy way to say. The first front end engineer, and I had it like my previous job so I think they just like totally gave me that title and make me feel good.

[00:05:06]
Now I run a team of about six or seven depending on the day, Front End engineers across two or three of our various code bases, whether it's an open source product. Cloud based SaaS product, the marketing website, some other internal stuff as well. And all those situations on that previous slide from the changing product direction to the thing that was probably never supposed to go to production to the like brand new codebase to the decade old one I have

[00:05:35]
seen those at various points. And so, that kind of culminates today, into like a set of practices and strategies around kind of starting to wrap your mind around. The kind of just nuances that come along with that. So what are we gonna cover? As you can imagine, having a relatively decent testing strategy is somewhat important if you're going to make changes, to a thing that you cannot hold in your head.

[00:06:12]
So we will kind of talk a little bit about some of the fundamentals of philosophy of testing, and we're gonna run the gamut from unit testing. So your browser based tests would play, right to some component tests across different frameworks. All those kinds of things get to the point where, okay, we now know that we can touch things, without worrying about something else breaking off the other end.

[00:06:36]
We will talk about like how and when to or to not to fake stuff, right? Like, a lot of times in a perfect world we would write end-to-end tests for everything, I aspire to live in that world one day, right? A lot of times we have to square, all the things that you've written a blog post about like, the right way to think about testing and then you have to square that with reality.

[00:07:00]
And the fact that most of those things are not possible at any kind of scale, right? And so we kind of talk about, like how to manage the kind of like, platonic ideal of what we're supposed to do with like the reality of the code that we live in every day.

[00:07:17]
We'll talk a little bit like as we kinda go through some of the setting up this infrastructure. When we can talk a little bit about like okay, what are some of the best practices or at least let me rephrase that. Best practices in my experience, for kind of structuring and thinking about whether it's components, whether it's the larger architecture of your application.

[00:07:42]
And like where can we kind of like learn from some of that. Some of those, depending on whether or not you are maintaining a relatively old large codebase. Or a brand new one that will have different amounts of like applicability, depends on those things but we will at least kind of talk about that.

[00:08:00]
Cuz at one point like there will be an opportunity to kind of leverage those. And then, as we all know, the real worst person on your team is you six months ago, right. The tied for second place is everyone else on your team, who does not put semicolons where you like to have semicolons put right.

[00:08:19]
And how do we actually like not so much about the semicolons, I don't wanna have that discussion, but like. We actually need this abstraction and we don't wanna just use let's say hypothetically fetch or like. Do we have a system to make sure that we don't accidentally ship a console log all the way to production or something along those lines.

[00:08:40]
What are the ways to kind of like maintain, and check these things? Running theme all of our time together, is going to be the fact that like, a large enough codebase over a long enough period of time. You will not be able to hold all this stuff in your head, you will not be able to find everything through every code review, right?

[00:08:56]
And so a big theme of our time together, is that kind of last bullet point down there. Which is how to build the processes, that make it so that you don't have to, right. Because we tend to get mad at our coworker who nitpicks all of our prs, right, and even I tend I'm the one that does that.

[00:09:16]
I eventually feel bad and just give in, you know who doesn't give in, automation, right? And like people will argue with you, but like they'll usually just take the fact that the build fails and deal with it, right? Like eventually it might come to a point where if your tests are flaky, everything falls apart.

[00:09:33]
But generally speaking, it is probably really good for the health of your team to have this stuff automated and dispassionate about all these things or whatever you agreed on and trying to like. Use it to the point where like it's serving you and not necessarily like pedantic.