Sure, you can read the description in the ticket, and you can figure most things out from the code. They will be able to fill you in on why it is done the way it is. In those cases, it is good to talk to the developer before starting the review.
#CODE IT RIGHT INSTANT REVIEW NOT WORKING CODE#
In a team of ten people, there is usually someone that can jump in and do the code review without it interrupting their own work too much.Īsk for context. You would write a message in the chat, and usually somebody in the team would start the review more or less immediately. In my team we always prioritized code reviews for this reason. The longer the review takes, the worse it is. One problem with code reviews is that they force you to context switch until the review is complete. The original developer should test the code, otherwise how do they know that what they have developed works? Given that the code has already been tested, it is enough to review the code without also running and testing it. I think this takes too much time and effort. Some people think that to do a proper review, you should pull down the changes and run and test the code. If problems like these are only detected during code review, then I have wasted a lot of effort coding and testing that change. Perhaps the change should be made somewhere else? Or maybe I could use an already existing feature I didn’t know about. Having a discussion like this before I start means that I will hopefully find out if there are better ways of doing it than I have thought of so far. If I am developing a feature, and it is not obvious how or where to make the change, I like to discuss it with one or more people in the team before I start. Code reviews also help to spread the knowledge of how the code works. And once in a while there actually is a bug. Even if there aren’t any bugs, there can still be issues that should be corrected: unclear code, poor naming, missing tests etc. Therefore it is good with a second pair of eyes to check the code. It can be hard to spot your own mistakes. First of all, it is similar to proof reading text. Why code review? Even though I don’t find many bugs, it is still worthwhile. Either way, it would be interesting to hear about other people’s experience in this respect. Or perhaps it is because I have really competent colleagues. Perhaps it is because I am bad at reviewing code. I find outright bugs maybe once or twice a year. All those things should be corrected, but if the program ran, it would still produce the correct result. I don’t count things like poor variable names, missing test cases, or misleading log messages. By bugs I mean cases where the program would do the wrong thing. When I review code, it is quite rare that I find bugs.
#CODE IT RIGHT INSTANT REVIEW NOT WORKING HOW TO#
Below are my thoughts on the value of code reviews, and how to make the process efficient. But I still think code reviews are useful. This is however not my experience – I rarely find outright bugs when reviewing changes. An example is chapter 18 (Modern Code Review) in the book Making Software. There seems to be an established truth in programming that code reviews find a lot of bugs.
0 kommentar(er)
