Jozi.JS 2018, 22 Jan 2018

Previous Meeting

⏯

youtube image

►

From YouTube: Code Quality - Unit tests and code reviews - Mitch Horne

Description

When looking at keeping up code quality and maintainability of your code base, as well as make CI and a good night's sleep on prod deployments a possibility. I will be looking at the pros, cons and a brief "how to start implementing" of unit tests and code reviews - comparing them to each other.

Jozi.JS exists to try and foster a community in Johannesburg, a meetup group dedicated to all things JavaScript!

The group meets on the third Thursday of the month. There are typically two speakers, on different topics: a ‘lightning talk’ of 15 minutes and a full presentation of 45 minutes.

https://www.meetup.com/jozi-js/

A

Hi guys, my name is Mitchell. Just tell me if you can get me at the back, so I'm pretty much all around JavaScript's phonetic. As you can see front end nodejs code quality has recently been my new addiction I work for binary digital as a software developer and note the e. The e is silent, just just saying okay. So today, my topic is gonna, be about code quality, with a specific focus on code reviews and unit testing.

A

So moving on what is code quality so for me personally, I think it's a collection of tools and techniques used to improve the quality of your codes, to the point that you can maintain it for a longer period without having to cry every time to get it. So some of the tools that you can use for that is automated testing. You have linters, you have your code, reviews and well wrist is on there and obviously like refactoring, quite important every now and again, so the.

A

Why I take my cue for why the same place as Edmund Burke, two kids, as in the only thing necessary for evil to triumph, is for good people to do nothing and that's the only thing for bad code to triumph is for good developers to do nothing, thus code quality is there to give us a way to do that. So, starting with code reviews I found, there are two major ways of code reviewing that's pair programming and your tool-assisted reviews, such as your code reviews on bitbucket and github.

A

I'm gonna go a bit more into detail in each of these, but the talk of role will be a bit more high-level, so with pair programming.

A

Yeah, as as with all things, there's a given at sake, good in a bad, if you will so what I find was pair programming is, it is extremely effective at finding defects really early. Did you have two people looking at the same code at the same time, both in the same mind, space, we're looking at the same problem domain? Thus I find it probably the most effective way since you have a driver and you have a navigator, so your driver, obviously the coder and your navigates are looking at a higher level.

A

Thinking of how this can be used in better ways, so that's very easy to pick up on mistakes early on. Secondly, it's great for mentoring and knowledge sharing. So especially when you have a large divide in experience between the two coders. Once someone is driving doing some code and possibly the other, the Navigator is more experienced. He can highlight things much easier that he would not have picked up on his own or would have taken a longer time to learn on his own.

A

So now you're sharing really great in pair programming and then the last thing is it's a very tight feedback loop, so with agile, one of the most important things is to iterate. They actually improve. You do something you fail, you learn you get better. So thus you need to improve your feedback. Loop has get it as tight as possible, and since you literally have someone sitting next to you, while you're coding and giving you feedback, that's probably the most site you're going to get that loop.

A

Now, as with a bad thing, you've got two devs for one piece of functionality that size up two resources for everything you need to pump out. That's obviously quite a time sink. You can also also another quite thing quite a thing that is bad affair programming compared to your tool-assisted stuff is everything is verbal or your communication or your decisions in your code going a certain way? Is verbal, so there's no way in six months time going back to it and looking.

A

Why did we make the decision to use X library here, for instance, and also you have personality clashes or what some people would call hygiene differences? So this could be a really big problem when you say in one workspace with someone you dislike and as for us, we don't like everyone.

A

We work with that's just a fact of life and then the final bad thing, or not, really a bad thing, but more of a challenge is you need a change in culture of your business to actually be able to implement this, getting everyone to become, to go and understand the reasons for pair programming and now moving on to tool, assisted reviews. So this also is effective at finding defects. As you have multiple people.

A

Looking at the same piece of code, you could notice things that the original code might not have either understood known or noticed himself as inserting mistakes, so you also have that it's also a great mentoring to, as you have comments which would be feedback both for reviewers and persons submitting in the review. I personally can attest to this before code reviews. I pretty much didn't know how to program. So that's where I learned how to program by being chewed out constantly, with like 100 comments on my code and then another benefit.

A

Is it's asynchronous so you're freeing up your resources to work on different functionality and submit a code review? The person picks it up at his own pace or his own time, so he can still continue with his work, thus get more stuff done. Then it is also a managed workflow. You know exactly how it works it doesn't it's got not kind of a wing it as you go if they're programming, you know you do your code, you submit a review, they comment on it.

A

You fix whatever needs to be fixed, iterate, merge and then lastly, you know so as if I feedback too, because it gets the feedback on the code gets back to you before it ever reaches testing or development or production. Anything like that now the negatives of this, so it is of course vulnerable to poor reviews, as you might get a reviewer that has an off day and he just doesn't care to look at the code properly or just someone who doesn't understand the problem domain.

A

So it's always always wonderful to that, but you just kind of have to work at that that one of the inherit problems with it also, you can get really nasty, merge conflicts and I'm gonna get a bit into that after and how to implement these code quality changes, but just suffice to say that if you don't leave your ego at the door, it's real easy to get offended by things being said about your code, so we all have our pride and then lastly, also takes culture change as its not very natural.

A

Just stop your work in the middle and start doing a code review for whoever asks now tips on starting this thing, as I just mentioned, leave your ego at the door. So your code review is a place to learn and to prevent bugs that would otherwise be much more expensive to fix. Later down the line, it is going to be criticized and it's gonna be questions about it, and if you find that it's wrong, that's a chance to actually take that in and become better.

A

Another thing to keep in mind is to not use pronouns, try to review the code and not the coder instead of saying you did this wrong, rather ask something like don't you think we can do this in a better way, for instance, the picture at the bottom is a good example of that.

A

So the third thing don't be fussy, so if you're using kirtland, if you loo using lenses, let them do the job, don't spend your time in code reviews actually looking at styling and formatting issues.

A

That's why the lenses are there and they do it much better than humans do anyway, and the fourth thing, as you're supposed to find the problems, not the solutions, so something that I found myself falling into quite a bit is finding something that I think I can fix really easily spending 30 minutes fixing a review, that's not mine and then merging it very bad practice.

A

You're not only wasting your time as the reviewer, but you're also taking away that opportunity from the person who made the review to learn from the mistake that you've just found the first one: it's not all bad. So, yes, you are there to find problems, but let's say you come across a piece of code that you thought so something really amazing that you might not have thought of yourself and you've learned something from it.

A

It's always good to give your colleague a little pat on the back and like well done just boosting morale and then finally embrace feedback. This is probably one of the most important points and goes hand-in-hand with leaving your ego at the door. Every comment every problem found in review is a triumph and you're supposed to learn from it. It's not something a criticism of you, it's better for you to improve so next unit testing, so unit testing is pretty much breaking up functionality into smaller parts or units and writing automated tests for them.

A

Now, there's one large difference between that and integration testing, which I'm having quite a dilemma with myself, which one is better but I I'll get to get to figuring that out soon. So the biggest problem that I found with it is that it assumes that everything outside of the unit you're testing is working and it's tested on its own. So without something I could coverage to make sure that that happens. You're kind of working on blind faith, hoping everything that plugs into this functionality works.

A

Now it is a debated topic and there are a couple of people in my mind so when it comes to unit testing, so there are the enlightened that have accepted it the one way, those who have not yet been convinced and those who cannot be saved. Unfortunately,.

A

Okay, so the good and the bad of unit testing, so it's great at regression management, especially we knew a couple of months down the line. Your code bases grow into an enormous unhand, Louisville size, you're, adding a feature and, unfortunately, something breaks. This is where unit tests comes in really handy, it'll tell you instantly that you've screwed something up, and you need to fix that. Also, it's an excellent explanation of complex code, especially if you follow the format of describe and its statements.

A

If you're looking at a weird piece of functionality, just kind of want to understand, if you put something in what does it give you out, this should help a lot like it should give you four. If you put in five, unless you know it is one ultimately something like that. Obviously it's a very simple example, but proves the point on the list and it helps tremendously in continuous integration.

A

So if your goal is to deploy multiple times for a week or as quickly as possible, then this helps as an extra check just sanity check before you deploy to make sure all of your stuff is still working. Now the bad is the bit more obvious parts which deters a lot of people from seeing the value in unit testing, as it takes a lot of time to write.

A

It can easily double your development time if you're not used to writing tests or if there are complex pieces of code to test, then it also provides no short-term gain.

A

The most gain you're gonna get out of unit tests is a few months along the line when you're either introducing people to your code base, and they can get an easier few for your functionality or you're, adding new functions and making sure that none of the old functionality breaks and the last thing- and this is probably the biggest flaw- interesting, orderly flow, but the biggest drawback of it is. It provides no direct benefits. Your client indirectly is for making sure that nothing breaks, but unfortunately we cannot claim that it gives anything directly.

A

So some tips to start on that. If you have a large code base, you want to introduce unit testing start by covering the new stuff make sure that whatever functionality you add is covered, then, secondly, adding going systematically to cover your old code with tests. Then the third one is to set up a social contract. Now a social contract is almost like a uniform decision of what the team values and usually this is set up with meetings, so you'd go into a meeting.

A

I would say, I think it's very important for us to cover everything in unit tests. I try to convince everyone once we are in unison, we're like okay, yeah, let's give it a try. We come back in two weeks, almost like a retrospective on our social contract. If this does work short, we continue with it. If it doesn't, we can revise and like maybe we shouldn't cover everything because I spent a week covering a function that was very simple to just see what it does and it was complex to test.

A

So we should cover everything or we should give a good reason why we're not going to and the social contract directly leads into creating a good good culture that values unit tests and pretty much anything else that you put into the soldier contracts and you've got pretty much a all-around. Yes from your dev team, then now look for the conclusion, so I think code quality is very integral to every coding environment. It ensures the longevity of your codebase. Definitely then changing codes.

A

It takes time in iterations, just like everything in agile you kind of need to work at it. It's not going to work from the first time and you're, probably gonna struggle for like the first two months or so, but it'll get better and, lastly, I think. If you have to choose between code quality code quality tools, I would go code reviews over unit tests every day.

A

It provides the most benefit and growth to your team and provides the most total benefit right now, whereas unit tests will provide a long down the line and usually when you're choosing between tools, you don't have the time to spare. Okay. Go! That's pretty much it thanks.