Delivery Requirements

Do not let delivery requirements enforce rules to the culture of a team. A team should see the delivery requirements of the project and set a standard and expectations that fits that set of requirements. In it’s simplest form delivery requirements and a relaxed culture would enforce no rules, and merges can just go to main. Now this has it’s problems of course, but it is very effective if the individuals on the team are highly competent in the work that they perform and if the individuals in the team work to build on the skills of each other. At it’s most extreme delivery requirements would make a burden on the team, and make strict enforcements on the test coverage and code review.

Code Review

The goals of Code review are

  1. quality
  2. design
  3. bugs
  4. learning the code base for the team
  5. learning new things about the modules and coding paradigms of the languages that the team uses
  6. documentation for why decisions where made
  7. documentation for the description of the program and the code generated

Code review needs to be a process that checks the quality of the code, and the goals of the team. Not just the correctness of the code, and things that would cause errors in the program or create issues with the business or domain logic of the program itself.

The more involved people are with the code review the better. It’s a white board for ideas which can help create concrete code in the future. It provides the benefit of teaching the entire team how certain processes are designed and work, and the future progression of the program.

One should use code review as a guide to a “perfect” code base. Given the constraints of the real world, we can use PRs as a guide of the documentation that is created on why certain things were done a certain way.

A PR should have a detailed description of what the objective of the PRs, and answer any whys in the code. It is the job of the author and the code reviewers to ensure that this is done in a manor that will benefit the entire team. We do not want to move forward 3 years in the future and not understand the reasoning behind the decides made long ago, this is the place to let the future know about those decisions and whys.