Timeline for Agile Practices: Code Review - Fail the review or raise an issue?
Current License: CC BY-SA 4.0
7 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Oct 28, 2018 at 16:25 | audit | First posts | |||
Oct 28, 2018 at 16:25 | |||||
Oct 24, 2018 at 15:58 | comment | added | Martin Bonner supports Monica | @user3067860 If you've turned a 10 line function into a 3000 line function - then clearly fail. If you've turned a 3000 line function into 3010 - then probably pass. But what if you've turned a 100 line function (usually a bit too big) into a 300 line function (definitely too big)? | |
Oct 24, 2018 at 14:39 | comment | added | Frax | +1, though I think you should rephrase the last paragraph to make it stand out that checking in code with issues should be an absolute exception. I mean, just that someone is blocked is not enough excuse. Failing a single sprint doesn't look like enough excuse either, and certainly not an excuse that might be used repeatedly. | |
Oct 23, 2018 at 17:19 | comment | added | Dunk | In principle this answer is exactly correct. In practice.....If all the developers believe in and practice good coding practices balanced against effort then you'd likely not run into this issue very often and then this answer is spot on. However....it seems that there's always that one or two developers who do everything quick and dirty in order to save 5 minutes now; whereas they ignore the hours to days or months they are adding to work that will be later. In those cases, this answer is just a slippery slope to having to start over and redesign the entire system. | |
Oct 23, 2018 at 16:45 | comment | added | user3067860 | I think in this case the change was the overly long function--if you've introduced a 3000 line function that wasn't there previously (or was a 10 line function previously). | |
Oct 23, 2018 at 10:45 | history | edited | gnasher729 | CC BY-SA 4.0 |
edited body
|
Oct 23, 2018 at 10:39 | history | answered | gnasher729 | CC BY-SA 4.0 |