How to - Handle High Risk Work

How to - Handle High Risk Work

Why Is It a Problem?

High Risk Work creates a quality risk on your code base. When developers trying to merge a branch with many changes that include a high level of refactored code, it increases significantly the chance that "something will be broken".

First, the more code changes we merge back to the code base the higher chance some of it is not thoroughly checked and tested. Second, when refactoring a "big chunk" of existing code increases the chances that this legacy code is used or interacting with other parts of the code. The more existing code we are changing the higher the chances we are affecting other code that relies on this code and the less chances we will be able to check and test all the "affected" areas.

How to Handle?

In order to reduce the quality risk level that is introduced by a High Risk branch you can can do one of the following actions:

Assign more than one reviewer to review the branch -

The more reviewers reviewing this branches the better the chances that quality issues will be found and resolved. More reviewers also mean that there are better chances that other areas that might be affected by the changes in the branch, are areas that were written by one or more of the reviewers. This familiarity with other areas in the code might help reviewers finding "affected" areas 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 where the author of the PR talks about the implementation and the team members ask questions and suggesting were might problems arise according to their experience and understanding.

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 senior, the chances this person will catch up with quality issues is higher. Depending on the size and complexity of the branch, It is could be a good practice to select the 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 the the tests. Same is true for integration tests. If refactored code "breaks" integrations with other parts of the code, If the coverage of integration tests is high, there is a better chance that the tests will bubble the parts that were "broken" by the new code.

Breakdown the task to smaller subtasks

With exceptionally large branches reviewing and adding test coverage might become extremely difficult. In such cases it might be a good idea to breakdown 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".

How did we do?

Powered by HelpDocs (opens in a new tab)