Le recensioni tra pari sono senza dubbio un ottimo modo per apprendere. Qualcuno potrebbe vedere qualcosa di diverso, hanno esperienze diverse per te e dovrebbero essere in grado di apportare miglioramenti. Questo non dovrebbe essere denigratorio, mi aspetterei che ogni sviluppatore sia in grado di commentare e criticare costruttivamente il codice di chiunque!
Mi sembra che alcuni di questi "miglioramenti" stiano effettivamente apportando cambiamenti radicali perché (come ci si aspetterebbe) lo sviluppatore di recensioni ha meno esperienza del software rispetto all'autore.
Questa tendenza è il feedback personale, forse il tuo codice è difficile da seguire o mantenere? Le tue recensioni sono preziose? Assolutamente! Riesco a vedere come può essere frustrante, avere un codice di lavoro che i tuoi pari sembrano rompere, non dovresti scoraggiarti - dovresti lavorare per proteggere il tuo codice contro questi cambiamenti.
La domanda diventa quindi come proteggere la funzionalità dei programmi in modo da sapere che la funzionalità è ancora funzionante dopo aver completato le recensioni. Il mio suggerimento sarebbe quello di garantire una copertura di prova unitaria decente. In questo modo ogni volta che tu / il tuo revisore / il tuo successore cambi il codice, puoi essere sicuro che le modifiche che hanno apportato sono sicure.
ETA: ho appena notato uno dei tuoi commenti, sono sicuro che questo è ovvio, ma le revisioni del codice dovrebbero essere fatte prima che il gruppo di test possa metterle le mani su. Altrimenti non stanno testando il prodotto finale.