Transcript from the "Static Analysis" Lesson
>> Lukas Ruebbelke: I think these are gonna be pretty fine from. So these are kind of cool fun things that I like talking about. So, who here has never made a mistake in their code ever? Like who perfect code from day one, nobody, right? More importantly, how many of us have actually made a mistake in our code and we genuinely realise it much later.
[00:00:22] Yeah, this happens all the time. And so, having feedback loops, to help us catch what we're doing and surfeits it so we can fix it, as well as giving us insights to where things may be going wrong. It's critical for us making the best possible code we can.
[00:00:42] So this is where static analysis comes in, in a big way. And so we've seen this already in the background, is we're working within the IDE. And so there's this angular development kit that the team has produced. That is essentially an SDK about how angular works. And so this is for you notices I'm typing.
[00:01:05] And if I messed something up, angular is telling me like, hey, you got this thrilling light space all the time it's telling me that. But, it's letting me know like this could be better, you could make this right. And so this is essentially what's happening cuz it's linting my code, is I'm typing it's saying, does this match the rules that you've set up.
[00:01:27] So there is this thing called the Angular Development kit that allows IDE and different things to know things about the language and communicate with kind of the framework. And so as you're typing, you're getting feedback of like, this is right or this is wrong. And as well as IDEs are running TSLint and as well with codelyzer is written by Mingko is, and it's not only doing TSLint but it's also running it against the actual style guide for angular.
[00:02:04] And so we can manually force this with NGLint. And so if we go to our command line, and I would just clear this up. And so this actually may be in a pretty good space right now. But let's just kind of mess this up.
>> Lukas Ruebbelke: So we will go with, I dunno.
[00:02:29] Here why not.
>> Lukas Ruebbelke: We'll just kinda do some stuff. This might actually not do anything but, I know what will get this really upset. We'll go var foo = var. So one you'll see it's running in the browser, but occasionally you'll still miss it. So I'm gonna save this.
[00:02:57] I'm gonna go back here, and I'm gonna run this again. What we'll see is, it telling me like, hey, you've got a trailing white space. You are using var instead of let. A let that's forbidden. And more so, foo is never reassigned: use 'const'. And it's a missing whitespace.
[00:03:18] So it's letting you know, hey, there is stuff that's broken here. Now what you can do is, I think you can go entry lint fix, let's try this.
>> Lukas Ruebbelke: And so we'll actually try to fix them. I don't think it did other than, I think it did actually most of it.
>> Lukas Ruebbelke: Which is interesting, so I would probably manually do most of this just cuz it's kind of weird saying I'm trusting my code base you. But running ng lint, it gives you good feedback. Because of the angular development kit we're getting this in the ID as well. But, if you are on a team, this should be part of your build process, is you should run lint on all your code before you check it in.
[00:04:12] Because that's just an easy first level of sanity to make sure that things are of sufficient quality. So this is, the first piece of static analysis, it's very easy and it's running in the browser.
>> Lukas Ruebbelke: So let me just double check to make sure that I'm back on the golden path.
[00:04:32] All right, so the next thing is code coverage. Now this ships with angular CLI, right out of the box. If I go ngtest-cc,
>> Lukas Ruebbelke: It's gonna run,
>> Lukas Ruebbelke: And so what it's gonna do is it's gonna go ahead, run the test. And then what we're gonna get using Instable is this really nice report of how well you've done on your code coverage.
>> Lukas Ruebbelke: Everything passed and we're good. Let me hop into the browser and if we go up here, you'll see there's this coverage folder, that has been generated. And from here you can just open this, and I'll just open this from WebStorm. And I was telling you like, okay, like App Home this can probably use some work and you kind of click through and see like, hey, there's some stuff that does not have test.
[00:05:41] So you can start to visually see like, okay, we need to clean this up, we actually need to write some tests for some of this.
>> Lukas Ruebbelke: And so this is a really nice way to get insight as to how well you're doing on your code coverage. How long did it take me to do that?
[00:05:57] All of five seconds. Well okay, if you add in the time it actually took me to open up this browser. You know, maybe 60 seconds. So now, it's really easy and convenient for us to get this feedback loop and this insight into our code.
>> Lukas Ruebbelke: Let me show you one more cool trick that I use, that I just actually learned about.
[00:06:18] And I have to pull up this slide for this. So ng test you see, there is a way, there is this cool plug in called Source Map Explorer. That allows you to see a relationship or some incite into how your application kind of fits together. So what I'm going to do,
>> Lukas Ruebbelke: Is this. We'll go back into our command line.
>> Lukas Ruebbelke: And it's already been installed, so I'm just going to do ng build, and so this is just going to create a standard development build.
>> Lukas Ruebbelke: And so this is going to generate a development build and it's going to include the source mats, which is what we're going to use to analyze.
>> Lukas Ruebbelke: Okay, so you can see here we've got the vendor bundle and these different things. So then you go, source-map-explore and then this is a ./dist/ and then let's go with the vendor.bundle.js
>> Lukas Ruebbelke: Wait for it.
>> Lukas Ruebbelke: As now you can look and see that, okay. In development mode my application is 4.22 megabytes.
[00:07:50] You start to follow this down you realize, my compiler is taking up a meg.
>> Lukas Ruebbelke: And you know material also about a meg. But you can see like, okay. Where are the big pieces coming from? And so for instance, I have about 100k in RHJS operators. And so you can start to see, where this will come in handy is if you actually import all of our xjs.
[00:08:20] And also just like, where did this 300 megs come from? And so what I'll show you here, let's do ng build. And so this is where I was talking about like deploying. You know, we're kind of getting on top of that. So we'll ng build --prod,
>> Lukas Ruebbelke: Was source map, let me see here.
[00:08:43] I'm trying to do this all by memory.
>> Lukas Ruebbelke: Okay, Iet's close.
>> Lukas Ruebbelke: So I'm gonna do a production build, which is slightly different. Actually quite a bit different, so it's much, much more optimized. But I'm using the -sm tag to generate source acts. Cuz generally with a you don't want to do that, it's unnecessary.
[00:09:15] But in the case of actually running this, I'll be dutied to generate source maps.
>> Lukas Ruebbelke: We just may get dark by the time this finishes. All right, so now let's go source-map-explorer.
>> Lukas Ruebbelke: We'll run with this vendor build, so,
>> Lukas Ruebbelke: Now notice, this is pretty highly optimized actually.
[00:09:47] So now we're at 1.25.
>> Lukas Ruebbelke: So here, 4.2 megs. We've chopped off at least 3 megs by doing this, so that's actually pretty fantastic. There's probably some other things that we can do to break this out, and make it even faster. Yeah, you can see the difference. Now the question is, what's the difference between a production build or dev build, staging or dev or whatever?
[00:10:24] Well, now you know, because we're analyzing the code, we're giving this hard numbers that you can then use to analyze. And so I have been in calls where, for political reasons, some other team had some agenda, they wanted to use some other technology. And so what they were using to drive their agenda is actually coming against in this case angular and saying this is inefficient and [SOUND] it's not gonna do it.
[00:10:54] And when you can show up at those kinds of meetings with hard numbers and say no, your corporate website it actually pulling in jQuery, which is almost a meg. And our application is running angular and the compressed G subversion is like 50K. Let's talk about who is running inefficiently.
[00:11:16] And all the sudden, you start to invert those conversations because you have hard numbers. And so here's three easy tools to get those feedback loops in your app. Ng lent using co-coverage, so that's ngtest-cc. So we can see where we are on our test, and then using source-map-explorer.
[00:11:40] This just goes a long way to saying, I don't know what's going on with app to saying here's some very clear actual things that we can do in our application to make it better.