Work Hours
Monday to Friday: 8am – 6pm
Weekend: 10am – 2pm
Understanding Code Reviews, helping Each Other Get Better
Code review is like a team check for computer programs. It’s a moment when your teammates take a close look at the code you wrote and offer advice. However, it’s not just about finding mistakes; it’s about helping each other improve. They discuss how the code looks, its design, and ways to make it better. This collaborative effort makes everyone on the team better at writing code. It’s all about learning and growing together.
Kickstart, the essence of changes before the dive
The initial step is to understand the change itself. This involves checking the task description, unraveling what needs to be altered, and find the reasons behind it. Additionally, try to imagine how you would approach making this change. This straightforward approach ensures we’re well-prepared to assess the code changes effectively.
Essentials, checklist for crafting quality code
A checklist in a code review is a guide that helps us cover all the important aspects of the code. It ensures consistency, helps catch issues early, and promotes a shared understanding within the team. Using a checklist makes our code reviews more effective and collaborative.
This is just an example, every project or team has own priorities while code reviewing. Use it just as a guide and example.
Sealed Classes: Imagine a sealed envelope – once it’s sealed, you can’t change what’s inside. Sealed classes are like that in code. They prevent others from changing or extending them. Using sealed classes keeps things more stable and secure. Also in C# has a little better performance.
Cancellation Tokens for Async Code: Cancellation Tokens are our way of saying, “Hold on, stop that task!” It helps us manage asynchronous tasks more smoothly and stop them when needed.
Handling Privileges and access: Some code needs access to certain things, like mobile device has permissions to access GPS or files. It can be granted or not by user. Same at desktops, you can have access to certain folders or not. We need to be careful and always check and react if we do or do not have permissions.
Code Tests: Testing code is like checking if vegetables are cooked – you stick a fork in, and you know it. Code tests check if our code works as expected. They catch problems before they become big issues, ensuring our code is like a perfectly cooked vegetables – firm and delicious.
Team Principals: Picture this as having a team captain who keeps things in order. In coding, we use same structures and similar code that helps everyone to quick find out in our team shared code. This task usually could be done by IDE tools.
Feedback, to mutual understanding
When you are writing, comment, explain why and how it can be improved.
- Clear and Constructive Feedback: It is essential to be clear and constructive. Instead of hard pointing out issues, explain why certain changes are needed and how they contribute to better code quality. This not only helps the developer understand the idea behind the feedback but also provide a learning environment.
- Suggest Alternatives: Do not just highlight problems – offer solutions. If you identify a particular section that can be improved, provide suggestions or alternatives. This not only accelerates the correction process but also encourages developers to think critically about different approaches.
Try not to point issues, but if you find one, notice good things
- Acknowledge Creativity: While focusing on improvements, don’t forget to acknowledge the positive aspects of the code. If you come across a creative solution or an innovative approach, take a moment to highlight and appreciate it.
- Recognize Performance Optimizations: If the code includes optimizations that enhance performance, responsiveness, or resource utilization, make sure to acknowledge them as well. These optimizations may not always be apparent at first glance, so take the time to recognize and commend the effort put into making the code more efficient.
Not every day is code review day
If you’re feeling tired or had a tough day, it’s not a good idea to review code. When you’re tired, it’s hard to pay close attention, and you might miss mistakes in the code. You could also end up giving feedback in a not-so-nice way, which can make the team feel not so great. It’s better to wait until you’re feeling more rested and clear-headed to review code. Taking breaks and making sure you take care of yourself can help make code reviews better for everyone.