Come dovrei implementare la revisione del codice in questa situazione?

Stai facendo anche il tuo QA? La tua situazione assomiglia molto agli ultimi 3 in cui sono stato, e sospetto che sia molto più comune di quanto sembrerebbe implicare tutta la documentazione sulle migliori pratiche (recensioni di codici, documentazione, SCM, ecc.)

Il mio contributo è che almeno hai l'altro ragazzo! Meglio di essere tutto su di te. Suggerirei a ognuno di voi di fare il QA sul codice degli altri ragazzi e di dargli una rapida lettura per essere sicuro che ognuno di voi possa capire ciò che l'altro ha scritto. Questo ti darà un codice migliore perché l'altro ragazzo che fa il QA potrebbe non fare le stesse supposizioni dell'autore e potrebbe catturare più bug di quanto lo sarebbe l'autore, e dal momento che ognuno potrebbe finire a lavorare sulle cose dell'altro ragazzo, si vuole garantire almeno un livello minimo di leggibilità / manutenibilità. Ho ereditato roba che era ottusa e appena documentata e l'unico modo per capirlo era di passare dolorosamente attraverso il debugger. Il codice leggibile / gestibile non è un lusso, è un investimento.

Sono d'accordo anche con gli altri ragazzi - la programmazione delle coppie potrebbe essere una buona idea e sicuramente ottenere almeno un SCM.

La prima cosa è ottenere un SCM di qualche tipo, anche se è semplicemente condiviso tra di voi senza alcuna forma di repo server centrale / dorato.

Quindi direi di installare Redmine e usarlo per tenere traccia delle richieste di modifica che ricevi, perché puoi puntare il redmine al tuo repository git e vedere le modifiche che sono state commesse, ma per far funzionare bene hai bisogno di un golden repo e un server per installare redmine on! Naturalmente, puoi farla franca con il tuo PC per questo compito, ma uno di voi dovrà essere il ragazzo che lo ospita - e quindi essere il ragazzo che "possiede" il repository definitivo. Presumo che questo tizio ti sia come te che ti interessa, e raccomanderei davvero questo approccio. Se hai paura di usare git, o non ti fidi abbastanza di gestirlo bene (dato che all'inizio potrebbe essere complicato e complesso), installa VisualSVN Server e fai in modo che l'altro si impegni a farlo - l'impostazione di SVN è più facile sia dagli strumenti PoV che concettualmente. Puoi sempre passare a git più tardi se ti rendi conto dei vantaggi e puoi forzare i flussi di lavoro richiesti all'altro ragazzo.

Questo ti consentirà di iniziare con le basi degli strumenti SCM, e forse in futuro potrai ottenere un server e fare qualcosa di più organizzato e "ufficiale".

Oh sì ... recensione del codice ... fino a quando non avrai più personale, fai revisioni manuali del codice - guarda il log delle modifiche di Redmine, fai doppio clic e ti mostrerà una bella differenza grafica delle modifiche da rivedere . Non c'è bisogno di uno strumento più formale che ti invi un messaggio di posta elettronica, di un bug ticket o di qualsiasi altra cosa con un link al diff in questo caso.

Requests are more "do what you need to do to hack together something that works ASAP, we need it in production tomorrow morning and we're only going to need it for a couple months

In base a questo, l'obiettivo delle revisioni del codice probabilmente non è un codice stabile e gestibile. Tuttavia, puoi comunque trarre profitto dalle recensioni del codice come mezzo per sviluppare ulteriormente le e le capacità di programmazione del tuo collega e per sviluppare una comprensione comune del problema. Come suggerisce @Mike, la programmazione della coppia sui specifici problemi potrebbe rivelarsi un modo molto efficace di utilizzare una sorta di revisione del codice nel tuo scenario. La programmazione delle coppie ti porterà a discutere gli approcci per risolvere un problema e quindi potrebbe aiutarti a "hackerare insieme qualcosa" con meno bug ancora più velocemente, il che è qualcosa che si traduce direttamente in valore aziendale.

Sono d'accordo con il suggerimento sulla coppia, tuttavia, se non puoi permettertelo, trovo che le recensioni di codici one-on-one pre-commit siano un buon compromesso in termini di collaborazione. Se non hai un sistema di controllo del codice sorgente e quindi non commetti, bene prima di tutto dovrebbe ottenerne uno (un DVCS nel tuo caso?) :) e nel frattempo tu è possibile eseguire queste revisioni di codici subito prima della versione, ovvero prima di pubblicare l'applicazione di installazione su un server, passare il modello di Excel con la macro aggiornata all'utente, ecc.

Ogni volta che un aggiornamento significativo e complesso di un programma è stato scritto e deve essere pubblicato, l'autore dovrebbe di sua iniziativa richiedere una revisione collaborativa completa di quel codice. Questo richiede tempo, ma ci vuole per diffondere la conoscenza tra tutti i membri del team, stabilire la proprietà collettiva del codice ed eseguire una prima verifica del controllo di qualità interno su ciò che viene prodotto.