Skip to main content
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