Tips to survive code review for junior software engineer

Tips to survive code review for junior software engineer

Maybe “survive” is a strong word here. But after getting the approval of a hundred-comment Pull Request (PR), you get the relief feeling like you have won a furious battle. Nonetheless, code review is the most effective way for a junior software engineer to learn from the senior ones. It helps you learn the best practices of the team faster. It saves you a lot of time by keeping you from the mistakes that other people have made. It makes you familiar with the codebase. In other words, the process of code review will help you become a senior one someday. But you should not rely too much on other comments and write sloppy, reckless code. That is a sign of irresponsibility and should not be forgiven. Your mentors, the senior ones in the team, have other jobs too and don’t expect them to fix every line of your code. You must put a maximum effort to review the code by yourself before pushing it before the eyes of others. This effort will pay off later. The code you write will become more trustworthy and you will become more proficient. So how to make sure you have reviewed all the things carefully before creating a Pull Request? A suggestion is to go through these five aspects of the code before pushing the button.

Code style and fix things relating to typos

Code style includes things like the format and syntax of the code. Modern IDEs like IntelliJ IDEA, GoLand, Visual Studio Code support automatically code formatting. Similarly, incorrect syntax can be detected at the compiling phase. Although these tools will take a lot of burden off you, they are utilized better when the engineer who uses them knows their rules. There may be many styles and conventions for each language, and for some language, there is a standard one. For example, Python has a well-known coding style named PEP-8. For Golang, you can consult the official code style from Google or the customized Golang style by Uber’s engineers. If you are coding in C++, this Google guide is a must. Or maybe your team has its own code convention. In that case, follow that guide. Read these code styles carefully and apply them to the next project that you write. While IDE helps you a lot with coding styles, there are more elusive typo errors that require a closer look. For example, you can hardcode the wrong path to your folder, missing semicolon in an embedded SQL query or write GET instead of POST. Sooner or later, these errors will expose themselves. But it is better that they are discovered before the code is reviewed.

Clean code

Now, let’s move to the next part: Clean Code. There is a thorough book on this subject with the same name written by the legendary Uncle Robert Martin. Make sure it will be read immediately after you read this post. It must be taken seriously. I remember vividly the moment of revelation when my spaghetti code is split into smaller functions, each function only does one thing well. My thought then was “Wow. Luckily I have read that book”. The book covers a large range of software engineer practices like how to write good functions, how to name things, how to write good unit tests, how to write comments… Read the books, especially the first three chapters and think about them each time you create a new class, write a new function or even when naming or commenting on some things. Another important aspect of clean code is to organize related code into layers. A famous example is the MVC model. For example, all the code that handles the logic of the website should be grouped into a Controller module. The code that reads and saves data to the database needs to be in the Model module. And we put the code of user interface into theView module. By separating code between layers, each layer has an independent role, we will have an easier time modifying code later. Remember that in the team, your code will be read by other engineers, so let’s do a good thing for the world by carefully make your code more readable.

Code logic

The most important thing about good software is that it must works correctly as described here. Your program must follow the logic in the dive-in or the approved specification. How to ensure that the code is correct? Its correctness is often guaranteed by its passing unit tests. It is recommended that unit tests must have at least 70% code coverage. Some companies even require that the coverage is at least 90%.

Improve code’s performance

Donald Knuth has a famous saying that Premature optimization is the root of all evils. It is true that you should not care about the optimization of your code too early. The highest priority is that your code works correctly. But when being confident with the above, you should consider making your code run a little bit faster. Think about the questions like: can I query this database with less database connection? Can I archive the same result of this code with a simpler logic? In many cases, others will point out the bottleneck in your code and you will follow their suggestions. It is okay because you are not expected to know all the tricks to make the code run faster when you are a junior one. But make sure that when some optimizations are trivial enough that you can handle them, carry out that optimization.

Take a careful look at unit tests

Junior software engineers often look down on writing unit tests. After all, how many times in college that you are forced to write unit tests. That bad habit follows them to the earlier stage of their career. But embrace unit tests and it will save you a lot of headaches later. First, make sure that the tests have a high code coverage and handle all the edge cases. Second, don’t just copy and paste the unit tests. You should understand why each test case is needed. Third, like your logic code, the format of the unit tests file must be as clean as possible. Don’t let the beauty of your logic code destroyed by the ugliness of your tests. Following through these tips is not a hundred percent gives you a free-comment PR, but it will enhance your code significantly and give other senior software engineers a happy time to look at your code rather than a duty that they will do everything to avoid. These lessons have been learned the hard way over six months in my first job after college and I would like to share them with you. If you want to make any improvement for the posts, leave a comment below.

Thank you and hope you enjoy it.