How To Do a Code Review And How To Pass a Code Review

Oleksandr — Thu, 02 Apr 2020 18:12:46 +0000

Well, ok, so you know what a Code Review is and what is the purpose to do it, right?

Code Review is the process where developers reviewing each other`s code to detect misconceptions and potential issues before merging it into a stable codebase. The main goal of Code Reviews is to find quality issues in the reviewed code. Other goals which are also reached by performing these reviews are:

Improved code quality
Keep consistency in your projects
Finding bugs
Creating a sense of mutual responsibility
Finding way better solutions to problems

Code Reviews are a great way for teams to keep their software maintainable and also find bugs before they make it into production. First of all, we have to remember that code review is not judging or reviewing a person's ability to code.

Before creating a merge request do the code review of your own code it will save your time fixing it later and it also will save the time of the person who's supposed to review your code.
A shortlist with questions to ask yourself before sending your code to review:

Did I implement the task correctly?
Did I cover the code by tests?
Is the code style standards followed?
Is logic in the code I wrote could be simplified?
Is the method/variable/class name is understandable?

Recommendations on writing code that easy to review:

Make small iterative changes
Link to documentation
Think about the readability of your diff
Don’t refactor in addition to new changes.
Check that your PR doesn’t have unnecessary changes or unrelated files.
each PR should be one logical unit of work

I believe that Code Review Principles and Best Practices should be shared within your team before you start doing code review.
Be friendly and make your comments precise but as short as possible. Make sure that it is about the Code and not about the Author. Avoid possession words like your, mine, my, they are easy to misinterpret and it really should be about the code. Make it clear if your comment is a request for change or an opinion, on which you probably need to discuss.

A shortlist with questions to ask yourself while reviewing the code:

Have I read the ticket description? Is the code cover the task?
Could the logic in the code be simplified?
Is the code style standard followed?
Why did this person write this code the way they did?

Recommendations before writing comments on code:

Put yourself in the other person’s shoes.
Listen to hear what’s actually being said.
Let go of what you think the outcome should be.
In your comments try to avoid phrases that could hurt the author.

Conclusion:
Most importantly of all, the goal of a code review is to have the code pass the review, and make it into production. Code under review is usually code that’s not being used, and code that’s not being used is not adding any value to the application or the users.
Write a good code is hard and review a bad one is even worse. Let`s do our lives easier and spend some time reviewing our own code before sending a merge request.

How to apply The Scientific Method in Software Development

Oleksandr — Fri, 21 Jun 2019 15:48:26 +0000

Day by day we as developers facing hundreds of technical issues that we have to solve. And, as you know, each of them requires its own solution, but the algorithm to solve an abstract issue is already has been determined many years ago in other science in philosophy. I am talking about the Scientific Method.

The scientific method is a systematic way of learning about the world around us and answering questions. The key difference between the scientific method and other ways of acquiring knowledge are forming a hypothesis and then testing it with an experiment.

The amount of steps in The Scientific Method is varied, but 6 general steps work for me.

Purpose
Research
Hypothesis
Experiment
Analysis
Conclusion

I will explain them step by step.

Purpose / Problem / Question

The easiest and most important as well task is to understand what is the issue you working on and what is the purpose to fix it. There was a lot of cases in my practice that if I dig deep enough into the issue I understood the there was no problem or the problem was diametrically different from the initial description.

Research

Conduct background research. Scroll to the bottom of articles to check the references. Check the author, check the publish date it is extremely important in the modern era where updates coming monthly. Investigate the code around, check the author and commit dates, check attached task and how the feature should work. If after all that you have questions contact the author if possible. Investigate tests if you have such.

Hypothesis

Propose a hypothesis. This is a sort of educated guess about what you expect. It is a statement used to predict the outcome of an experiment.

Experiment

Design and perform an experiment to test your hypothesis. The easiest and most appropriate way to do it is to write a test that detects the issue. While writing tests check only one variable, make them as smaller as you can. In such a way, you could be safe and sure what exactly you test.
Build a test project where you can implement a feature from scratch if possible.

Analysis

Record observations and analyze what the data means. Try to understand what is the key reason for the issue and how it could be prevented.

Conclusion

The result of the analysis should be described in related ticked and discussed with the team to exclude the possibility of appearance such in the feature.

You probably noticed that The Scientific method is a perfect example of an algorithm and there is no surprise that it was inherited by dozens of other methods. First came to mind is Red-Green-Refactoring method by Robert C. Martin and Observe-Test-Analyze-Repeat method for QA.

Forem: Oleksandr