Timeline for What do you do when code review is just too hard?
Current License: CC BY-SA 3.0
51 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 16, 2018 at 20:19 | comment | added | luizfzs |
Create an issue on your favorite issue tracker for later
|
|
| Aug 15, 2016 at 17:11 | history | edited | Bradley Thomas | CC BY-SA 3.0 |
added 832 characters in body
|
| Jul 7, 2016 at 14:01 | history | edited | Bradley Thomas | CC BY-SA 3.0 |
added 23 characters in body
|
| Jul 5, 2016 at 7:08 | answer | added | Jules | timeline score: 0 | |
| Jul 5, 2016 at 4:37 | comment | added | code_dredd | I think the main problem is that people want to keep using credit cards and never pay back their debts. Maybe we should create the software-engineering equivalent of a debt collector. | |
| Jul 5, 2016 at 1:31 | answer | added | ChrisW | timeline score: 1 | |
| Jul 3, 2016 at 10:47 | comment | added | undo | 100th upvote! :D | |
| Jul 3, 2016 at 10:45 | answer | added | Peter | timeline score: 1 | |
| Jul 2, 2016 at 14:08 | comment | added | Fattie | You should never be doing some "huge change" to code. Just do a small job at a time. Alternately, and by all means, you should trash the project and start fresh, which is the norm in software. | |
| Jul 1, 2016 at 20:56 | comment | added | Bill K | @BradThomas There are a lot of good suggestions here--if you are having trouble figuring out how to start might I just suggest that you begin by adding unit tests until you fully understand the behavior of that section of code. Any code you can't unit test might be refactored (Pure, tiny refactors--no behavior changes even to bugs!) to make it testable. This can take a while but it makes a good foundation for both understanding the code and ensuring larger future refactors don't change behavior. | |
| Jul 1, 2016 at 16:23 | answer | added | Cort Ammon | timeline score: 0 | |
| Jul 1, 2016 at 12:09 | answer | added | h22 | timeline score: -1 | |
| Jul 1, 2016 at 11:17 | comment | added | Lightness Races in Orbit | Make it easier. | |
| Jun 30, 2016 at 16:43 | comment | added | ErikE | "We built this bridge for cars out of random boards, glue, nails, and scrap metal, but someone found a deep structural flaw that could make it fall down. How do we fix it? It could take longer to rebuild the bridge than it took to construct in the first place! And how can we know that when we rebuild it with more random boards, glue, nails, and scrap metal, that it won't have some new deep structural flaw that could make it fall down?" Isn't the answer proper design, architecture, and testing? | |
| Jun 30, 2016 at 14:00 | answer | added | Yakk | timeline score: 40 | |
| Jun 30, 2016 at 12:32 | answer | added | Greg Burghardt | timeline score: 0 | |
| Jun 30, 2016 at 12:23 | comment | added | Richard Ev | This sounds like the kind of code change that should not be attempted by a lone developer. Time for some pair programming maybe? | |
| Jun 30, 2016 at 1:05 | comment | added | Eric Lippert | @sleske: I am reminded once again of a lecture given by Brian Kernighan that I attended in my youth. He began by writing the number "1" on the chalkboard and said "number of hours of meetings per lines of code change at Bell Labs". I used to think he was kidding; now I'm not so sure. | |
| Jun 29, 2016 at 21:34 | comment | added | Daniel R Hicks | There is no magic answer. You review what you can, test what you can, and do a risk assessment on whether that's sufficient. At the very least review enough to identify some areas of concern that merit additional ad-hoc testing. (Note that here "risk assessment" means putting it on the head of management if they insist on plowing ahead without sufficient review/testing.) | |
| Jun 29, 2016 at 18:27 | history | edited | Bradley Thomas | CC BY-SA 3.0 |
added 7 characters in body
|
| Jun 29, 2016 at 14:57 | comment | added | xpmatteo | If you don't feel comfortable doing the review, you could ask the committer to discuss the changes with you. The committer should be responsible for convincing you that his or her code is OK. If he or she cannot do that, then the code is very likely not ready for production | |
| Jun 29, 2016 at 14:17 | history | edited | Bradley Thomas | CC BY-SA 3.0 |
added 323 characters in body
|
| Jun 29, 2016 at 13:56 | history | protected | maple_shaft♦ | ||
| Jun 29, 2016 at 13:56 | comment | added | maple_shaft♦ | For further discussion on the merits and drawbacks of comprehensive unit testing please visit our chat room. Comments should be pertinent to the question. Thank you. | |
| Jun 29, 2016 at 13:34 | answer | added | Graham | timeline score: 3 | |
| Jun 29, 2016 at 12:08 | comment | added | Mast |
Merge and hope nothing slips through? That's a notoriously bad idea.
|
|
| Jun 29, 2016 at 8:51 | comment | added | sleske | Your question seems to imply that it is "excessive" if the review/test of a change takes longer than performing the change. I don't think this is excessive at all. In environments demanding high quality, or for complex changes, it is not uncommon for review/testing to take an order of magnitude more time than the change itself. | |
| Jun 29, 2016 at 8:45 | answer | added | guillaume31 | timeline score: 14 | |
| Jun 29, 2016 at 8:13 | answer | added | gnasher729 | timeline score: 11 | |
| Jun 29, 2016 at 4:21 | comment | added | Kevin Krumwiede | This is an argument against writing complex, fragile code, not an argument against fixing issues identified during a code review. | |
| Jun 29, 2016 at 2:08 | answer | added | cristianoms | timeline score: 2 | |
| Jun 29, 2016 at 0:17 | review | Close votes | |||
| Jul 3, 2016 at 3:05 | |||||
| Jun 28, 2016 at 22:40 | answer | added | Eric Lippert | timeline score: 312 | |
| Jun 28, 2016 at 22:38 | history | tweeted | twitter.com/StackProgrammer/status/747922243393622016 | ||
| Jun 28, 2016 at 21:57 | answer | added | John Wu | timeline score: 15 | |
| Jun 28, 2016 at 21:02 | history | edited | gnat | CC BY-SA 3.0 |
removed uppercase to avoid perception of shouting
|
| Jun 28, 2016 at 20:47 | comment | added | Doc Brown | @MasonWheeler: I guess you are not thinking the same way about automated integration tests? That is probably sufficient for what the OP was asking for. | |
| Jun 28, 2016 at 20:27 | comment | added | Mason Wheeler | @RobertHarvey There was more than one link there. I've done it both ways too, and I consider the folly of unit testing to be self-evident. | |
| Jun 28, 2016 at 20:24 | comment | added | Robert Harvey | @MasonWheeler: Probably a conversation for another time, and you're referring to TDD specifically in that article, using assumptions that I don't think any self-respecting TDD'er would ever make, but I've done it both ways, and I consider the benefits of unit testing to be self-evident. | |
| Jun 28, 2016 at 20:21 | history | edited | Christophe |
added tag development-process as one of the proposed option is to replace review with additional tests
|
|
| Jun 28, 2016 at 20:19 | comment | added | Mason Wheeler | @RobertHarvey Meh. I've never been too shy about my position on the subject of unit testing: it's an idea that was known to be bad before it was formally invented, that lulls developers into a false sense of security, and on balance is generally a waste of time and effort. | |
| Jun 28, 2016 at 20:19 | answer | added | Robert Harvey | timeline score: 25 | |
| Jun 28, 2016 at 20:18 | comment | added | Christophe | The test suite would definitively help. But the peer review and tests are complementary. I think it's not a good idea to replace one by the other. | |
| Jun 28, 2016 at 20:08 | answer | added | JimmyJames | timeline score: 3 | |
| Jun 28, 2016 at 20:07 | comment | added | Robert Harvey |
what if there is no pre-existing test suite? -- How about writing one?
|
|
| Jun 28, 2016 at 20:01 | answer | added | Christophe | timeline score: 100 | |
| Jun 28, 2016 at 19:49 | comment | added | gnat | see also: How do I choose what code to review? | |
| Jun 28, 2016 at 19:45 | comment | added | gnat | possible duplicate of Should code reviewers test as part of the review? | |
| Jun 28, 2016 at 19:40 | comment | added | Bradley Thomas | Ok, fair suggestion, that would help, but what if there is no pre-existing test suite? Or the fragile code is mostly UI components, layout etc. | |
| Jun 28, 2016 at 19:32 | comment | added | Vincent Savard | What about running your test suite to make sure you didn't break anything? | |
| Jun 28, 2016 at 19:31 | history | asked | Bradley Thomas | CC BY-SA 3.0 |