 Hello everyone, my name is Seish at the front end at Redmart. So today I would like to talk about code reviews and how to speed up the code review process. So we all know that code reviews are very important. Code reviews, they help us ensure that the code base stays readable, maintainable and consistent. They help in knowledge transfer within the team. They also help in learning. So personally I have learned a lot through just the code reviews. I've learned the existence of new APIs, different ways of solving a problem and so on. They also have so many other benefits. But the thing is code reviews are also very time consuming. So from start to finish they can take anywhere between couple of minutes to hours or even days. So where exactly are we wasting all this time in code reviews? So if you think about code reviews, right? So usually there are two entities here. So there is the submitter and there is the reviewer. Submitter is the developer who is working on a feature or bug fix like price a bunch of code and since that as a pull request to the reviewer. So the reviewer goes through the changes, looks for things to improve and makes the suggestions back to the submitter so this cycle continues. If you think about that, this is not actually very straightforward, right? So this flow is not actually a synchronous thing. So the submitter makes a bunch of changes, he sends that to the reviewer. So the reviewer is like normal developer just like you and me probably working on some other task. So the reviewer has to wait for some time to context switch from the current task to this review and after that is done. So the reviewer goes through the code and there is this huge laundry list of things to review like is the changes consistent with the rest of the code base like format bias, is the changes readable, are there any bugs, are there any browser APIs that we are using that is not implemented in the browsers we support and so many other things. So the reviewer is done, the reviewer has a bunch of situations. For example, let's say that changes contain a method with like 200 lines of lines inside that method. So the reviewer make a suggestion say that just make this method smaller, decompose this into like much smaller methods. One more suggestion would be like so many console logs like in our team like we don't use console logs, just remove that, maybe like magic numbers or there are some like other bugs. So the reviewer sends all these review comments to the submitter. So the submitter is again a normal developer like you and me like and this has been like so many days and the submitter is probably working on something else. So the submitter now has to like context switch from the current task to this review and this cycle continues. So if you think about this, there are like many ways to optimize this process. One good way, if you think about it, if you think about the suggestions that the reviewer made, most of these things are can be found out using just tools like the tools are available, things like how many lines are there in a method using some console log or using magic numbers and stuff like that. So the tools are already available that does that. So if we can just offload these checks to tools. So what happens is the reviewer now can focus only on aspects of code review that are not automatable and the submitter immediately gets feedback. The submitter doesn't have to wait many hours or many days to just get the feedback that there are so many lines in that method, right? So we have a couple of tools already available in the JavaScript review system. So these tools like I'm going to talk about are specific to JavaScript. There are many other tools, like similar tools that exist in other languages that do more or less the same thing. I'm going to talk about Prettier and ESLint. So let's start with Prettier. So Prettier calls it's a opinionated code formatter. So it formats code. So it not only formats JavaScript. It also supports CSS, JSON, TypeScript, SAS, and so many other languages. So the thing about code formatting is that everyone and their cat has different opinions on what is the best format. It's such a divisive thing in the software development community. Spaces versus stack, single codes versus double codes. How do you put the braces, like the same line or different line, where do you put the comma? Like how many should that be a space between the arguments and stuff like that? There's just so many ways you can format the code. And everyone has their own subjective opinion on how to format the code, which is totally fine. But when you're working as a team, right? So the consistency of the code base in the team is far more important than individual preferences. So you have to make sure that the code base as a whole is consistent. So the only way to achieve that is using the automated code formatting tools. So one more thing about formatting is that when you have PRs, and if you don't have these automated tools, like prettier or anything else, what happens is the PRs, they devolve into like nitpick commands. Like nitpick, use space instructive, nitpick, use single codes, instructive, double codes. There's just so many nitpicks in that PRs. It just pollutes the whole PR. And it's just so noisy that you cannot focus on other important things, like finding bugs or finding edge cases in the implementation. So just use some automatic code formatting and just sleep easy. So the next tool we are going to talk about is ESLint. So this is one of my favorite tools. So ESLint is like a static code analyzer. It helps us enforce best practices. And it also finds problematic patterns in code. So ESLint, by default, it comes with a lot of rules. But the best part of ESLint is the community around it. So the community has created custom rules for React, the custom rules for Angular, for Node, for Mocha, and so many other libraries and frameworks. There is even a custom rule that if you define the browsers that you use in a project, let's say Chrome, latest Chrome, latest Safari, latest Firefox, and I11, what it does, it scans through your code base and finds occurrences of APIs that are not implemented in one of these browsers. It's called ESLint plugin compact. Like you can Google that later. One of the other good things about ESLint is the shareable config. Say you're in a company, you have like 50 JavaScript developers. So one day you just get together. Say, okay, let's create a standard coding convention for this company. And you come up with a list of 15 rules that every project in that company should use. It's fine. And one more thing what you can do is you can extend this rule, a company-wide rule, to your teams. Let's say that there are five developers in your team. So all the five developers can sit together and say, okay, we like these 15 rules. We want to follow that. We want to add 10 more rules to that. So the team config extends the company config. It can go even one step beyond. So you have like multiple projects in your team. Like there is a node project, there is a React project. So the node project can have the company config, the team config, and also node.js specific configs rules. Same goes for React. So, and you can even publish this config. You can share this config in NPM. And people from outside the company can actually use that. So there are like many of the configs like Google's config, Airbnb's config, like there is even a config for Redmart. So one of the best cool things about ESLint is the concept of auto-fixing. So most of the other tools like JSLint and JSLint, like they don't, they just tell you the warnings and they don't do anything after that. But in ESLint, some of the rules, they can be auto-fixed. You just have to run ESLint fix, then they just fix most of the rules. So that's very useful when you are actually migrating big code base to ESLint. So these two tools are fine. I mean, you can use them as plugins in your editors. So in Prettier, if you make a change, you can configure the plugin so that if you press save, it automatically reformats as per your config. The same thing can happen for ESLint. If it is auto-fixable, it automatically fixes those rules. If it is not auto-fixable, if there is something, so it just shows some tooltips or some squiggly lines in the editor, it's totally fine. But what if you want other developers, who are not JavaScript developers, maybe Scala or Java developers who occasionally want to contribute to your project? I mean, it happens in your organization. So usually, let's say these developers use WIM or they use Eclipse or whatever and they contribute like maybe once in three months or once in four months. We should actually encourage these kind of contributions. But if you ask them to download some editors, like Atom or VS Code or Sublime, and then ask them to go to that package repository and download A, B, and C plugins, and you have to configure that plugins, like use the checkmarks there, like put this value here. Don't check this checkbox, like remove the checkbox or put some checkbox here, and it has a barrier for their contribution. So what we can do is, like we can harness the power of Git commit hooks. So Git commit hooks, they allow us to run some commands before the Git commit happening. So we can configure Prateon ESLint to run before Git commit. So if the code, the code gets automatically reformatted by Prateon, the code gets automatically fixed by ESLint. If it's not fixable by ESLint, like it throws some errors. For Git commit, I personally use LintStrage. It's a pretty easy to use library. So you just have to install the dependencies and just add this to your package season. That's about it. The Git commit hook is set. So this is how our new development workflow looks like. For developers who have the editor plugins, you make a change. If it goes against the team's coding conventions, the editors throw an error or throw a warning. If it is formatting thing, like Prateon just automatically reformats the whole code on the fly. If you don't have that, the commit hooks catch that. Even if your editor plugins is not properly installed or like if you use item, like you know what I mean, editor plugins break someday and they just work. The other day, so the commit hooks is like a layer that always checks the code before it gets committed. So I also use some CI server here so that it's always runs when you push something to the master. And finally, it gets to the reviewer. So this is how it looks like in editor. So if you use the ESLint recommended config, it disallows console law. So it shows those squiggly lines in the editor. You know that you're getting the fast feedback as long as you type, you get feedback from the editor. If you don't have this, you can have the same thing in the git commit hook. Like I try to add and try to commit and it throws the errors in the before committing and it just aborts the commit. So by offloading these kind of automatable checks to the tools, what happens is for reviewers, they can focus more on things that only humans can do, like finding logical bugs and edge cases. And for submitters, you can give the feedback faster to the submitter. So in the end, what happens is the whole development lifecycle gets shortened and you can release that feature faster. Yep. Hope you found it useful. Thanks again for your time. Okay, thank you. You have time for questions. Okay. So I have a question with you. Yes, sure. Can you give an example of the before and after when you run the feature? It looks prettier, I guess. So I guess to add on to the question as well. In ESLint, you had ESLint fix. Yep. So how is that different from prettier? So, okay. So prettier is only concerned about code formatting. ESLint has some style rules, but you can disable that and just use prettier only for formatting. And ESLint has also things like it detects like cyclomatic complexity and the number of lines. And even it checks whether you're using the Avid keyword when you're using the Async keyword. Things like that. So it has a ton of rules. Just go through the documentation and read through that. So prettier, for your question, it has some configuration. It calls it's opinionated. So it has about like five or six configuration. I don't have a demo, like I don't want to demo. Say for example, you set the max length to 80 characters or something and you have a super lengthy if condition and it just like formats that so that it's like three lines or something. Yeah, something like that. Okay. Okay. Okay. Any more questions? We're here. Anyone else who wants? Nope. Okay. We'll help you. Thanks. Thanks guys. Thanks.