alt Hacker NewsBecause it's basically async pair-programming.
You do a lot of small changes (<100 loc) that get reviewed often. If it doesn't get reviewed often then the whole idea of continuous development breaks down.
Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc? After that 100 loc or maybe 200 take a break and review other people's code.
Plus you also have random meetings and stuff so your day already fragments itself so adding a code review in the time before a meeting or after is "free" from a fragmentation standpoint.
Replies
IMO code reviews are not pair programming. By the time I've raised an MR, it's already perfect. I've had multiple client calls, talked to my team about design, unit tested it, tested it on a container environment, thought about it.
So it really doesn't matter when the review gets done. I mean, even a week and it's fine.
> Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc?
I have an issue at work that will likely be solved by a single line change. But figuring out which line it is is going to take awhile.