smably

How to Give a Great Code Review

Claim: A great code review is thorough, constructive, kind, and prompt.

Thorough

1. Effective code review requires that you understand what the PR is trying to accomplish. If there is a ticket or issue associated with the PR, start by opening it and reading the acceptance criteria. Then read through the PR description. Think about how you might approach the problem if you had written the code yourself. What are the constraints? What are some edge cases you would want to watch out for? If you are unclear about any aspect of the problem the PR is solving, talk to the author to clarify before you start looking at their code.
2. If the author has deployed their code to a QA environment, take some time to try out the new functionality. See whether the actual behaviour matches your assumptions. If not, go back and check the acceptance criteria. If you have any questions or you think you’ve found

kevinweber

<alignment jcr:primaryType="nt:unstructured"
    name="./alignChildren"
    fieldLabel="Alignment of components"
    required="{Boolean}true"
    selectionMode="single"
    sling:resourceType="granite/ui/components/coral/foundation/form/buttongroup">

    <items jcr:primaryType="nt:unstructured">
        <default jcr:primaryType="nt:unstructured"
            name="./default"

mikepea

Pull Request Etiquette

Why do we use a Pull Request workflow?

PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.

Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories

Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.