# Code Review

## November 9th, 2020

-   Oscar, apparently, is down - not good!
    -   eroland3@gatech.edu (Team we're reviewing)
--------------------------------------------------------------------------------

-   Today, we'll be talking about the Code Review assignment (which is due first) and the delivery documentation
    -   At Tech we probably require too few code reviews from students, but in the real world understanding other people's code and being able to understand if it's good or not, and why, is HUGELY important
        -   In the career world, they expect you're a Georgia Tech grad who can just jump into code and start getting a handle on it

-   Let's go ahead and talk about the code review assignment; hopefully most of this sounds familiar from CS 2340
    -   This review isn't going to be massive, but instead just a 60 minute review of another team's code (if you go over that's okay, but don't spend hours on it)
    -   Make sure to send your GitHub link to the team that's assigned to review you
    -   Then, someone should be assigned to moderate the meeting and keep track, someone will read the code and try to explain what it does, someone will take notes, and then everyone else will inspect the code and critique it (both positive feedback and identifying issues)
    -   A few tips:
        -   Code reviews are NOT debugging sessions; they're about identifying issues, not solving them, so don't get bogged down trying to figure out how to fix something (that's the developer's jobs)
        -   Critique the code, NOT the people who wrote it; stay professional. Everyone makes mistakes
        -   Before meeting as a team, look at the code individually for ~30 minutes so you have some orientation going into the code and don't spend much meeting time purely on prep
        -   Focus primarily on logic errors and substantive structural issues, not stylistic errors
            -   This may be difficult if you're not actually running the code, but try to identify what you can
        -   Devote some fraction of time on the actual quality of the team's code; give the team actually useful feedback, not just the bare minimum amount of work
        -   Using a checklist for the code review (this is a bit old-school and probably overly professional, so use it as a rough guide)
    -   You'll then turn in:
        -   A list of typos/stylistic errors
        -   An issue log where you record problems (PDF on Canvas)
            -   There's no minimum number of issues you need to have; we care much more about quality of the issues you DO identify, and that the issues you identified are real and helpful, not just done for a grade
        -   A summary report of the code review
        -   A cover sheet (PDF on Canvas)
            -   "I don't really care if you put an in-person signature"

-   "This is actually a pass-fail assignment, and almost everyone passes"

-   For the delivery documentation, it really is basically a README for your GitHub repo!
    -   Your client is going to want some installation/usage instructions for whatever it you're building; you should have some instructions to do this for regular users, as well as for developers (if needed)
        -   Mention the pre-requisites you expect, 3rd party libraries your software uses, download instructions/links for online stuff, build instructions (for future developers), installing the app, run instructions, and a basic troubleshooting guide
    -   You should also have some release notes for the product; really, just have this for the last sprint (don't dump all your user stories, just mention the most recent changes from the past few weeks)
        -   You should also list any known bugs or missing features you still have and didn't have time to fix

-   The Demo and elevator pitch should be combined into ONE video; you have 30s for the elevator pitch, and 2m 30s for the demo, so 3 minutes total for the video