How to Address High Risk Work

How to Address High-Risk Work

What is high-risk work?

LinearB classifies high-risk work as branches with more than 100 code changes, and also over 50% of these changes are rework or refactor work.

Why is it a problem?

High-Risk Work can present a quality risk on your codebase. When branches are merged with a high number of changes, especially when this includes a high level of refactored code, it significantly increases the chance that "something will be broken."

• The more code changes we merge back to the code base, the higher the chance some are not thoroughly reviewed, checked, and tested.
• Legacy code often is used or interacts with other parts of your codebase in unexpected or unanticipated ways. Refactoring a big chunk of existing code increases the possibility that we are affecting other code dependencies and reduces our chances to check and test all the affected areas.

How to identify high-risk work.

From the Activity tab, click on the filters menu, and select High-Risk Work.

By default, this will identify branches that have over 100 code changes, and also over 50% of these changes are rework or refactor work.

Ways to remediate

In order to reduce the risk of unexpected bugs being introduced by a high-risk branch, you can do one of the following actions:

Assign more than one reviewer to review the branch

The more reviewers who are reviewing a high-risk branch, the better the chances that quality issues will be found and resolved.

Having more eyes on a high-risk branch also increases the likelihood that a reviewer has recently worked with a different branch that might have unexpected dependencies. Familiarity with other areas in the code can help reviewers find dependency issues and check them more efficiently.

Sometimes, it is also might be a good idea to take the review process "public" and have a session with the entire team. The author of the PR can discuss the code implementation and team members ask questions and suggest areas where problems might arise.

Assign a Team Leader or a senior developer to review the branch

Just like with multiple reviewers, if the person that reviews the branch is very familiar with your codebase, the chances this person will identify quality issues is higher. Depending on the size and complexity of the branch, It is a good best practice to select a reviewer based on her skill set and experience.

Increase test coverage of unit tests and integration tests

With high-risk branches, it is recommended to increase the level of test coverage in both unit tests and integration tests. The higher level of coverage, the higher the chances that issues that are introduced in the code will be caught by tests. The same is true for integration tests. If refactored code "breaks" integrations with other parts of the code, there is a better chance that the tests will bubble up the parts that were "broken" by the new code.

Breakdown the task into smaller subtasks

With exceptionally large branches reviewing and adding test coverage might become extremely difficult. In such cases, it is a good idea to break down the task that is covered by this branch and create multiple branches for different subtasks. Review, test and merge each part separately. This will improve the review and testing of each subtask.