Following Best Practices

[00:00:00]
>> So we've talked a lot now about different categories of the view ecosystem. But at the end of the day, right? We have to remember that what makes an an application enterprise level, or frankly like production grade, is a lot of time the fact that it is easy to follow best practices and that the conventions are followed.

[00:00:20]
Because the one thing you need almost above anything else in an enterprise level app is consistency. If you don't have that level of consistency, then you introduce, as you would expect unpredictability, into application architecture, which means you're going to have either a lot of technical debt or simply communication debt over time.

[00:00:40]
Because as we know, as I mentioned earlier, I've worked on teams where like the contractors are working on the other side of the world. And so this makes timezone overlap like near impossible. And so if you can imagine if someone writes something in a way that breaks convention, and they're allowed to, and then that enters the code base, but then they're the only ones who know understand or how to fix it.

[00:01:00]
This means now you're gonna basically lose a whole day of development over like these bugs. And if you multiply that across multiple developers like, this cost me astronomical to development processes and companies in general. And so that's why we're devoting this section to really talking about the importance of making it easy to follow best practices.

[00:01:20]
When it comes to best practices and why they're important, right? We've discussed some of those things as far as they scale, but as developers, right? What does best practices mean for us at the end of the day? And oftentimes this means that we are faster at development. This means fewer bugs and at the same time, because we have all these things, this means you have more opportunities for learning.

[00:01:39]
And because you have the ability to experiment with things, and you know basically the boundaries in which you can experiment without breaking things. But the problem with this phase best practice, even though we use it a lot, and this is more or less a convention of saying it, I prefer the term or the phrase chosen conventions instead of a company.

[00:02:01]
It's because when you're talking to your team, you're trying to convince them on certain things, right? Let's say for example, you really like the flat, flat component architecture. If you were to go to a team who's traditionally used to something like Nested architecture, and you're like This is a best practice, there immediately creates this like sort of us versus them mentality.

[00:02:23]
Because best right by default implies that like this is the number one thing to do, when as we talked a lot about, there are reasons for either choosing one site or another or frankly mixing two different approaches in the case of the flat versus nested folder directory structure.

[00:02:41]
And so that's why I think chosen conventions or frankly, when you're talking to them about changing a convention, I think this is better for stakeholder communication. Because now it's not a matter of asserting superiority or whether one idea is smarter than the other. But whether or not like I think it basically allows you to have those discussions objectively about which convention fits best for their team, rather than whether or not their team is following a best practice which inherently comes with some judgment.

[00:03:10]
And so of course, this brings us to the question of what makes a convention good, right. And I put this quote because again, we want to avoid this judgmental factor when it comes to deciding what is the team doing this is not necessarily good or bad. But ultimately, like if we're talking about the evaluation of conventions, there are two primary factors that contribute to whether or not the convention is basically a good fit for the team or not.

[00:03:34]
And the first thing is that they enable to the developers to write great code with a low barrier of entry. And so the way to think of this one is that when you're deciding on a convention, if the onboarding process to figure out how that works, is super tedious, right?

[00:03:53]
It has a lot of basically what they call it a number of different steps to get something done. Each additional step that you add to the process of following some sort of convention is just one and like the likelihood of them abandoning that halfway through is much, much higher.

[00:04:09]
So the example of this is we talked about automatically generating test unit tests with your components, for example. And so if you didn't have that this means that going forward whenever a developer is creating a new component by default, if they're not using a generator, they'll do like right click new base button, base button w component, and then they'll just develop, right because that's, that's our natural flow is to just like, do the thing, solve the problem and then go forward.

[00:04:34]
But now if you're like, by the way, every component should come with some sort of basic unit tests. And now you're forcing the developer to not only then create that, but then they have to go well. All right, now I have to create a test where did the test go?

[00:04:48]
And then you go, okay, the test files here. So I create the test. What's the naming convention for tests? Are we doing dot tests? Are we doing dot spec and then on top of that, then you have to also make them, then think of the burden of like.

[00:05:01]
I don't really know testing because if we're being frank about things a lot of us entering into this field these days don't necessarily come with like a hardcore testing background. And so testing unlike just the reality is often becomes an afterthought. So now you've added this other barrier, where if they're not used to writing tests and Jess, where they kind of have an idea, but don't really understand, now they need to go to a different test.

[00:05:24]
We need to copy it and kind of modified it accordingly. And at this point, you've noticed that I've just talked through like four or five steps just to create a unit test for a component that they should be working on. And they might lose hours on this because as we know, when you're working on a team, it's sometimes tricky to get people's help or sometimes people have like they want to be self sufficient.

[00:05:44]
And so they might feel like intimidated to ask for help. And guess what, because we did not automate this piece right this this easy this best practice right now like based on this like the general convention of all components should write should have unit tests. Without automating it, we fail this first valid qualification.

[00:06:05]
Which is that, the enable developers write great code with a low barrier of entry. In my experience when, developers have a scaffold for them waiting for them, especially with like unit tests, they're like, that's kind of how it works. And I just add another IP block, and then I just describe it, and then I pass my function, and then okay, that's it.

[00:06:23]
Okay, done. Moving on. They can focus their energy on what matters which is writing the test, rather than creating the file and doing like all this hurdles just to get to the test. And so with that, once you have that piece the other thing to really consider then is, is it easy to refactor or abandon because conventions come and go The variables that come into play as far as whether or not you should do things a certain way or not can change with either the team makeup, maybe the department is changing tech stacks or whatnot.

[00:06:59]
And so the more that these conventions are easy to go, you know what this convention isn't working for us. Let's abandon it. The better it is because this also has the added benefit of in the future. If someone's like, yeah, this is not working for us. You don't want to make it extremely painful for them to get out of it.

[00:07:15]
And so this is why a lot of the conventions and best like, best practices we talked about today. Are lower barrier of entry, like they more or less try to follow that low barrier of entry. Right, so that if, for example, you want flatter directory structure with your components.

[00:07:29]
We're not saying take the time to refactor everything onto flat, but maybe start by not having so many components nested and saying like, hey, can we at least keep it to page level components and seeing how the team feels about that, and then they might eventually move to the next thing.

[00:07:43]
Whereas if you're like, no, let's like strip everything out of the directories and then like move and then like then you've created a situation where people are going to be hesitant to try this convention because in the event this goes poorly, or even just poorly like people just don't like it.

[00:07:58]
Now you've made it really difficult to move backwards. And so this is also my belief of tooling. It should be easier to enter the ecosystem it should be easy to exit the ecosystem and conventions similarly should be the same way.