Quality and Defects

Quality and Defects

Bugs

  1. Errors are reported via Sentry. It has a plugin for Spring Boot.
  2. We have weekly triage meetings to address each issue in Sentry.
  3. Once we get through the backlog of errors we’ll change our workflow to a more proactive one.
  4. We’ll review this process as we go.

Error Triage

The Error Triage meeting will follow:

  1. Filter Sentry by ‘recent’.
  2. Each entry, zoom out to 90 days to see context.
  3. Create GitLab issue and link it to Sentry. Create Issue »
  4. The issue should take the form:
    • Malfunction. → GitLab ‘bug’ Issue, snooze for 1 week.
    • Bug in the code. → GitLab ‘bug’ Issue, snooze for 1 week
    • Application Notification. → This is likely a feature that should be raised to the Product team to be removed from Sentry workflow. Either the message should be included in a report for Product, or sent to the user, or instrumented some other way. Issue should mention that we remove the error message from the codebase.
  5. Check for confidential details before pasting.
  6. Link the issue to Sentry.
  7. Snooze the error in Sentry for a period, e.g. 6 months. We will use the GitLab issue to track.
  8. The Product Triage team will pick up and prioritise the issue. High priority issues should be marked as such.

Legacy to Greenfield

  1. We will gradually improve our Legacy codebase, but we won’t aim to make any fundamental changes.
  2. As we focus on services, we will extract the code or rewrite the service wholesale.
  3. If the code is simply extracted it will be classed as Legacy, but we will be in a better position to improve it. We will have to be tolerant of service boundaries being a little inexact.
  4. If it is re-written it will be classed as Greenfield.

Static Analysis

  1. We use SONAR for Java and Python.
  2. We use clj-kondo for Clojure.
  3. We will follow the rules to the letter for Greenfield projects. Sometimes they are cumbersome, but the benefit of a clean codebase nearly always outweighs the annoyance.
  4. IntelliJ has an excellent plugin which will flag things before they are picked up with CI and get quick feedback.

Code Review

These should be met before submitting for code review. Reviewer should also confirm as the first step of code review.

  1. Code should not be merged if:
    1. Tests don’t pass.
    2. For Legacy codebases, SONAR results should not have got worse.
    3. For Greenfield codebases, SONAR results should be green.
    4. They are not linked to an issue number(s) in commit messages. Click it to make sure it works.
  2. Review requirements in the linked issues / user stories. Make sure all functionality is represented by tests and implemented.
  3. If code needs fixing, make the change and resubmit:
    1. If the merge reduces the test coverage, remove unused code or refactor to write new tests.
    2. If there is behaviour that hasn’t been specified to the point where a unit test can be written, work with the Product Owner to clarify requirements.
  4. Check the ‘code review’ box on the relevant tickets. Review other developer actions on the ticket. Don’t move to ‘done’ until all boxes are ticked.

Style

We use standard style guides. Reformat your code before committing.

Java

  1. We use Google Java Style for Java. You can download it here and import into Intellij.
  2. Reformat your project before committing. In Intellij you can right-click on the project tree and ‘reformat code’.

Python

  1. PEP8 is the official Python style.
  2. Google’s YAPF tool can be used to reformat files. Use yapf -i -r /path/to/code.

Clojure

  1. We use Clojure Style Guide.
Edit Edit this page