4 ms·
Saw this link here in the past. Didn’t pickup. The reason why I don’t like it is that random people, regardless their expertise, cannot just review PRs and unde
by niros_valtos 5y ago
Saw this link here in the past. Didn’t pickup. The reason why I don’t like it is that random people, regardless their expertise, cannot just review PRs and understand the impact of the change on the system without being deeply involved in the product.
- jopsen 5y agoNor can arbitrary people weigh the balance between accepting technical debt and shipping a feature. It involves a risk / benefit analysis. On the other hand, maybe you can build a relationship with contractors that focus on reviewing code. And maybe it can give insights your team won't have?
- rwmj 5y agoI'm a little more positive about this. A careful code reviewer might be able to spot generic security or even logic flaws in code, such as inappropriate use of strcpy in a C program or code which is unreachable in a way that cannot be detected by the compiler. Also there's a lot of scope for automation, such as running Coverity or other free and commercial linters/checkers, although also a danger of overwhelming the results with false positives and junk.
- niros_valtos 5y agoResults from these tools typically go to the developers, not to the PR reviewers. They see only the result of fixing a vulnerability, and if there is a new vulnerability introduced, these static code analysis tools should detected them before deployment to dev/prod.