• Code changes are stored in git
  • Setup continuous integration
  • Have a testing framework
  • Use dependency management
  • Define a code standard
  • Prefer function/method typing over dynamic types
  • On every push to git
    • Code quality check
    • Code style check
    • Unit/functional/integration/system tests
      • Code coverage should be recorded during tests and a report made available
  • A project repository must have a README.md explaining how to run the project on your own computer
  • A project repository must have a RELEASING.md explaining how to release the code
  • Responsibilities are made explicit in terms of roles
  • Critical roles, such as project lead, must have a backup/shadow individual
  • Setup telemetry, alerts, profiling, logging
25 May 2019

Reviewing code

History / Edit / PDF / EPUB / BIB / 2 min read (~331 words)
Software development Processes
  • 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
    • I've used traffic light color emojis to communicate 🔴 MUST, 🟡 SHOULD, 🟢 MAY
      • Another emoji based option is gitmoji
  • 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

  • Always prioritize your work
  • Always work on something that is a task in a task tracking system
    • You should always be able to tell someone else what task you are working on and link them to that task
  • Always provide an agenda when you book meetings with others
25 May 2019

Writing tickets

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

  • 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
25 May 2019

Writing code

History / Edit / PDF / EPUB / BIB / 1 min read (~59 words)
Software development Processes
  • Make sure you understand what you have to implement
  • Make it work
  • Write a test for what you implemented
  • Refactor the code for reusability/code standard
  • Verify that your code passes linting and tests
  • Commit your code on a branch
  • Push to the central repository
  • Verify that CI passes
  • Create pull request
  • Annotate code to explain intent of changes