Reduce the number of bugs - improve PRs quality

[molnard]

General Description

The latest release showed that we can accumulate a lot of bugs during the development. This was also required before that, but I failed to set up a testing team, a lack of luck and human resources - still, the problem stayed. The release was postponed by weeks until we went through and fixed them. Both code and UI contained issues. We are adding features, refactoring, and changing here and there the consequences are clear, mistakes will happen. It is risky to catch these bugs only in the testing period because some bugs can lead to a complete refactor of a module or class - that is causing a delays in the release.

The best point is to catch this right before the PR gets merged into the master. Otherwise, we will see numerous patches or even reverts.

We have numerous options, maybe more - this is open for brainstorming.

• Manual testing: it plays a critical role in improving the quality of pull requests (PRs) and ensuring that new code does not introduce bugs into the master branch. While automated tests can catch a lot of issues, they cannot fully replace the insights and detections that human testers can provide.

• Implement a Code Review Checklist: Create a checklist for both submitters and reviewers to follow. This list should include checking for coding standards, ensuring new code is covered by unit tests, verifying the functionality meets the requirements, and ensuring the code is readable and maintainable.

• Require Code Reviews: Make it a mandatory process that every PR must be reviewed by at least one or more team members before merging. Use tools like GitHub's protected branches to enforce this rule.

• Automate Where Possible: Utilize Continuous Integration (CI) tools to run automated tests, linters, and security checks on every PR. This can catch many common issues automatically before human review.

• Educate and Train Your Team: Regularly hold code review workshops or training sessions to discuss best practices, common pitfalls, and how to effectively review code. Encourage a culture of constructive feedback.

• Implement Pair Programming: For complex features or bug fixes, consider pair programming. It allows for immediate feedback and sharing of knowledge between team members.

• Use Feature Branches and Forks: Encourage developers to work in feature branches or forks and rebase frequently to keep up with changes in the master branch. This helps to reduce conflicts and makes PRs easier to review.

• Set Clear Coding Standards: Establish and enforce coding standards and conventions. This makes code easier to read and understand, reducing the cognitive load on reviewers.

• Encourage Small, Frequent PRs: Large PRs are hard to review effectively. Encourage your team to break work down into smaller, manageable pieces that can be reviewed and merged more quickly.

• Perform Regular Refactoring: Encourage regular refactoring of the codebase to improve code quality and maintainability. This makes future changes easier and less error-prone.

• Feedback Loop: Establish a feedback loop where the team can discuss merged PRs that caused bugs or issues and learn from them. Use these lessons to improve your processes.

• Pre-Merge Checklist: Before merging, have a final checklist that includes ensuring all automated checks have passed, manual testing (if applicable) has been done, and all review comments have been addressed.

• Use Feature Toggles: Consider using feature toggles for new features. This allows code to be merged into the master branch but not activated until it's ready, reducing the risk of introducing bugs.

• Documentation: Ensure that changes in PRs are accompanied by updated documentation if necessary. This helps maintain clarity and reduces the chance of misunderstandings.

• Promote a Culture of Quality: Cultivate a team culture that values quality over speed. Encourage taking the time needed to review PRs thoroughly and to write quality code.

Many of these we already have in some way or another.