| Bluntly, this is the problem with code reviews: at the review stage it’s too late. Changes from this type of review are usually fine details (“use a constant for this”, “consider this edge case”, “prefer this style…”) that can be done easily by the reviewer with no context. If you’re lucky, you might get meaningful feedback (“consider using this approach instead…”), but many people just use code reviews as a gateway to merging code (1). This is the pragmatic approach; just trust the other developers and doing their jobs and do a light pass check to ensure that everyone is aligned on approach and style. ..but, that’s not what you were tasked with. You were asked to review the code, not the syntax. You cannot review code you do not understand. I’m sorry, but your mental parser does not run code. It does not render ui, update databases or generate concurrent race conditions. You may be able to approximate some of those, but most people can only do all of those things by actually running the code. So… you may get some value from looking at code; but I question, in almost all cases, if teams contributed significant value by doing so. [1] - see https://blog.jetbrains.com/upsource/2017/01/18/code-review-a..., etc. google “code review as gateway”. |