Serialization with System.Text.Json
Find out how to efficiently serialize JSON documents with System.Text.Json.
Should everything be code reviewed?
An issue that I haven’t seen addressed in depth in is whether you should review every commit to your code base or only aim to cover critical parts of your application. As usual, there isn’t a single answer to the question, and there are advantages (and disadvantages) to both. The answer will often depend on your team’s context, so let’s dive right in to see if we can make some decisions on when to use a certain methodology over another.
Three ways to conduct code reviews
There are two major schools of thought when it comes to how best to perform a code review. The first and simplest strategy is to sit down with a colleague, go through the code together, and discuss the finer points of programming. The other, less interactive way, is to use one of many tools available on the market to facilitate the discussion. But what is the best way to maximize value, improve the development skills of your team and promote collaboration? As with most things, the answer is usually somewhere in the middle.
Reviewing code you’re not familiar with
We’ve all had to do code reviews on bits of code we weren’t very familiar with. Whether it’s part of the application you haven’t worked on before or a new hire who’s looking at the code-base for the first time, it’s never obvious what to look for, how to determine if the implementation details are bug-free, or how in-depth you should go. The natural instinct, at least for me, is to gloss over the higher-level concepts and look only for obvious mistakes in the implementation details. So how do you get up to speed quickly, figure out what needs attention and doesn’t, and find potential issues with the implementation? As it turns out, a lot of it relies on what the person creating the code review makes available to you as the reviewer.
