Hey all! My team at work is struggling with growing pains of getting into a formalized review process, so I was wondering if any of you guys have some things to live or die by in your code reviews. How much of it is manual, or how much is just static code analysis + style guide stuff, etc?

  •  vraylle   ( @vraylle@beehaw.org ) 
    4•1 year ago

    We use a version of Git Flow for branching (since everyone is talking about branching strategies here). But technically, you asked specifically about code review process. Every ticket is it’s own branch against the development branch, and when complete is merged by PR into the development branch. We’re a small team, so our current process is:

    1. Merges to the development branch require one approval
    2. Merges to the main branch for a release require two approvals
    3. If the changes are only code, any developer can review and approve
    4. If there are “significant” SQL changes a DBA approval is required.
      • “significant” means a new entity in the DB, or…
      • an inline/Dapper query with a join

    As we grow we’ll probably have to silo more and require specific people’s approval for specific areas.

    A lot of what we do is “cultural”, like encouraging readability, avoiding hard-coded values, and fixing issues near the altered code even when not related to the original ticket. The key is to be constructive. The goal is better code, not competition. So far we have the right people for that to work.