Timeline for Coworker thinks code review cost too much time
Current License: CC BY-SA 4.0
5 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Nov 15, 2019 at 16:08 | comment | added | Koenigsberg | What you are thinking of is a QA department that ensures quality after a process pipeline XY has been worked through. This is not anywhere close to how QA and specifically code reviews are done in practice. A common technique is review everything that is supposed to be commited to the master. See the four-eyes principle: unido.org/overview/member-states/change-management/faq/… | |
Nov 15, 2019 at 16:03 | comment | added | Koenigsberg | en.wikipedia.org/wiki/Code_review Read the very first sentence. QA is not "people", QA is a process. It may have people or even departments attached to it, but it is typically not at the end of a process, but applied during. | |
Nov 15, 2019 at 15:18 | comment | added | Strader | @Mär Code reviews are not connected to QA, most of QA people are not required to know environment product is developed in. If Function twice is working, the code can make to QA but not in to the repository. P.S. reviewing "Work In Progress" code IS meaningless and waste of time. Developer should concentrate on his task and not how it looks, When it works - then it can be reviewed and refactored. Perhaps you need to look up terms like "Gold plating" and KISS | |
Nov 15, 2019 at 15:04 | comment | added | Koenigsberg |
First of all, code reviews are part of the QA process. Second of all, features are checked using software testers, not code reviews. Why would you need a feature to be completed, when your review aims to eliminate stuff like, function xTwice( int x ){ return x + x; } , to present a naive example? Code reviews are neither done on singel commits, nor on whole features, but typically on merge requests into the master. Seems like the Sr. simply has no concept of the term technical debt.
|
|
Nov 14, 2019 at 15:19 | history | answered | Strader | CC BY-SA 4.0 |