Code Review
1 like98 views
The document outlines Erik Ecoologic's process for reviewing code. It begins by stating that code reviews should not be too large and commits should have clear messages. It then details the steps Erik takes which include reading architecture, tasks, commits and code from specs. Erik ensures code meets quality standards through testing, readability, simplicity and following best practices. Comments are suggested objectively and learning is emphasized. The document promotes being kind and discussing code in-person. Resources on code reviews, the programmer's oath, clean code and agile principles are also provided.
Code Review
- 1. How I review code @erikEcoologic Github: erikEcoologic
- 2. Too big? • Ask to split it (: • I will make frequent, small, releases so that I do not impede the progress of others (Programmer’s Oath n.4)
- 3. Read • Architecture agreed in advance? • The actual task description (referenced in the MR title) - ideally • The MR title and description • The commit messages…
- 4. Commit messages • Fix… (tell what) • Refactor… (tell what, use multiline?) • S1234 As a user I want to do this (include specs for this) • S1234 As a user I want to do that (include specs for that) • Cleanup (green specs) • — • Possibly avoid commits with: WIP, “solved conflicts”, “merged x” etc • git reset --soft origin/master # Careful - Git stash; green specs; Bisect
- 5. Reading the Code • Scroll and get an idea • Start from the specs • Follow the code like a parser • Global review
- 6. Specs • What you expect from the title (core functionality) • Some unit tests • Internals are not mocked • betterspecs.org • I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should (Programmer’s Oath n.3)
- 7. Production Code • Security!! • Readability • Doesn’t make you feel stupid • I will continuously ensure that others can cover for me, and that I can cover for them (Programmer’s Oath n.7) • Simplicity • Can you think of a simpler way?
- 8. Good Code • Agile principles (e.g. DRY, IAGNI) • OO principles (e.g. SOLID, Demeter) • Design Patterns (e.g. Service) • Code smells (e.g. Shotgun surgery) • Bad practices (e.g. Comment what) • The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate (Programmer’s Oath n.2)
- 9. Naming!! • Follows company conventions • Follows project conventions • Consistent namespacing • Specific, limited responsibility • It does what it says • Is clear what it does 9
- 10. How to comment • Ask questions • Suggest, don’t impose yourself • Back your comments with links • Everyone learns, objective comment • In depth explanation • Create a common language • I will never stop learning and improving my craft (Programmer’s Oath n.9) • Agile: People over tools, be kind • Talk in person, but make sure you’re chill • Mention the good stuff too
- 11. More Resources • blog.jetbrains.com/upsource/2015/07/23/what-to-look- for-in-a-code-review • blog.cleancoder.com/uncle-bob/2015/11/18/ TheProgrammersOath.html • Clean Code Book - Robert C. Martin • Refactoring Book - Kent Beck • Agile Manifesto
- 12. Thank You Twitter: @erikecoologic Github: ErikEcoologic