 We're going to talk about code review. Go ahead and start leaving. That's fine. Hi, this is me with a lot less hair and a hammy programmer cliche. It's a little bit about me. I'm a very long time WordPress user. I work at Automatic on the WordPress.com VIP team. I can kind of code with some help on a good day. So I need code review a lot. But all of you just now are probably thinking, why do you care so much about code review? I tried to answer that. And why should I? Again, I work at WordPress.com VIP, where code review is a way of life. So quick thing, what is WordPress.com VIP? So you can understand the point of view here. You all know about WordPress.com. WordPress.com is the largest single WordPress installation in the world. It serves billions of page views per month and has millions of new posts per month, many millions of sites and blogs. WordPress.com VIP is a little bit different from WordPress as you would think it, because we're enterprise level WordPress hosting on WordPress.com itself. VIP does two and a half billion page views a month and has very good uptime and an average response time of 350. You may know some of our clients and their sites. Some brief bits about the guts of WordPress.com VIP. Sites run on WordPress.com sites just like yours and mine. If you start up a free WordPress.com blog, it's exactly the same infrastructure. We give our clients a custom server and repo for their themes. And they commit changes to the theme directly to that directory on WordPress.com. A problem with a VIP site can affect other VIP sites and can even affect more of the WordPress.com network. So because of this, we review all code before we deploy it for obvious reasons. It's a culture of code review. But why should you do this code review thing? Well, let's talk about it with some basic reasons. You want safe code. So you want to find cross-site scripting, unescaped, unsanitized code. You want your code to be scalable. So you want to look for things like smart queries, cache functions, you want dry code. You want readable code. So you want code that follows coding standards, whitespace, formatting, those kinds of things. So everybody can work on the same code base. And the last thing is you learn a lot when you review code and when you have your code reviewed. As we say in our VIP documentation, we don't review to add more time to or delay your launch schedules. We do code reviews to help you launch successfully. So what do you look for when you review code? Let's do just a basic overview. Things like validation, sanitizing, and escaping. You're looking for cross-site scripting and JavaScript. You're looking for things like uncached WordPress functions that could be done better with, say, helper functions that are cached. You're looking for smart fetching of remote data, so you're not going and grabbing everything all the time. You are looking for terrifying queries that set databases on fire, which is very easy to do, as many of you in this room probably know. And you're looking for, oh, I missed one, didn't I? Yes, I did. And you're looking for best practices and WordPress coding standards. And the last thing you're looking for are typos because a typo can kill a site. So how do you do code review? Now that I've convinced you and you are absolutely sure that you need to embrace code review, how do you do it? Two ways. Automatic code review, one T, not two. Things like PHP code sniffer with WordPress coding standards rules that are out there. VIP quick start or the VIP scanner, which are tools that we use for VIP sites to show them blockers or things that we might think need to be worked on. Continuous integration testing, which I'm sure all of you are using, things like Travis and the WP enforcer. Other option, manual code review, which I highly recommend. So let's take a little sidetrack here and talk about the WordPress.com VIP code review process. All right, as I mentioned before, I'm on the VIP team. We use this thing that we call the deploy queue, which sadly I cannot really show you because I can't show it to you without you seeing client code and I can't do that. So here's the basic gist of how it works. Client commits a change to the repository. The change set is displayed in a special view that we have on our side that contains the committed self, including the diff, the revision number, repository data and who committed it. The change log entry for each revision. And then the reviewer takes a look at that and they can either open a ticket to discuss the change and leave notes and talk about ways to improve it or they can deploy or revert the change as they need to. Here's some stats on that. We do this kind of a lot. We've reviewed to date on WordPress.com VIP nine and a half million lines of code. This is a slightly old statistic. This is probably closer to 10 at this point. Over 144,000 individual deploys to all VIP sites combined. And the average time that we have in review that's from commit to deploy is around two hours. And we're talking thousand lines of code or less generally for those reviews. So again, you may be asking, that's awesome. You've got this custom built flow but what can I do to do the same thing? Guess what? How many of you in here use GitHub, right? It's pretty much everybody. Hey, so GitHub does this cool thing. And I actually put these slides together before they introduced their little code review feature which makes this even easier for me because I just say, yo, GitHub has this thing called code review, do it. The humble pull request is your friend. And so somebody submits a pull request and you can take a look at the pull request and diffs and inline comments make code review something that's super easy for everybody to do on a project, right? It's like right there, all the tools are there for you to have these discussions, review code and suggest better ways to do things in your teams. Pull requests are built in code review opportunities. Think of them that way. It's less, hey, here's this thing that I wanna do and more, here's an opportunity for us to learn from each other and to make our code better. So I have another little branch that I wanna talk to, something you may have heard about recently called Calypso which is if you've used the WordPress desktop app or created a post recently on wordpress.com it's a single page JavaScript app that does a whole bunch of API stuff with WordPress. It's very nice. And code review was a major tenet of the Calypso development philosophy. It was a bedrock of how Calypso was built. In the project documentation, code reviews help to keep code quality consistent. They spread ownership of the code and they help every person working on Calypso improve over time. So the same stuff I just talked to you about, it's right there. Some basic points on code review that are in that project documentation. Pull requests are peer reviews that are just waiting to happen. You stay positive when you review the code. Comment on the code, not the person. Don't say you shouldn't have done this. Say here's a better way that we could code this. It's a team effort. You're not trying to put somebody down. You're not trying to make them feel bad about what they've done. You're not shaming them into better code. You're trying to learn from each other. And you have a list of things in the documentation to look for on code review because checklists are your friends. When you're creating a pull request and when you're reviewing and hopefully merging the pull request. Which gets me down to this. Your code and your processes no matter what project you're working on need documentation to have successful code review. If you don't have documentation, you can't agree on these things. Code review will help Calypso be a development success. Andy Petling said code review greatly increased the quality of our code base and helped everyone level up their JavaScript skills. Basic ways to handle manual code review. Get help or requests. I already talked about this. One rule you add to pull requests. No one merges their own PR. Code review, right there. Use the comments, they're a great tool. Line number comments are even better. If you don't use GitHub or a similar tool, diff reviews, just use a good text editor. Pull a diff, take a look at the diff, do a review. WordPress core does this. Code review is already part of something that you use all the time. Core WordPress uses code review and it uses it for everything. There's nothing that gets merged in to core WordPress without a review for very good reasons. It's clutch that code review needs to be part of your developer DNA. Not just something you do occasionally but something that you do all the time. However, you may be thinking if you're sitting in this room and you're not part of a team, I am a solo developer. What can I do? Well, code review is not something that demands that you have a team or more than one developer. One basic thing you can do, sleep on your code. And by this I do not mean print it out and snuggle it. I mean write the code, wait, maybe write your own pull request. The next day take a look at it because I cannot tell you how many times I've tried to fix something and I've gone back to it just 12 hours later and been who was this guy? Coding is you fighting with your former self. Let's be honest. Even 12 to 24 hours later. So ways you can affect solo code review. Create pull requests or diffs of your own code and queue them up for your own review. Don't merge to master production head, whatever you wanna call it, the same day if you can help it. If it's not mission critical, take your time and just look at it with fresh eyes later. Maybe with some sleep, we all know how that goes. Clear your mental context between writing your code and reviewing your code. Write the change you want, go do something else for a couple of hours. It's like I said, 12 hours, just some sleep makes all the difference. Or maybe go read something, right? Do something else. Eat lunch, code before lunch, review after lunch. Even that amount of time, you might find something. And you can use those automatic code review tools to get you part of the way there. They'll give you obvious things or automatic things. There's no discernment with those tools. It just gives you a raw list of things but it gives you a good starting point for reviewing your own code. Everyone can do code review, including you and me. So you may ask, when is it appropriate not to do code review? I'm going to try to convince you, never. Right? If something's broken, then maybe not. But you should, if code review is part of your developer DNA, if it's part of your culture, of your team, you should be doing code review all the time on everything you do. Because review code is better code. Thank you. I will have this URL up probably after lunch and it's just ryanmarkle.com slash WCUS 2016. I'll download of these slides and the download of the slides will include my presenter notes, which I've been using as we talk here. Some links to the resources I listed so you're not just taking a picture of the screen and doing some Google searches. I'll give you some places to go for that. And there's a contact form right there on the page of my presentation so you can ask me if you have any questions. And of course, you know, other blog posts that have almost nothing to do with WordPress that you probably don't want to read. But again, after lunch sometime, I'll have this page up for you and you can go there and look at all the resources that I listed in the presentation. So thanks again.