 In an amazing team, the only argument we had had was about merging source code directly to the main development branch. Actually, this is not my first time in Singapore. I was here in January and I really liked the place. And I was presenting a topic here about iOS security basics. And back then I started a habit. Every time I present a topic in a certain country, I wanted to introduce myself in the language of that country. And actually, last time I introduced myself in Chinese, which sounded, Ni ha, wu zi yao machi, wu shi chong, Poland. And this time I would like to add another language to my list, and it will be Bahasa Malaya. Hello, nama saya machi, saya berasa dati poland. And for those of you who don't speak any of those languages, hi, my name is Machi, and I come from Poland. And if you want to know where the Poland is, it's a country in Europe. It borders with Germany. And it takes around 15 hours by an airplane to get here to Singapore. I am also an iOS programmer, and I run a blog with my friends. It's called Swiftin.io. And today I would like to present you the importance of code review. Why is that? It is because I've done hundreds of reviews for the past years, and I have a bit of experience with that. And it's just important. And you will get to the point why it's important for me. I would like to start this presentation with a real-life example of reviews. In Poland, I am interested in music, so in Poland it connected me with my friends. I have a band over there, and it's called Admin Admin. You know, just like a usual username and password to the majority of informatics systems. And this is a picture showing our band on one of the performances. But of course, before every performance, musicians rehearse their performances, their pieces of music. So to let you experience better what I mean, I will just bring out my instrument. And this is what actually musicians do before performances. They go to the place of their rehearsal in a certain hour. They pick up their instruments. They attach some fancy pieces of equipment. This actually is a tuner, so I will try to tune it up. I hope it will take less than 30 minutes. Maybe. So actually rehearsing for musicians is quite important because they have to know that their pieces, the sound that goes from their instrument actually creates a perfect harmony. They also try to assess some areas for improvement in their play. It's actually hard to tune it and speak simultaneously. I wasn't prepared for that. I should have done it before the presentation. Cool. So let's say it's more or less in tune. So musicians just go to the place of the rehearsal. They sit in a perfect circle so that everyone see each other faces and can hear each other instruments. And once they're ready, they just start to play, right? Yeah, let's say it was supposed to be more or less like this. So actually musicians during their rehearsals review their music. They try to point out places in a play that are good enough and they point out places that should be improved. Yeah, I will practice even more before next performance. So look what you were just able to do. You were able to review my piece of music which wasn't good enough so I can gather your feedback after the presentation but I know that I should practice more before next performance. So actually musicians review their work, rehearse their work. Just as programmers should review their code, right? And this is Yuku. So we should review code but what actually is a code review? So code review is a process of finding and fixing mistakes overlooked during an initial phase of development, of software development. It's intended to enhance quality of the source code and to improve skills of each individual in a development team. We can distinguish three types of code reviews. First of them is per programming and actually this is the type of code reviews we actually do at the place I work at the moment and I pair usually with Tai who is over there. Tai, you can wave your hand if you're brave. I work with him and it's a really nice experience because we can show our ideas, we can discuss the code we're currently developing and we can bring to the source code base everything best that we can, right? And it looks like that. We have one computer to set the keyboard and mouse switch in Perse and develop source code and we are reviewing our work because we can point out some places that need our work and what we can discuss everything we do. So there is also a formal inspection, another type of code review and formal inspection usually uses an online tool that can display differences provided to the source code so we can attach comments to every place in the code we can discuss it also with other team members and they can share their thoughts about our work. And another type of code review is something that I like I call show me your code review and it happens when somebody has a problem in a team and it comes here or here, they come to me and they say you know, Mati, I don't know how to solve that problem and we discuss it a little bit and then I just tell them yeah, you know what, just show me your code. So I just go to their computer, they display their code and I can look through it and review their work point out some ideas for improvements and solutions to their problems. There are three important aspects connected to code reviews and those are checklists, ego effect and positive culture and those are very important when introducing such processes like code review in your workplace, at your workplace. So checklists, you know, I like music and maybe one day I will become a musician and musicians before performances tend to have high demands for organizers of the concert. So for example when, I don't know, Michael Jackson if Michael Jackson came to Singapore to play a concert probably he would demand, I don't know, some fancy pieces of furniture on the backstage, drinks and nice ladies, whatever, right? So high demands are something that musicians want to have before concerts and actually there was one band that started those high demands back then but for different reasons. So there was this band which before every concert would give checklists to the organizers of things that should be on the backstage and this checklist contained very different crazy stuff. For example somewhere at the bottom of the list one of the items would say that put a bowl full of red candies somewhere here on the backstage and give, I don't know, maybe a poster of Michael Jackson somewhere on the left on the backstage when musicians entered the backstage and was able to see all of those items on the backstage they knew that somebody did the effort of going through all of the items on the list and this list actually contained some tasks related to security because this list was meant to secure the backstage for a band and actually programmers can also be secured with this checklist when doing some code reviews because checklists contain items that should be checked during a review. Another important aspect of code review is ego effect and this is something that drives us to write as best code as we possibly can because when we know that somebody will be looking at our code we will just write good code no shitty code will happen and we should have a positive culture in the company and positive culture of code review means that finding mistakes is welcomed positively and somebody is punished for either doing a mistake or finding a mistake but positive culture means also that we can prize our peers for a job well done at our place when Ty writes good code I will just say wow mate this is an amazing piece of code we should be solving those kinds of problems in that way from now on and this is a positive culture of code review so how to introduce those processes at work I am an electronics and telecommunications graduate and when I started iOS development a few years ago I didn't know what unit testing and code reviews were because those are subjects that are not thought during my field of study and unit tests at my workplace looked like that we had an Excel file and we just copy and pasted QA quality assurance test cases we run through them manually filled in Excel sheet and those are our unit tests but we knew at that time that we were lacking some experience in area of unit testing so we invited an external trainer to teach us how to do unit testing properly and after that training I felt very secure I knew how to unit test properly and it paid off for me in the future because one day I received a coding task from one of the companies I was applying for a job and the coding task said that I should develop an application that has this functionality X and I would get extra points for writing some unit tests but the most surprising thing about this coding task was that I was supposed to send the results back via a pull request and at that time it was something for me it was something right like pull what? what's a pull request? and for those of you who use GitFlow it's obvious when you are using Git repository here to something called GitFlow and GitFlow assumes that you have the main development branch you apply some commits with every piece of work you do over there but you can also have per feature functionality branches so you just divert from the main branch you commit your work on a certain feature on this branch and once you think your job is ready you create a pull request and it really is a call for your colleagues to review your work and they can use such tools as GitHub to commend your work to point out some pieces that can be improved or they can use this tool to say that your job is so cool that you don't have to do anything but sometimes you have to work again rework your work commit some pieces of code and somebody finally approves your pull request and it can be merged to the main development branch and back then it felt really good to me because during this pull request and this coding task I gathered a lot of feedback about my code and a lot of experience so I created a vision that I want to share with developers around the world whenever I am wherever I am so I think that world would be a better place if every software developer used unit testing and code review and actually in iOS development those two were a standard not an opt-in feature and I wanted to introduce code review to my work as well, to my team because we didn't have such processes unfortunately when you want to introduce your vision, your dream to your team members you will find some obstacles especially from project managers so I went to my project manager and I said I want to do this code review thing but he answered that no, no, Maciej, you know we have only three months and three developers to deliver this product, right? This is the usual, it was, the usual estimate at my previous workplace OK, PM, but you know we can just have one hour for code review and we'll avoid searching a bag for one week OK, but then he answered no, Maciej, you know we only have fire and forget projects and this slogan for us meant that once we ship our products we never get back to the source code so there is no need for code reviews and of course not for unit testing, right? We did a lot of conferencing apps so those were one event, one, one those were applications that were used for one or two days I work for a pharmaceutical company, by the way but I replied that we should perceive those projects as review and learn because we can gather feedback about our code and we can apply solutions to certain problems in next projects, right? But of course the PM would answer that there is no time for doing it I would say there's no try we just should do it just do it like AdWords used to say but of course it takes too much time the PM replies but it's really 60 minutes for a code review too much is it too long? really do you know how much it takes to deliver a drug to the shelves of the pharmacy from a molecule, from the time it is invented to the time it is available for patients is it one year? three years? actually on average it takes 10 years for a drug to be available for patients for people to be used and it's because every drug is a subject to clinical trials there is an entity in the US called FDA Food and Drug Administration and it has some regulations for drugs every drug has to be tested that their properties don't harm other people that drug actually cures people and we have three clinical phases three phases of clinical trials each of them takes a few years so this is why this process is so long and actually also the software that is used in manufacturing of those drugs and in clinical trials needs to be validated software validation is a process of assessing pieces of code and this process assumes that unit testing and code reviews are performed during the development of the source code this is why code reviews and unit testing is an important subject for pharmaceutical companies as well so I was talking about this FDA company sorry FDA entity in the US and actually there is another there was one company in the US that had problems with their regulations it was called 23andMe and they produced DNA collection kits actually when they kicked off their business they had to seize selling those DNA collection kits because they wasn't able to fulfill some regulations and I received one of their kits collection kits and I was flicking through their website searching for my DNA reports so I could know from which parts of the world my DNA comes from and I noticed this one line really was amazing for me they also do some researches and they publish outcomes of those researchers in a peer-reviewed academic journals and I said just wow even they use peer-reviews right they review their work and actually this is also what we do in Swifting IO every article we write is created on a separate branch when they get repository before being published our team members assess our articles and we provide some improvements and that stuff to articles and once somebody thinks it's ready he or she can publish an article of course not everyone does it world isn't ideal so my question is should we review probably not everyone in this room has a software that on which one's life depends probably not everyone works on a software of an airplane not everyone deals with billions life billions lines of code and probably not probably no one here works on a project that tries to send human into space right so why the hell should we review I think the bottom line of this presentation is because with code reviews we can learn from each other every individual in this room has different experience and we can share our ideas we can learn from each other we can teach others we can improve our work source code and that's the bottom line I think and if we ever happen to work on a project on which one's life depends we will be ready because good habits will stay with us and if you are dreamers just like I am maybe and if you want to introduce such practices in your work maybe you can do what I did once so I started actually with a prank I did to my colleagues I worked in my opinion on an important feature in one of our applications I wanted this one to be checked so I created my work on a separate branch and the prank was about sending a pull request from my colleagues and I asked them to review my work and you can do the same thing and maybe one day those code review practices will become a standard in your team, in your company just as it was for my team and maybe one day the only argument you will have with your in your team will be about merging source code directly to the main development branch and just guys review all the things thanks oh and by the way this presentation was also reviewed dozens of times do you have any questions for you? yes please so you sit down like you need just one hour to review right? yeah so basically just one hour not a long time so basically I think you just review the spawn thing yeah of course it depends case by case but when you review somebody's work when you work on one subject you probably cannot focus for more than one hour or 90 minutes at most on a certain topic so actually this one hour is one hour per day this is what we yeah we were spending on code reviews at the previous workplace explore the use of static code analysis yeah a bit we were using C-Lang so built in Xcode static code analyzer and we also at my previous company we were using a thing called okay just forget the name but it wasn't good enough but there's actually one that you can use for your open source projects on GitHub it's called CodeBeat and you can just I think you can link your GitHub account to CodeBeat and put links to your public repositories over there and they can point out some actually they can put out some things that can be improved in your code they provide some metrics for your code and it's three for open source projects they also have some plans for enterprises so you can use them in your company so what are the kind of things you learn from the code review oh there are many yeah programming style usually it's good when you work in a team is probably the best thing is when you can learn from seniors under a style of work and it's also good that you can establish certain rules, certain solutions to basic problems so use the same coding style or solving style certain problems I think those are the most important things especially at the beginning of the project when for example in our previous company we tend to switch teams so there wasn't many times when we worked with the same people and when you gather different people together they have to start working together and it's difficult at the beginning so to get to know each other to develop a style for a code don't kill me don't kill me with another question because last time Dominik asked me a question I didn't know how to answer it play again I don't know man maybe ok so let's call it a day thank you very much