3 ms·
Ask HN: How do you give thoughtful reviews on code you've never seen before?
I am frequently tagged on code reviews for large (2000+ lines) changesets to portions of a large, complex codebase that I haven't even seen before, just because it's "frontend" and I am one of the frontend developers, and am supposedly therefore qualified by default to critique the code.
I find this very challenging, and sometimes spend long periods trying to figure out what the context is, what the existing code did, what the goals of the changes were, and how the author went about implementing those goals. This can easily take 3-4 hours or more depending on the code, if I'm saying anything more than "missed a semi-colon there." And often can result in a simple "looks good to me!," leaving me feeling like I wasted an afternoon.
How do you (or your company as a whole) deal with this problem?
- brudgers 10y agoTo me, three or four (or sixteen) hours on 2000 lines of code seems like a good business investment because: 1. A bug can easily consume that many staff hours and create orders of magnitude more losses than the cost of the staff time...and that's just if it is a bug rather than a vulnerability. 2. The reviewer learns the existing code base. 3. The reviewer learns the new code. 4. Peer review is part and parcel of sound engineering practice. To me, 2000 lines sounds like a large change set and reducing the size and scope of the change set and increasing the frequency of changes might help and is consistent with current industry trends toward process improvement. My random internet advice is to reframe 'looks good' as evidence that the process of code review is doing what is supposed to do. Not that I particularly like sports analogies, but the sign of a good team defense is what doesn't happen. One of the things that doesn't happen is 'its your fault not mine' when something bad happens. Good luck.