JavaRush /Java Blog /Random EN /Coffee break #38. What is a code review and why is it nee...

Coffee break #38. What is a code review and why is it needed? Imposter syndrome is a developer's best friend

Published in the Random EN group

What is a code review and why is it needed?

Source: DZone Starting a startup is difficult, but writing software for it is no easier. For software to work well, you need good code. But how can you be sure your code is really good? While working with client code, we discovered that many freelance developers and even IT companies ignore code reviews. Well, since our team considers code review a standard step of work, we decided to explain our point of view. Coffee break #38.  What is a code review and why is it needed?  Imposter syndrome is a developer's best friend - 1So let's start with some basic terminology.

What is a code review?

It is a systematic examination of software source code to find errors and evaluate quality. A code review consists of the following steps:
  • Determining the most effective ways to complete a task;
  • Search for logical errors;
  • Search for the most common vulnerabilities;
  • Malware detection is a special type of code inspection to look for suspicious pieces of code or search for and any malware integrated into the software.

Why do you need a code review?

There are several reasons why code review is considered a necessary part of development. The first reason is risk reduction. Let's say you have software written by a freelancer or an agency, but you are not sure about the quality of the work because even good developers can miss something. So double-checking is always a good idea. Moreover, by working together to learn the code, each team member can come up with smarter solutions that will improve the overall performance of the project. The main thing to remember about code reviews is that they should be done BEFORE your new development team takes on the code base or project. A code review before launching a project gives your team the opportunity to review it and determine the quality of the code and whether improvements are needed.

Guide to Code Review

Based on our experience, we decided to prepare a short guide for developers who are going to check the source code of their projects.
Divide code reviews into time intervals
Don't try to analyze the entire project at once. Experts advise not to review more than 400 lines of code at once. Moreover, a one-time check should take no more than an hour. Humans cannot efficiently process this amount of information, especially over long periods of time. When you exceed this mark, the ability to detect errors decreases markedly, so you may miss some important errors.
Ask your teammates for help
One head it's good, but two better. You might be surprised how much the quality of your review will improve if you share this process with someone else. We're used to doing collaborative code reviews using Atlassian's Crucible . This tool allows you to assign additional reviewers, discuss selected lines of source code, files, or an entire set of changes. Collaborative code review not only improves the software, but also improves the team's competency by sharing knowledge through discussion.
Recording indicators
Before the review begins, the team should set precise goals, such as “cut the defect rate in half.” The goal of “find more bugs” is too abstract and therefore impossible to achieve. During the review, record indicators such as the speed of the check, the number of errors found per hour, and the average number of errors per line of code. Constantly monitoring review results will show you a real picture of internal processes.
Keep a positive attitude
Code reviews can sometimes worsen relationships within a team. Nobody likes to be criticized, so it is very important to maintain a friendly atmosphere unless you want your colleagues to lose motivation. Instead of viewing each bug negatively, think of it as a new opportunity to improve the quality of your code overall.
Set up the error correction process
So your team has completed the code review, but what about fixing any bugs that were found? It was a surprise for us to learn that not all development teams have an established method for correcting the errors found. Fortunately, we are collectively working not only to find errors, but also to correct them. All bugs are discussed with the creator (except when we are reviewing another team's code) and all changes are always approved before being pushed to source.

Summarizing

Code review should be an important process in any development company as it helps maintain high quality coding standards. Working together on code reviews brings the team together and provides an opportunity to share knowledge and experience within the company. So whether you're running a startup or handing over a project to another team, always do a code review to ensure your software is of the best quality.

Imposter syndrome is a developer's best friend

Source: Catalins.tech After reading the title, you might think there is something wrong with me. But I’ll say it again: impostor syndrome is a developer’s best friend if channeled in the right direction. I also believe that impostor syndrome is so widespread in software development because of the sheer amount of knowledge you must have and the constant change in tools and programming languages. Coffee break #38.  What is a code review and why is it needed?  Imposter syndrome is a developer's best friend - 2The programming language and tools you use today may be out of date within a year. This means that you will again have to “start from scratch” to some extent. Software development is a very dynamic environment in which you need to constantly learn. But, despite the difficulties, you can get used to them. Thus, it is almost impossible to get rid of impostor syndrome. Why not then learn to live with it?

Most of us have it

Let me tell you something else. Almost all of us suffer from impostor syndrome. There is always someone better than us. There is always something we don't know. There's always something to learn. Every day a new tool comes out. From time to time, a new technology or programming language appears. You will never be able to learn it all. Trying to keep up is also very difficult. And this is how the syndrome appears. You start asking yourself questions: “Will I ever be able to do this?”, “Will I ever be able to do x, y, z?”, “Will I recognize x, y, z technologies? ", "What if I'm an impostor?", and the list goes on. The answer is yes, yes and yes. By the way, impostor syndrome is worse for those beginners who feel that they will never succeed in this field. I went through this too. You can overcome the syndrome with hard work.

Imagine

You are not the only one asking yourself these questions. Your work colleague has the same problems. The developer you follow on Twitter also has similar questions. And a video blogger with 50,000 subscribers. And these questions also appear in front of me, although I have a job and everything is fine. Questions are not only bothering you. Imposter syndrome is part of our profession. Of course, some people deal with it better, so it's not so obvious that they have problems too. But believe me: almost all of us have them.

What to do?

First of all, you must understand that impostor syndrome can become your best friend. After all, he pushes you to become better. Feeling like you're not cut out for the industry, or that you don't know much, can be an incentive to learn more. As a result, you become better every day. I use impostor syndrome as fuel, as motivation to become a better developer, and it works very well. But be careful—it can quickly push you toward burnout. Believe me, you don't need this. Whenever questions and irrational thoughts creep into your head, REMEMBER that all developers suffer from the same syndrome. REMEMBER that there is always a better developer than you. But also REMEMBER that there is always a developer who is worse than you. REMEMBER that you can never know everything, and that's okay. You only need to know a few tools that are relevant to your job. With persistence, you can become a good developer. Do you think you will become the best programmer? Most likely no. Will you work for Amazon/Facebook/Google/Apple? Probably not either. Will you earn millions? Hardly. But you know what? This is fine. You don't need to do any of these things to become a good developer. Because in reality, most of us never achieve all of these goals.

Remember

  1. Almost all of us have impostor syndrome.
  2. You can achieve success in this industry through your perseverance.
  3. You will never know everything, and that's okay.
  4. There are always better developers than you, but there are also worse developers than you.
  5. You don't have to be a superstar programmer. It is enough to be good at your job.
Comments
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION