So, I'm very... It's a pleasure to be here today with you guys. Thank you for all the organization that makes this happen and, definitively, it's an honor to be here today. This is my first time speaking here in Europe, so, it's another memoir, moment in my life and my career. And I hope you guys can enjoy this talk as well.
So, I was already introduced, so I will save you guys from hearing this again. The idea here in this talk is to share with you what I've learned after doing research on ten of the most used JavaScript libraries in GitHub. And I try to structure this in a way that we can basically understand a little bit more about the best practices that these guys have been using when reviewing code. And that is the approach. The idea today is not to go on the features that the libraries have, but instead is to learn more about how they are reviewing the code that are submitted to these repositories.
So, let's move ahead and think a little bit more about the code review process, right? The code review process is basically a simple way for people that are coding every day, right? It's something that is pretty straightforward, but for the people that are in the testing side, sometimes doesn't know exactly how it works. So, first, we have the code that is created. So, the developer goes there and creates a piece of code, or even the testers, depending on how you guys are structuring the way that you produce your test automation code, right? But this is the first part to create a code. Then the person that created this code opened APR. And after opening APR, that's the pull request, basically we have our teammates going there and reviewing this and providing us some perspectives, the views that they have. And then after that, we can, if we have the approve, we can go ahead and merge the code. If not, we need to work on this pull request, or in this piece of code that we are producing, right? The thing is that there is a very, how to say, very important activity that happens during this process that is basically to have these teammates looking at the code and reviewing that. The question is, how do devs do it? And the answer is magic, right? Actually, let me ask you guys that are devs. Tell me what do you have in mind when you are reviewing a code? That's your turn. Yeah, we're doing standards, right? What else? That's a very good question. That's a very good answer as well. Readability. What else? Yeah, if the code does what it should do, right? However, where do these ideas come from? Yeah, experience, right? The way that you do it. There's no, I'm not telling you that everyone does it this way, right? But sometimes we do it from an experience manner, right? Based on our experience. So, it makes us to be, how they say, empirical, right? So, if everyone here raised their hand and shared one thought about how to review, we would be the wisest person in this whole conference, right? There is another way to do it. In software testing, we use a standard called ISO 25010. Have you guys heard about it? Yeah? Raise your hands. Okay, good. Do a wave. We got thumbs up.
Comments