Valore di mantenimento degli output di debug

Considerando che sei nuovo nel team, per prima cosa devi essere estremamente sicuro delle tue modifiche.

Gli standard aiutano in situazioni come questa. Parla con gli altri membri della squadra e scopri cosa è tipico del gruppo. Condividi i tuoi suggerimenti di qualità o efficienza apertamente con il team.

Se la tua squadra ha un accordo generale sul fatto che segmenti di codice sono "posseduti" da un particolare sviluppatore, chiedi loro di rivedere le modifiche al codice. È una buona pratica avere comunque un codice di revisione di qualcuno e questo è un ottimo modo per guadagnare fiducia ai nuovi membri del team.

Penso che l'unica cosa veramente sbagliata qui sono i parametri extra che sono usati solo per il debugging - non dovresti davvero cambiare la semantica della base di codice per eseguire il debug delle cose. Avere un sacco di output di debug è generalmente una buona cosa oltre a questo.

In termini di effetti operativi, molte dichiarazioni di Debug.Write () non fanno male a una mosca; vengono ignorati dal compilatore se non si passa il flag DEBUG in esso. E, a differenza dei tuoi breakpoint, sopravvivono con il codebase, quindi se hai una regressione non devi ricordare dove hai impostato il breakpoint e cosa stavi guardando. Mentre con l'output di debug avrai sempre la tua strumentazione.

Yuck, cancellali e quando ne trovi ancora qualche centinaia cancellali. Soprattutto se sono commentati. È improbabile che esegui il debug esattamente come ha fatto il tuo collega, tuttavia molti anni fa li ha aggiunti e tutto ciò che fanno è rendere ogni cosa più difficile da leggere.

Nell'interesse della pace sul posto di lavoro, potrebbe essere meglio chiedere prima al collega se va bene, visto che stai apportando importanti cambiamenti.

In fase di sviluppo, sì, l'uso di un debugger e l'analisi del codice, la visualizzazione delle variabili è il metodo preferito. È una questione di qualità del codice. L'aggiunta di variabili alle firme dei metodi e altri output di debug è confusa e introduce variabilità nel codice. Ci sono stati dei difetti che sono stati nascosti (o rivelati) solo perché è stata introdotta una variabile extra o è stata aggiunta una dichiarazione di stampa della console.

Tuttavia, c'è qualcosa da dire per l'uso del logging per acquisire informazioni di debug, a condizione che tale registrazione possa essere regolata al livello appropriato di verbosità. Di solito uso qualcosa come log4j e vari livelli di registrazione. Sulla base di ciò che sto facendo, aggiusto quel livello. Durante l'esecuzione e l'uso normali, accedo a INFO o WARN. Se eseguo il test, accedo a TRACE o DEBUG per ottenere ulteriori informazioni. Questo, insieme alla capacità di vedere le variabili e impostare i breakpoint è inestimabile.

La ramificazione potrebbe essere un'opzione per il controllo del codice sorgente? In questo modo questo sviluppatore potrebbe avere un ramo locale in cui può avere le sue uscite di debug senza inquinare la base di codice condivisa.

Tuttavia, a lungo termine, sarebbe bene mostrargli i benefici dell'uso del debugging di tipo breakpoints (uno a uno o durante un "Lunch and Learn") e questo gli dà la possibilità di mostrare i benefici del suo metodo, ma può essere complicato (ad esempio se si tratta di uno sviluppatore esperto che è ben ancorato a modo suo).