A static archive of Markus Tacker's tweets. Follow me on Mastodon: @[email protected].
(p. 7) Correlation between code review process satisfaction and code quality
satisfaction: I would totally agree. Tested software does not automatically mean
that it is high quality (readable, maintainable). I can spot man problems in
implementation which have 100% test coverage.
(p. 11) 60% review tests: when I make a code review I rarely look at the tests,
because I can tell from the implementation how testable the code is. It provides
no value for me to look at the test also because I know the purpose of the
implementation.
(p. 13) Use CR for Knowledge Sharing: I don't think it is a good tool for that,
since it happens after the fact, the code has already been written and that
makes it harder to make bigger or fundamental changes (redo all work). Pair
Programming is best to share knowledge.
(p. 14) Benefit of Code Review: Adherence to Coding Standards/Conventions - I
try not to make that part of a CR, that should be catched by automated tools and
linters. I have these rules as pre-commit hooks in the projects and also as part
of the CI run.
(p. 16): "We have not enough time to do Code Reviews": it's the same as with
technical debt. Code Reviews take time but reduce technical deb.
(p. 18) Reports / Metrics: I would love to see Code Coverage from tests in Pull
Requests. Also interesting would be Copy&Paste detection - I have nothing
against duplicate & modify, but I discourage having exact copies of code.
This can be hard to spot in larger changes.