Come devo fare per correggere il codice da un programmatore meno esperto?

19

Un po 'di storia: sono uno dei due programmatori per il nostro dipartimento di 10 persone (il resto sono artisti e management). Noi due facciamo tutto il codice necessario per far fluire bene le cose e sviluppare tutti i progetti che emergono. Ho programmato per circa 4 anni, dove questo è il suo primo "vero" lavoro (come lo dice lui). In genere stiamo lavorando a diversi progetti in qualsiasi momento.

Un paio di mesi fa ho sviluppato un insieme di classi (assolutamente non perfetto) che dovevano essere utilizzate per un progetto successivo. Gran parte di quel progetto gli è stato delegato (per motivi di fatturazione) per progettare e programmare un'interfaccia GUI. Da quando era nuovo, ho aiutato un po 'con la progettazione e ho detto di chiedere aiuto se ne avesse avuto bisogno con il resto. Ha terminato l'interfaccia poche settimane fa, che ha dimostrato che ha funzionato, anche se un po 'lento.

È iniziata la parte successiva di quel progetto a cui sto lavorando. Ho aperto l'interfaccia per iniziare con i passaggi successivi e ho subito riscontrato problemi (un po 'lento era un po' di eufemismo, errori su azioni comuni, ecc.). Ho esaminato il codice per alcuni problemi e sto trovando le O(n^n)chiamate che dovrebbero essere O(n), digitare ipotesi senza controllo degli errori (è in Python), riferimenti alla GUI aggiunta al codice originale e così via.

Ora, vorrei sicuramente insegnargli cosa non andava e come risolverlo, ma è già passato al suo prossimo progetto, e questo è successo poche settimane fa. Ho paura che dica "Torna indietro e fallo bene!" (con l'aiuto ovviamente) è troppo duro e nel frattempo abbiamo ancora altri progetti da realizzare. Dovrei semplicemente correggere il codice da solo per ora e provare a catturare le cose in futuro?

code-reviews bug

— TorelTwiddler
fonte

4

In futuro, c'è la possibilità di concordare linee guida per la codifica, che impedirebbero errori come hai descritto?

— Benni,

5

È una buona cosa che tu non stia correndo immediatamente verso la direzione e glielo dica. Alcune aziende sono orientate alla colpa. Mentre controlli le correzioni, trova un modo per raggrupparle e poi chiedi a questo ragazzo di guardarle in seguito. D'altra parte, anche un neolaureato non dovrebbe codificare nulla che sia a O(n^n)meno che non ci sia altro modo. Se lo fanno, probabilmente hanno ottenuto una C in algoritmi o non l'hanno presa o avevano un insegnante schifoso. Sfruttare una sorta di strumento per aiutare a trovare i problemi comuni sarebbe bello. Forse come compito successivo questo ragazzo può scrivere alcuni test delle prestazioni?

— Lavoro

Una O (n ^ n) senza documentazione sul motivo per cui è semplicemente sbagliato, punto. Se devi davvero farlo, i commenti dovrebbero spiegare meglio il perché.

— Loren Pechtel,

Stavo per scrivere che "ehi, O (n * n) non è poi così male, molte applicazioni lo richiedono ..." ma poi ho capito che non era un segno di moltiplicazione, ma un assassino ^!

— Max

O (n ^ n) può essere di una grandezza più veloce di O (n) se O (n) ha una costante enorme, e n è piccolo. codinghorror.com/blog/2007/09/… Poi di nuovo, n ^ n è estremo: D

— Coder

33

Sembra che istituire una sorta di politica di revisione del codice potrebbe essere utile su più livelli. Alcuni vantaggi immediati:

È possibile influenzare direttamente la qualità del suo codice prima di eseguire il commit del codice, mantenendo così alta la qualità della base di codice
Ti impedisce di fare errori simili che potrebbero catturare un'altra serie di occhi
In assenza di linee guida per la codifica, le recensioni portano naturalmente a coerenza nello stile di codifica
Condivisione della conoscenza. Se ci sono solo due di voi e uno viene colpito da un autobus ...

Ora, quando vai avanti e inizi a ripulire il suo codice, usalo come esercizio di insegnamento quando cerchi una revisione di questo codice. Farai rivedere le tue cose e potrebbe imparare come farlo meglio la prossima volta.

— nithins
fonte

3

La revisione del codice +1 è un ottimo modo per procedere. Suggerirei di formularlo di più sulla falsariga di "Ti dispiacerebbe dare un'occhiata ai cambiamenti che ho fatto per assicurarmi di non aver perso qualcosa" piuttosto che "Ecco come ho migliorato il tuo codice".

— Steve Jackson,

1

+1 Direi che la revisione del codice è molto più adatta di qualsiasi "linea guida per la codifica della regola d'oro". Non molte cose non vanno mai bene.

— Max

Mi piace davvero questa idea, grazie. Ora dovrò solo cercare un po 'di buoni modi per fare recensioni di codice!

— TorelTwiddler,

1

In realtà c'è un documento buono e divertente con alcune basi disponibili su mumak.net/stuff/your-code-sucks.html . Si tratta principalmente di tecniche comportamentali per lo svolgimento di revisioni in modo costruttivo, che è estremamente importante per le recensioni di successo.

— nithins,

@TorelTwiddler, ricorda solo che le recensioni di codice sono per l'apprendimento, non per la colpa. Sottolinea le cose che ha fatto bene, quindi sa che sono buone allo stesso tempo nel suggerire modi per migliorare.

— CaffGeek,

5

Non correggeranno mai e poi mai il loro codice, altrimenti non impareranno altro che se commettono errori, li prenderai e li riparerai. L'attività non viene eseguita fino a quando non viene eseguita . Sono stato davvero fortunato quando ho iniziato la mia attività professionale e il mio supervisore diretto ha ricontrollato tutto ciò che avevo commesso, e se ci fosse stata una soluzione migliore o avessi fatto un errore sciocco mi avrebbe detto, il che significava che le mie abilità erano migliorate, il che significa che sono migliorato più rapidamente e sviluppato una pelle più dura.

Lasciarlo scivolare genererà cattive abitudini, la correzione ora li farà affrontare meglio le critiche e triplicare il controllo prima di affermare che è stato fatto.

— Nicholas Smith
fonte

2

Possiamo dedurre che il progetto "funziona" e che è stato realizzato in un ragionevole lasso di tempo (anche se con alcuni problemi di progettazione grandiosi ma risolvibili)? In tal caso, ha una forma molto migliore rispetto a molti progetti che ho visto nel corso degli anni.

Penso che una maggiore comunicazione possa aiutare il tuo team - e questo potrebbe essere fatto con una revisione periodica del codice.

È positivo che tu sia sensibile all'essere "troppo duro" e penso che tieni a mente che la revisione del codice non deve essere un'esperienza demoralizzante in cui i giovani vengono grigliati e controllati. Può anche essere un modo per gli sviluppatori senior di dimostrare buone pratiche e per tutti ottenere fiducia l'uno nell'altro essendo educati e amichevoli anche in presenza di "errori".

Le persone imparano bene quando vedono l'aspetto di cose davvero buone. È meglio che sottolineare sistematicamente ogni piccolo difetto. O (n ^ n), tuttavia, dovrebbe essere sottolineato in modo gentile e costruttivo.

— Angelo
fonte

0

Condividi le tue conoscenze.

Gli offrirei aiuto per il suo nuovo progetto in cambio di alcuni insegnamenti da senior a junior.

Perché non accoppiare la programmazione su entrambi i progetti?

— mouviciel
fonte