Skip to content

Instantly share code, notes, and snippets.

@h3h h3h/tires.md
Last active Dec 17, 2015

Embed
What would you like to do?
Kicking the Tires

Modifying Programs

When modifying a program, or when reviewing a modification of a program, you will want to consider at least the following:

  1. Tests
  • Is the modification tested?
  • Can you prove that the tests cover both the pre-modification and post-modification states of the program correctly? Do it.
  1. Interface
  • Does the modification change the interface of the code?
  • If so, are all possible callers prepared for the change?
  • What implications does the interface change have for versioning and dependencies?
  • Stepping back, is the new interface still well-designed as a whole (does the modification fit in)?
  1. Rules/Logic
  • Does the modification change the rules or logic of the program itself?
  • How is the program's data affected by the change in logic, both for callers (side effects) and downstream code?
  • Does the modification conform to the general style of code used elsewhere in the program?
  • Is the modification the simplest and most explicit way of achieving the result?
  1. Errors
  • What possible errors or exceptions can surface from the program's internal logic or operations (think divide by zero, internal validation checks)?
  • What possible errors or exceptions can surface from the program's dependencies (think network, DB, disk, memory, external validation, schema mismatch)?
  1. Storage
  • Is the program storing data in a datastore (or just local memory)?
  • If so, how much data is being stored?
  • Does the modification change the type or amount of data stored?
  • Is the program's data converted by the interface with the data store (e.g. Redis converting to strings)?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.