25 May 2019

Reviewing code

History / Edit / PDF / EPUB / BIB / 2 min read (~308 words)
  • Verify that the build/tests pass
  • Read the issue title and description
  • New code
    • Understand the feature and associated requirements that are supposed to be implemented
    • Verify code implements the desired feature and that the requirements are completed
  • New/Changed code
    • Check code contains tests
      • Is all the new code covered by those tests?
    • Verify the location of new/moved files
      • Are the files in the right directory?
      • Are they appropriately named?
    • Verify classes, methods, functions, parameters naming
      • Are they significant of their purpose?
      • Are they clear enough?
      • Are they respecting the naming convention?
    • Does the code respect SOLID?
    • Consider that when functions/methods signature change, code may now be backward incompatible.
      • Discuss whether this is necessary
      • Backward incompatible changes should be documented
    • In a weak typed or type hinted language, are parameters and return of functions/methods typed?
    • Are there TODOs that should be completed within this review?
    • Check code for code style issues
  • Bug fix
    • Verify that the fix is applied at the right location and will not "fix the symptoms, not the cause"

When reviewing

  • Provide specific and actionable feedback
  • Clearly mark nitpicks and optional comments
    • Alternatively, use an approach such as RFC2219 where you indicate whether a change is a MUST, SHOULD, or MAY
  • Assume competence
  • Provide rationale or context
  • Consider how comments may be interpreted
  • Don't criticize the person, criticize the code
  • Don't use harsh language

25 May 2019

Writing tests

History / Edit / PDF / EPUB / BIB / 1 min read (~84 words)

When joining a new project without tests, here is the value you need to provide through the addition of tests:

  1. the application works and doesn't crash
  2. the application works and supports a few input cases
  3. the application works and supports a variety of input cases
  4. the application works and is robust to most input cases
  • Write a test that tests the common case usage of your function
  • Write tests that cover edge cases of your function
  • Write tests to cover all statements, branches, paths
25 May 2019

Writing commits

History / Edit / PDF / EPUB / BIB / 1 min read (~85 words)
  • One liner describing what changed (not period terminated)
  • A few lines describing in more details why things changed
  • GPG signed commit

  • Separate subject from body with a blank line
  • Limit the subject line to 50 characters
  • Capitalize the subject line
  • Do not end the subject line with a period
  • Use the imperative mood in the subject line
  • Wrap the body at 72 characters
  • Use the body to explain what and why vs. how

25 May 2019

Web applications

History / Edit / PDF / EPUB / BIB / 1 min read (~61 words)

  • 3 different environments: development, staging, production
  • Write migrations for schema changes
  • Use ORM if possible over raw queries
  • Always make it possible for testers to report the version they tested against
    • Simplest is to have a meta field in the head section

  • Mockups
  • SRS
  • Database and software architecture
  • Implementation
  • Test/QA
  • Deployment

25 May 2019

Writing tickets

History / Edit / PDF / EPUB / BIB / 1 min read (~36 words)

  • Title
  • Important
  • Urgent
  • Definition of deliverables
  • Assignee
  • Estimate of effort required
  • Deadline

  • If a ticket is in a blocked state, then the reason why it is blocked should be made explicit