About this talk
This talk discusses the intricacies of code reviews, highlighting their importance in software development and team dynamics. The speaker emphasizes the benefits of code reviews, such as enhancing code quality, sharing knowledge, and preventing errors early in the development process. However, they also address challenges like delayed feedback and ineffective communication between team members. The session provides practical tips for both code authors and reviewers, encouraging best practices like self-review, clear documentation, and respectful feedback. Ultimately, the speaker advocates for a more collaborative approach to code reviews to foster a positive work environment and improve overall team performance.
Full transcript
[music] j hello, I'm glad to see such a full hall. Thank you Ivo for the kind words about my performance. Now, to begin with, I would like to ask you a few brief questions. The first one is, right, I'm going to ask you to respond with a show of hands. Which of you in the room are currently in the position of senior, mid-level, or junior programmers? Okay,
okay. Lots of hands raised. Great. And are there people among us who take on more managerial positions, say Team Lead, Tech Lead, Engineering Manager, or something similar? Okay, there are some hands raised. I'm glad about that. Okay, so which of you are currently attending the lecture just because you're waiting for the raffle to come? Okay, there are hands up again Thanks for the candid answer. Jokes aside.
Last serious question. Which of you participate in the code drive on a daily or almost daily basis, whether as code authors or as code reviewers for your colleague? Okay. Still quite a few hands raised, almost the entire hall. Why have I decided to share this topic with you? A comprehensive guide to a more enjoyable work experience. Why do I think it's important? Conducting code reviews has established
itself as a key component of software development. At the same time, they also occupy a large part of our daily lives, regardless of the position we hold as programmers or as leaders of teams of programmers, as we just saw with the raised hands. What's interesting to me is that behind their technical focus, code reviews touch on different elements of the workflow. They deal with both the technical
implementation of a given task, ensuring its quality, and dynamics, communication, and relationships between people in the team. Along with their undeniable benefits, they also hide their challenges, as the lack of a suitable approach and attitude for conducting them could lead to them being perceived as a tedious commitment or to increased tension in the team, which in turn will ruin the working atmosphere. Let's quickly see what we're
going to talk about today. At the beginning, I will highlight some of the benefits of holding a co-dinner. Then we will share what challenges they pose, and then I will share with you a set of practical tips, for both code authors and reviewers, that have helped improve the code review process teams I have worked on. First, a quick clarification, a familiarization with the terms. When I talk
about conducting a code review, imagine perhaps the most common situation where one person writes some code, he is the author of those changes, and sends a request to one or more of his colleagues so that they review his changes. Okay, what are the benefits of holding Kotrivo? How do they help us improve the workflow? I will focus on five such benefits that I have found to be
important and very useful based on my experience. The first benefit, finding better solutions by sharing ideas and comments among colleagues, so as to find the best implementation for a given task. Second benefit, improving code quality, again by sharing ideas and comments on suggestions, so as to ensure maximum code quality. Third benefit, accident prevention. at a very early stage, when their correction and removal is most painless. Fourth
benefit, sharing knowledge between people on the team who have different experiences, different knowledge, both about software development and writing quality code, as well as information related to the product and system you are developing. And the fifth benefit, increasing team commitment, strengthening the feeling of a common team effort, so that together we can find the best possible solution, achieve the highest quality development. Okay, let's now see what
challenges the co-drives still hide . Again, I will share with you five that I consider essential. The first challenge, time to wait for feedback. The longer it takes to respond to a sent message or to provide comments, the more the author would get fed up, stressed, and stressed, because most likely he is blocked and cannot continue with his next tasks until he receives response. Second challenge. A
large number of changes to review. Here, reviewers would get frustrated. because they would get a big bag of change and they would start wondering where to get it from . This will either lead to the code review being postponed or being skipped. In any case, this will mean a lower quality of the review. Third challenge, lack of time for review. Again, if you are overwhelmed with other
ongoing tasks, you may not bother with the code at all and just tap and quickly check it off, which will mean that you will not provide the necessary added value to the process. Fourth challenge, giving inappropriate feedback. Here I mean any useless comments, any comments that do not give a specific idea of what and how to improve, or direct personal attacks. Fifth challenge, reaching agreement, when there
are different ideas, different points of view on a given issue, how can you most easily and quickly reach some kind of consensus so that you can make the best possible decision. Okay, we saw that there are benefits, but we also saw challenges. Now I will share with you 10 practical tips that I think would help improve the code review process in your teams. I'll start with advice
for code writers. If you've been looking for recommendations and ideas on how to optimize the review process, how to make it more effective, you may have noticed that the main emphasis is on code reviewers. And this is understandable, because after all, the main goal and idea of code reviews is to guarantee the highest possible quality of a given implementation. At the same time, through simple steps, the
code author can greatly improve the review process, can make it incredibly easier for reviewers, and thus code can provide the much-desired workflow. The first tip. Review your own changes. Don't rush into launching Request. Take enough time, after you have done the implementation, to check it once, twice, three times, as many times as you deem necessary, to make sure that your code is in the optimal form for
you. Check whether the task requirements have been implemented. Think about whether something can be optimized. For example, to use other design patterns, other libraries, to somehow simplify the implementation. Consider more appropriate naming of classes, variables, class properties, and methods so that your code becomes more common, more understandable, and easier to maintain. Test the changes. Ensure that all existing tests continue to pass successfully, and that you have
written all the necessary tests to cover the various test scenarios. Be responsible. Don't assume that once you've submitted your changes for review, your colleagues will inevitably discover all the inaccuracies you've made. You, as the code author, are the person who is best acquainted with the implementation, who has the most insight into the details, and you are the person who can best detect inaccuracies. Overall, these things will
save time for both you and your colleagues, because there will be no need for unnecessary new code reviews, and you will generally save yourself trouble in the future. Second tip. Reduce annoying inaccuracies. One of the most unpleasant and irritating things for code reviewers is seeing some obvious errors and inaccuracies in their colleague's code. Use different tools to minimize these inaccuracies. As specific suggestions from my side, use
spellcheck eliminate all spelling errors. Use code formatting tools like Config to your code follows established company or team code style guidelines, eliminating pointless arguments like what to use for code spacing, tabs, or spaces. Use code analysis tools that will help you find out about any inaccuracies you may have made , such as forgotten documented code, forgotten unused variables, left-over debuggers, or give you specific guidance on what
things can be optimized, how to reduce the complexity of your Thanks to these things, you will be able to make reviewers focus on the really important things and components of the review, the things that no tool can validate, such as whether the changes made implement what is required by the assignment. You will also ensure that you save time on subsequent reviews by automatically removing any annoying inaccuracies.
Third tip. Aim for a small number of changes. Code revisions that contain a small number of changes are reviewed faster, and this is due not only to the fact that they are smaller in size, but also because reviewers will be more likely to devote attention and time to that code review. The psychological barrier that they don't have time for this right now and don't feel like doing
it falls . Also, small changes increase the quality of the review itself. Because reviewers have to make sense of, understand fewer things, and accordingly provide better quality feedback more accurately and more reliably also lead to fewer bugs in the implementation. Also, a smaller number of changes are easier to roll back because they are expected to cause fewer merge conflicts, and if necessary in the future, they would
be easier to roll back. As a suggestion from my side, how to achieve this desired effect? First, limit the scope of the changes. Be careful with the so-called scripting, which would occur if, say, you start a bugfix and at that very moment you decide that it is super appropriate to change the name of a method to a more eloquent name in your opinion. Accordingly, you will have
to make changes in all places where this method is called and finally your substantial changes, your bug fixing will be overwhelmed by refactoring changes. Therefore, try to make one code refer to exactly one thing. Leave the rest for another day. Also, if you've done a larger overall implementation and ended up with a big bag of changes, consider how best to break them into multiple code drives to
help reviewers more easily review them. However, be careful not to break them down into such small parts, such as having each line of change in a separate code review, and in this way, instead of making things easier, you could make things more difficult for the reviewers, and lose the overall picture of the implementation. You know very well that if you receive 10 lines of code for review,
you will most likely get 10 comments and 10 ideas for improvement. And if 500 lines of code need to be reviewed, hardly anyone will bother, and the code review will skip over it, directly saying that everything is fine, and the quality of the review will drop, which could lead to unpleasant incidents in the future. Fourth tip. Write an appropriate description of the changes. Having a clear, well-formatted,
and detailed description of the changes made makes it incredibly easy for reviewers and speeds up the review process. The goal of this description is to convey clarity about what the changes are and why they were made. This way, reviewers will be able to provide much better quality suggestions and Also, having such a description would help in the future to track the history of changes. For example, in
situations where an incident needs to be investigated and you go back how and why this functionality was implemented in this way. Or if a colleague wants to understand how a certain functionality was implemented that he did not work on, or even if the code author himself wants to remember after months or years what exactly he implemented. As a suggestion, so that you don't have to wonder every
time how and what to include in your description, you can use a Pull Request Template. This is a Markup file that easily integrates into Asure Defs, GitHub, GitLab, thanks to which, when you launch a Pull Request, guidelines are directly loaded into the description field for you to follow. Now I'll show you a quick example, a short example of such a custom template, which might include a short
descriptive title, then indicate what the type of change is, followed by the main part of the description. Please describe in detail what the changes are and what led to their implementation, and in general any useful information related to their context. You can then write what tests you added and finally any additional information that you think should be taken into account by the help reviewers see your changes
better, understand them more clearly, and be able to provide better suggestions for corrections, which will lead to finding a better solution and implementing better code. Fifth tip. Be open to Don't take your colleagues' comments personally. Everyone makes mistakes. Programming is a skill like any other that requires improvement and refinement. Be of the mindset that your colleagues are well-intentioned towards you and that you have a common goal
to find together the best possible solution to a Be prepared that your implementation will not always be the best. After all, you are working with people with different experiences, with writing quality code, and also with different knowledge about the product and system you are working on. Therefore, try to make good use of their suggestions and take advantage of them to learn new things and gain new knowledge.
Also take the opportunity to find out how you are doing. Very often, each of us seeks feedback from a more experienced colleague, from a direct supervisor or manager, to understand how we are doing with our work, what we can improve, how we can become a better professional. But few people realize that co-trees provide such an opportunity every day. Treat comments and responses to code on pullquests that
you receive from your colleagues as a kind of feedback that you can use to improve yourself. In general, try to understand the other side. Thank you for your feedback. Try to understand the changes well to get the most benefit for you. Okay, now let's move on to the five tips for code reviewers. Typically, the emphasis in reviewing and how reviewers can be more effective in reviewing code
falls on how they can find as many bugs and problems as possible in At the same time, however, we work with people and the way we convey our ideas, the way we communicate our suggestions, is essential so that they can be perceived in the right way, so that they are not perceived as some kind of direct criticism and attack, respectively, leading to interpersonal conflicts, and hence to
increased tension in the team. Therefore, it is very important that, in addition to the technical aspect, code reviewers also focus on their communication with colleagues. First tip. Start the review promptly. Treat code review as a high priority task. Don't delay starting it for an unnecessarily long time, so as not to make your colleague wait and get nervous about creating a situation. Prevent the accumulation of a large
number of code reviews for you to review precisely by starting early, so that you can devote more time to each code review in a more focused and careful manner and thus provide better quality feedback and ideas for improvement. However, be careful of the negative effects of context switching. You know very well, and you know very well start to watch one code review per second when you receive
a notification for a new pool request and load your current tasks, you will inevitably pay the high price of context switching. with him. And besides the fact that when the context changes, you will need extra time just to remember what had to be done, where I had gotten to now, what was required of me. This will reduce the quality of your current tasks and your review will
not be effective . So think about what approach works best for you. a suggestion from me. You can set aside time slots during the day to focus solely on reviewing the code review. And if these intervals are selected in a suitable way, you can achieve both the desired effect of providing timely feedback and not constantly losing focus and jumping from task to task. thus your work will
better quality. In general, don't keep your colleague waiting for too long . Usually he is blocked and tasks until you return a response, until you return your comments. So provide feedback within a reasonable time frame. Second tip. Be responsible. Don't rush the code review. Take enough time to focus on all the changes, understand them, and make sense of them, so that you can provide more adequate suggestions
for improvement and together achieve better quality code and find the best possible solution. It is recommended that you approach it in a structured way so that you don't have to wonder every time what I need to review, what is important, what is not. As a suggestion from my side for such a structured approach, I will share two things with you. The first is to use a checklist.
This is a list of questions for each reviewer to go through and which questions to find answers to during their The second approach is the study of a kind of codreve pyramid. For both suggestions on this slide, I have left links to a more detailed description and to examples. The presentation will be shared with you after the end of the conference, so you can safely view them.
Now I will say a few words about both approaches. About the checklist. This list of questions would be nice if the questions were grouped into some basic categories. Now I'm going to show you a list of such and such categories that you can use. The categories include things implementation, related to whether there are logical errors and bugs in the code. Then, is a proper root mechanism, proper
logging, ensured so that it can be used in investigating incidents? Then how these changes interact with other components of the system. Do these changes in any way compromise data security and confidentiality ? How do these changes affect system performance? Also, whether these changes are testable and whether all necessary tests are provided to possible test scenarios. And last but not least, code readability. whether the code is understandable,
easy to maintain, whether it follows established team or company practices for writing code. Regarding the pyramid, it was designed by Dr. Milan Milanovic. As I said a moment ago, I have left a link to his newsletter post, where it is described in more detail, as it consists of five levels, and the closer each level is to the base, the wider it is, because it needs to be
paid more attention, because things at this level would have a more serious impact on the implementation and on the quality of the development. At the bottom design. How do your changes How does the design of your changes fit with the existing software or solution architecture? Are the principles of high cohesion or something else followed? Then we move on to implementation. Has by the assignment been implemented? Can
anything in the implementation be simplified? Is there proper logging, error handling mechanism, and so on? The third level, tests. Are all necessary unit integration tests provided? Is it guaranteed that ? The fourth level, documentation. Has an appropriate description of the changes been added? Has any other appropriate documentation been added for them? And the top level is now the code style, your code or your colleague's code? Does
it follow established team code style guidelines? Once a piece of code is checked into the common codebase, it becomes a common commitment and a potential common problem in the future if production issues arise, for which you, as a team, will need to quickly find the most adequate solution. So don't Give it enough attention so that you can be sure that you have given the feedback possible. Third
tip. Ask questions and suggestions instead of orders. By framing your comments as questions, you create the feeling of a softer way of giving feedback. It doesn't feel like a direct order. Also, with the question you show a desire to find out what the opinion of the author of the code is. Give the opportunity to open a discussion between you, to share different ideas and even to find
an even better solution to the given task. Also, by asking questions, you can understand the reason for a decision. The author of the code can share with you what steps he went through, what things he took into account, to get to this point, to this implementation. This way, you will better understand his idea and save yourself any unnecessary and unfounded criticism or direct attacks that he got
something wrong, that he, that his implementation is totally wrong, given that you may simply be missing some information. You may not have guessed anything. By formulating suggestions, you provide useful and actionable comments that give specific ideas about what and how can be changed. I don't like comments like this , they seem too slow to me, and they bring absolutely no value to your colleague. Now we will
illustrate these principles with two quick examples, and for both them and the following examples of the following tips, I will first show you an unsuccessful approach to writing a comment, to giving feedback, and then a more successful one. The first example, an unsuccessful approach. Move the user validations file. New validations folder. That sounds like a direct order. Listen, perform. I don't care if you like it, don't
like it, what do you think? Take action. With a better approach. What do you think of the suggestion to move the user validations file to a new validations folder? This will separate the validations from the rest of the files and make it look cleaner. The file structure will become clearer . By asking the question, you signal to your colleague that you would be interested in what his
or her opinion is on the matter. You also provide an explanation, a better explanation of your idea, so that he can better understand the motive for your comment. That way he will be more willing to accept it and consider whether it is truly meaningful or not. Second example. Bad approach to writing a comment. I don't like it at all. Completely redo the implementation. It's not clear what
you don't like . As a code author, what should I do to make you like it next time? I can't remember. And again a direct order. Rework the implementation. It's totally wrong. Throw it away and start over. A better approach to writing the comment. What is the reason you chose this realization? You give your colleague the opportunity to share with you what things he took into account,
what steps he went through to reach this decision. This his idea and then you will think about whether you can really give some suggestion for improvement, instead of directly criticizing him for not doing his job in general. By asking questions and suggestions, you reinforce the feeling of a common effort, of a common commitment to this common goal, and that you have a common goal to find the
best possible solution together, to find the highest quality solution for a given task together. Fourth tip. Give respectful feedback. Talk about the code, not the author of the code itself. I will now illustrate this again with a quick example. Poor approach to giving feedback. You forgot to mark user ID as a required parameter. You forgot to tag it. It's your fault. It sounds like a direct attack
on your colleague. A better approach. There is no indication that the user id is a required parameter. The code does not indicate that user ID is a required parameter. The problem is in the code. This way, your colleague will be more likely to understand your comment, think about it, and assess whether your idea is really good not. Second thing. Focus on a person's behavior, not on them.
This is a generally valid principle when giving feedback, regardless of the situation you are in . A person's behavior can be changed much more easily than any character traits. Either he wouldn't or if you put a label on him, he would feel directly attacked by you and would go into defensive mode and from then on he would only think about how to defend himself from your attacks,
rather than thinking about your proposal and whether it provides any value or not. Again, a quick feedback. You are careless about writing unit tests and skipping basic checks. You label your colleague as being careless. A better option. I advise you to spend more time considering what unit tests are needed before you release a request. This way you focus on behavior. Just take a little more time. You
are capable and capable enough to remember what June tests are needed, how to write them. Just take a little time. Also, use I messages instead of you messages. Try to frame your comments in terms of how you perceive the situation, how you feel. This way, there is a very small chance that the other party will start an argument with you, because they are subjective after all. You
say how you feel in a given situation, rather than using messages that are directly directed at your colleague, then he would again go into direct defensive mode and would not care at all about your suggestion and your comment. A failed approach. You wrote this method in an incomprehensible way. You wrote it incomprehensibly, while with the more appropriate approach, it's hard for me to understand what the purpose
of this method is. It's difficult for me. This method may be wonderful, it may be very well-crafted, but I can't understand what its purpose is. This would prompt the author of the code to think, if one person has difficulty understanding it, it will most likely be difficult for another person as well . What can I do to conversion? Overall, by giving respectful feedback, you increase the chance
that your colleague will think about your comments, your suggestions for improvement, and thus reach the best possible solution. Fifth tip. Praise the author. Most often, the focus of reviewers when reviewing someone else's code is on how to find as many problems and bugs as possible. Accordingly, to give constructive feedback. However, our contributions give you a wonderful opportunity to provide positive feedback to your colleague. Don't miss the
opportunity to praise him when you see a very well-done implementation. a beautifully crafted piece of code or some clever solution that you wouldn't have thought of. Positive feedback should be timely, specific, and sincere. It should also be separated from the constructive one, if you have one. Again, a quick example, a bad approach. Overall the changes are good, but the get user status method is big. This praise
cannot even be understood as praise. It doesn't sound sincere at all. It's also not specific what exactly you liked. And on top of that, constructive feedback is added in the same sentence are separated by a and your colleague will post the following . So your criticism, rather than pseudo-praise. A better approach. I really like that you moved part of the implementation into a separate user status service
class, which also follows the single responsibility principle. Good job. At the same time, it struck me that the get user status method is too large, as does the idea of breaking it down into smaller methods. This feedback sounds much more sincere and you give specifics, and you say specifically what you liked about your colleague's performance. Also, in a separate sentence or even better as a separate comment,
you leave the constructive feedback, which is based on the advice and principles that I shared with you a moment ago. Giving praise on your part will not hurt you. nor will it slow you down much in completing your work tasks. At the same time, the author of the code will be motivated by it. He will feel a sense of satisfaction from a job well done and an
incentive to continue in the same spirit in the future. Okay. And as a conclusion to all the advice I've shared with you, I would this: Take your time and prepare the changes for code as you would like them to be reviewed. Value the time and opinions of your colleagues. Respect the time they spend on feedback, conducting code reviews, and do whatever you can to make it easier
for them. so that they can do their job better. Value their opinion. Try Be grateful for the feedback you receive and try to make the best use of the suggestions so that you can get the most out of them and potentially learn something new. Remember that you are a team. Be responsible for your work. Do not resort to personal attacks and have the attitude that the other
party is well-intentioned towards you, that you have best possible solution to a given task together. This will lead to an improvement in the team atmosphere. From there, this will mean achieving better team results, which in turn will lead to more satisfied and happy users and customers of your products and services. And all of these things will also mean a experience. Thank you. Bra.
