Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Code Review Workshop for Researchers - SSI 2022 - Closing Remarks

Code Review Workshop for Researchers - SSI 2022 - Closing Remarks

Closing Remarks Presentation of the "Code Review Workshop for Researchers" held online on 10th February 2022

Organised by Software Sustainability Fellows (SSI)
* Dominik Krzemiński (Cambridge University)
* Thibault Lestang (Imperial College London)
* Valerio Maggio (University of Bristol)

More: https://codereviewworkshop.netlify.app

Valerio Maggio

February 10, 2022
Tweet

More Decks by Valerio Maggio

Other Decks in Programming

Transcript

  1. Code Review for Researchers
    Closing Remarks
    v
    a
    lerio.m
    a
    ggio@bristol.
    a
    c.uk
    @leriom
    a
    ggio V
    a
    lerio M
    a
    ggio

    View full-size slide

  2. Thank You, very much!
    Image Credits: bounteous.com/insights/2019/06/11/code-review-limbo-how-low-should-you-go

    View full-size slide

  3. Summary (1/)
    Why Code Review matters ?
    • Code Review fosters Knowledge Sharing


    • Ensures Consistency (design & implementation)

    • Code Review bene
    f
    its overall code quality


    • (also) aids track of changes: pre-commit and post-commit CR



    • Code Review fosters Collaborative work


    • Mentoring new-comers (e.g. new lab members)

    View full-size slide

  4. Summary (2/)
    Why Code Review matters ?
    • Code Review lowers the barriers


    • There is no shaming nor blaming in CR!


    • Helps
    f
    ighting the Imposter Syndrome (more on this in the next slide)

    • (Most compelling reason for Code Review)

    Find defects as early as possible in your development process

    View full-size slide

  5. Summary (3/)
    How to Code Review ?
    Re Imposter Syndrome, i.e. fear of being found out as “Bad Programmer”


    • Code Review should help to set up a safe environment


    • It is a tool we should use to grow as better SE, and scientists.


    • (therefore) Rule #1: Being Respectful

    • Code Review is not all about defects


    • Great practice to also recognise the good parts of a code listings!

    View full-size slide

  6. Summary (4/)
    How to Code Review ? (more practically)
    1) Write some code (😏 )


    2) Ask someone to look at the code


    3) Incorporate their feedback into your
    code


    4) Repeat 2 and 3 until satisfactory for
    both parties


    5) Enjoy 🎉
    Code Review Loop
    • Code Review can be carried out IRL or remotely

    (e.g. GitHub or ReviewBoard)


    • Communicate Goals and Expectations


    • Know what to look for in a CR


    • Give feedback and Helps


    • Make sure to include everyone in the process


    • Every contribution counts

    (like in Open Source)
    (short) Tips list

    View full-size slide

  7. Getting Started with Code Review (1/)
    Find Reviewers
    Find Reviewers:


    • In your research group


    • In your lab


    • In your Institution


    • Ask your PI.


    • Organise a Coding-Group


    • Reaching out to SSI and RSEs


    • Join CR Network

    View full-size slide

  8. Getting Started with Code Review (2/)
    Choose a Code to Review
    Author:


    • Aim for 40/45 mins, ~200LOC


    • Choose depending on your expectations


    • Pick a part you are not con
    f
    ident about
    (or very con
    f
    ident with)


    • Pick a part that is representative of your
    programming practice


    • Lean towards Pre-Commit CR in your dev.
    cycle
    Reviewer:


    • Fast interactions and (reasonably) short
    comments (esp. for online CR)


    • Explain Why


    • Give Guidance


    • LGTM w/ Comments

    View full-size slide

  9. Getting Started with Code Review (3/)
    Start with Conversation and Agree on a Plan
    • (If needed) Introduce yourself: provide background and relevant experience


    • State Expencations and Goals


    • Provide the reviewer with any context or pre-requisite about your code


    • e.g. this is a heavily numerical module that
    f
    its within a larger ecosystem. I have been
    working on this for the past couple of days.


    • e.g. This is a script that simpli
    f
    ies my own personal experimental setup, I wrote it 2 years
    ago from another student's script.


    • Prefer Live Discussion (whenever possible)


    • Give the reviewer some time to make their own independent ideas


    • (Ultimate Goal) Make Code Review a Standard Development Practice

    View full-size slide

  10. (some) References
    • Google Engineering Practices Documentation

    https://google.github.io/eng-practices/


    • Code Review as a Simple Trick to Enhance Reproducibility, Accelerate Learning, and Improve the Quality
    of Your Team’s Research (Vable et al, 2021)

    https://academic.oup.com/aje/article/190/10/2172/6218064


    • Code Reviewing in the Trenches (MacLeod et al 2017)

    http://chisel.cs.uvic.ca/pubs/macleod-IEEESoftware2017.pdf


    • A recent ACM talk by M. Greiler (Youtube)

    https://www.youtube.com/watch?v=gRR-UhusQe8


    • A old, short but popular blog post by Je
    ff
    Atwood, see also the discussion underneath

    https://blog.codinghorror.com/code-reviews-just-do-it/


    • Another rather popular couple of posts by M. Lynch

    https://mtlynch.io/human-code-reviews-1/


    • What to look for in a code review (Trisha Gee, JetBrains 2017)


    • Code Review By and For Scientists (Petre and Wilson 2014)

    https://arxiv.org/abs/1407.5648

    View full-size slide