We've created a new screencast outlining some of the best practices that apply to performing code reviews, and how Upsource can help apply those best practices. In this blog post we've also transcribed the content, and have provided links to further information. https://www.youtube.com/embed/EjwD7Pi7J_0 (more…)

We've previously covered at What to Look for in Java 8 Code, now Java is moving faster than ever it's time to do an update and cover what to look for in Java 9 code. While Java 9 has even now been replaced with Java 10, and Java 11 in coming in September, these Java 9 features are, of course, available in Java 10 and 11. If your application is using any version later than Java 8 you may benefit from these tips. (more…)

Code review like no other development practice relies on humans being efficient. And for most of us to achieve that, it's important to have our tasks well organized and our time well planned. Upsource takes care of a lot of things for you without any need to configure anything. For example, if you have a branch review, it'll automatically add new revisions to it. It'll promptly notify you about things that require your attention. It keeps track of which changes you have seen, and which you haven't so that you only need to review those you haven't seen. With some configuration required

The last three posts on code review workflows show that there's more than one way to do a code review, and that the approach you take will depend upon what you want to achieve with your reviews and the type of team you're working with. In this post, we'll cover how Upsource aims to make your workflow, whatever it looks like, simpler by automating as much of it as possible. We'll show the types of things that can be easily automated, when this might be useful, and show how to achieve it. Automatically Create Reviews If your workflow is predictable in who reviews code, you don't need to man

In the last two posts we talked a bit about how effective those approaches are for the author to learn and improve, because those two approaches focus on getting the code correct. The Design Evolution approach additionally mentions the value of the whole team seeing the evolution of the code. This third approach for code reviews puts learning at the centre of the process — the purpose is not to check if the code is correct, but to share with other developers what changes have been made. In this example, I'm assuming a slightly different approach to development. This team develops against

In the last post we covered a review process where the code review is performed after all the code is written with the goal of approving the suggested changes. If getting the design right is important to your team, then a collaborative and iterative approach may be appropriate — the code can be checked frequently while it's being built, so design feedback comes at the right time. In this example, I'm going to assume the team works using feature branches. As with anything, this approach has its supporters and detractors, but it's a reasonable model to showcase iterative code reviews. The

We've talked a lot about what to look for in a Code Review, but we haven't covered the process at all. There are many different reasons to perform code reviews in your team or organisation, and the process you choose should be driven by what you're trying to achieve with the reviews. The first example we're going to explore is Code Review as a Gateway. In this process, a developer picks up or is assigned a task, implements the code to the best of his/her ability, and when s/he's "finished", submits it for review. The reviewer checks the code and, if everything is OK, the code is merged into

In earlier blog posts we've talked about general things to look for during a code review. Recently I've been working a lot with Java 8, and I'm starting to have some opinions on what modern Java code should look like.  I've written about some of my Top Tips from an IntelliJ IDEA point of view, but I'd like to share these and more in the form of feedback you could give during a review of Java 8 code. Just a quick note on the screenshots in this post: I'm (mostly) using the single page diff that's the default view in an Upsource review (with white-space changes turned off). Code with a red ba

Code review workflows are as diverse as teams that use them. Some teams are flexible and review only certain commits as they see fit, others have more formal criteria of what should be reviewed, by whom, and how the outcome of the code review should affect the development process. For example, there are teams that want to make sure all commits are reviewed by at least three team members. Some teams may have dedicated team members whose approval is crucial – changes won't get merged into main branch until approved by all. Upsource lets you make your code reviews more efficient by allowing y

Last year we published a series of blog posts written by talented Trisha Gee attempting to answer questions like: What should we look for in a code review? What kind of questions we should ask ourselves as reviewers? What kind of problems are worth our time? Given how vast is the topic, we've barely scratched the surface of it, but still these posts proved to be interesting and helpful to many. The series grew over time, and we've decided to provide a more convenient way to access all the articles at once. Now all the useful advice we've collected is available free of charge as a small boo

We’ve had two themes running through the articles on what to look for in a code review: Lots of what we’re tempted to look for can (and should) be automated Humans are good at checking things computers can not. In this final post in the series, we’re going to look at the grey area in between - we’re going to look at how the features in Upsource can make your job as a human code reviewer easier. As a developer, code reviews can sometimes be a frustrating process - you’re used to all the power of your IDE, yet when you open up a set of changes in your code review tool you can't lever

This is part 6 of 6 posts on what to look for in a code review. See previous posts from the series. How much work you do building a secure, robust system is like anything else on your project - it depends upon the project itself, where it’s running, who’s using it, what data it has access to, etc. Often, if our team doesn't have access to security experts, we go too far in one direction or the other: either we don’t pay enough attention to security issues; or we go through some compliance checklist and try to address everything in some 20 page document filled with potential issues. As us