{"id":607,"date":"2021-01-08T07:18:34","date_gmt":"2021-01-08T07:18:34","guid":{"rendered":"https:\/\/metrics.blogg.gu.se\/?p=607"},"modified":"2020-12-28T14:39:36","modified_gmt":"2020-12-28T14:39:36","slug":"consistency-in-code-reviews-article-review","status":"publish","type":"post","link":"https:\/\/metrics.blogg.gu.se\/?p=607","title":{"rendered":"Consistency in code reviews (article review)"},"content":{"rendered":"\n
\"\"
BIld av press 👍 and ⭐<\/a> fr\u00e5n Pixabay<\/a><\/figcaption><\/figure>\n\n\n\n

tse2020_hirao.pdf (uwaterloo.ca)<\/a><\/p>\n\n\n\n

In the last year, I’ve written a lot about code reviews, mostly because this is where I put my effort now and where I see that software engineers could improve. <\/p>\n\n\n\n

Although there is a lot of studies about how good code reviews are and what kind of benefits they bring, there is no doubt that code reviews are a tiresome task. You read software code and try to improve it, but, let’s be honest, if it works don’t break it – right? <\/p>\n\n\n\n

In this paper, the authors study open source communities and check how often the reviewers actually agree upon the code review score. They find that it’s not that often – 37% disagree. From the paper: “How often do patches receive divergent scores? Results: Divergent review scores are not rare. Indeed, 15%\u201337% of the studied patch revisions that receive review scores of opposing polarity<\/strong>“<\/p>\n\n\n\n

They also study how the divergence actually influences the patches – are they integrated or not: “Patches are integrated more often than they are abandoned. For example, patches that elicit positive and negative scores of equal strength are eventually integrated on average 71% of the time. The order in which review scores appear correlates with the integration rate, which tends to increase if negative scores precede positive ones.<\/strong> “<\/p>\n\n\n\n

Finally, they study when the discussions\/disagreements happen and how many reviewers there actually are: “Patches that are eventually integrated involve one or two more reviewers than patches without divergent scores on average. Moreover, positive scores appear before negative scores in 70% of patches with divergent scores. Reviewers may feel pressured to critique such patches before integration (e.g., due to lazy consensus).2 Finally, divergence tends to arise early, with 75% of them occurring by the third (QT) or fourth (OPENSTACK) revision<\/strong>. “<\/p>\n\n\n\n

I think that these results say something about our community – that we tend to disagree, but do integrate the code anyways. What does that mean? <\/p>\n\n\n\n

It could mean two things, which IMHO are equally valid:<\/p>\n\n\n\n

  1. The review comments do not really touch upon crucial aspects and therefore are deemed not so important (e.g. whether we call something weatherType or typeOfWeather as a variable…)<\/li>
  2. The reviewers’ reputation makes it difficult to get some of the comments through, e.g. when a junior reviewer is calling for a complete overhaul of the architecture. <\/li><\/ol>\n\n\n\n

    Either way – I think that the modern code review field is quite active these days and I hope that we can get something done about the speed and quality of these long and tiresome code review processes. <\/p>\n","protected":false},"excerpt":{"rendered":"

    tse2020_hirao.pdf (uwaterloo.ca) In the last year, I’ve written a lot about code reviews, mostly because this is where I put my effort now and where I see that software engineers could improve. Although there is a lot of studies about how good code reviews are and what kind of benefits they bring, there is no … Continue reading “Consistency in code reviews (article review)”<\/span><\/a><\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,7],"tags":[],"_links":{"self":[{"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=\/wp\/v2\/posts\/607"}],"collection":[{"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=607"}],"version-history":[{"count":1,"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=\/wp\/v2\/posts\/607\/revisions"}],"predecessor-version":[{"id":609,"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=\/wp\/v2\/posts\/607\/revisions\/609"}],"wp:attachment":[{"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=607"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=607"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/metrics.blogg.gu.se\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=607"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}