If you're a "bit OCD" and about to embark on code reviewing your developers work, might I suggest you think about what your standards are and document/communicate them before bombarding devs with change requests? That makes the whole process less frustrating IME. Also, to begin with, you might want to ask yourself "Would i go and ask the person to change this after it was committed" as a self check as to whether stuff needs changed - just to ease people in, until those guidelines are fleshed out. You could well say you plan to tighten it up - and eventually rely on developers to review each others work.

Another process is a mini show and tell, where before each user story / feature is committed its shown in action to the person who requested it / QAs etc at the developers desk. Problems seen here may not even be the developers fault. A tendency towards reactionary defensiveness, and the recent goings on, might be best considered before doing this right now though. (It may well be you don't give the leeway you would a non family member for this as well.)