Rivedi e annota il codice

• Esamina DO , preferibilmente utilizzando uno strumento di revisione del codice. ^{(Altrimenti e-mail, ma ... meh).}

• giustifichi le tue osservazioni e i tuoi commenti.

• NON cagna su di esso.

Correggi il codice

• FACCIAMO a risolverlo :
  • se non hanno il tempo di farlo da soli,
  • dopo dopo averlo discusso con l'autore, o formalmente detto ad alcuni membri del tuo desiderio di sistemare alcune cose.
• Fai test per le cose che risolvi ^{(preferibilmente con test di unità e integrazione)}
• DO justify te stesso.

• DO prioritize:

  • Inizialmente inizia con alcune piccole cose per prendere l'abitudine e dimostrare che stai attento;
  • Ma poi FARE assolutamente le cose più importanti prima piuttosto che centinaia di piccole cose.

• NON aggiustare percorsi di codice poco chiari che non comprendi completamente.

• NON aggiustare percorsi di codice non testati che potresti interrompere inconsapevolmente.
• NON aggiustare i percorsi del codice in modo cieco. Le correzioni semplici sono semplici, ma l'errata digitazione di un simbolo o la presenza di un brainfart e l'inversione di una condizione booleana avvengono continuamente. Metti alla prova le tue cose.
• NON cagna a riguardo, ancora.
• NON infastidire gli altri e predicare in modo auto-giustificato .
• NON aggiustare problemi irrilevanti o irrilevanti ^{(inizialmente)} . Se non importa troppo, è probabile che tu abbia cose migliori da fare.
• NON sacrificare la coerenza .

In sostanza, NON diventare questo ragazzo fastidioso che tutti sappiamo che cambia solo gli spazi bianchi o gli stili di parentesi basati su una preferenza personale ma senza riguardo per la coerenza con il resto della base di codici, e che arriva addirittura a spaccare le build mentre aggiusta le violazioni minori del codice introducendo bug semplici ma profondamente nascosti.

Comunicare

• Contatta gli autori .
• FARE discutere le tue modifiche con gli altri (non necessariamente gli autori).
• Richiedi la revisione per i tuoi cambiamenti dagli altri; Questo:
  • mostra umiltà,
  • invita gli altri a saltare sul carro del carro,
  • mostra che si tratta di un processo fluido.
• FARE regole e convenzioni con i tuoi colleghi per evitare che questo problema si espanda e paralizzi il codebase nel tempo.
• FARE rapidamente la questione.

Chiedere

Chiedi. Piuttosto che dire "Sto aggiustando questo perché X", chiedi direttamente "perché lo hai fatto in questo modo, e come pensi che possiamo migliorarlo?" Se escono con qualcosa di meglio, allora inizia con quello e lavora insieme su qualcosa di ancora meglio. Se non lo fanno, allora fai un suggerimento. Se escono con qualcosa di meglio, o non capiscono perché è sbagliato, allora spiegano e pongono di nuovo la seconda domanda.

Fallo uno sforzo di squadra

È più probabile che la tua squadra salti sul carro del vincitore se effettivamente partecipi a questo. Se si tratta di un progetto di grandi dimensioni con una base di codice un po 'datata, è probabile che a loro non piaccia lo stato di decomposizione del codice, ma forse non si è mai preso la briga di fare qualcosa al riguardo.

Se hai il potere (o il supporto di quelli che lo fanno), può essere una buona idea organizzare piccoli sprint dedicati a migliorare la qualità del codice. L'impostazione di analizzatori di codice per rilevare gli odori del codice e monitorarne la diminuzione costante durante il refactoring è anche abbastanza motivante per una squadra.

Ovviamente, potrebbe essere un po 'più difficile per i team remoti, poiché è un po' più difficile trasmettere entusiasmo su queste cose senza lavorare veramente insieme.

Quasi tutto si riduce a quello.

Semantica

Inoltre, non confondere "politically correct" con "diplomatic" :

• Il primo riguarda la possibilità di non offendere la gente dicendo qualcosa che molto probabilmente sarà negativo.
• Quest'ultimo tratta di affrontare i problemi senza offendere le persone perché potrebbe esserci un contesto emotivo.

Sono cose molto diverse.

Domande correlate

• Come Posso suggerire con tatto miglioramenti ad altri codice mal progettato?

Parte della soluzione sta cambiando il modo in cui le persone vedono il codice. Ogni pezzo di codice appartiene a tutta la squadra, non solo alla persona che lo ha scritto. Se inizi a pensare al codice base in questo modo, non dovrai pensare a chi ha scritto il codice originale, perché appartiene a tutti.

Creare questo tipo di ambiente fa molto per far sentire le persone a proprio agio nel modificare qualsiasi parte del codice.

Parla prima!

Non ha senso fare cambiamenti che qualcuno, altrimenti, si arrabbierà e annullerà. È uno spreco del tuo capitale politico e del tuo tempo. Se sei il capo e puoi imporre nuovi standard, parla con il tuo team dei nuovi standard e implementali. In caso contrario, parla ai tuoi colleghi e magari al tuo capo prima di apportare modifiche.

Se parli con ciascun membro del team uno contro uno, puoi decidere quanto capitale politica sei disposto a spendere prima di accendere il fuoco davanti a tutta la squadra. Potresti comunque avere una riunione di gruppo come riconoscimento pubblico del consenso privato che hai ottenuto attraverso incontri individuali e come possibilità per le persone di commentare le nuove politiche di codifica prima di implementarle.

Con un consenso di gruppo, ognuno ha il compito di rendere il codice migliore. Non sei solo contro il mondo. Se l'accordo è irraggiungibile, non perderai tempo a combattere l'inevitabile.

Una base di codice in un ambiente di team distribuito è molto simile a Wikipedia; come si suol dire, "Se non vuoi che i tuoi post siano modificati spietatamente dal resto del mondo, non inviarlo".

Se c'è un modo migliore per scrivere un particolare pezzo di codice, e ne hai bisogno scritto in quel modo, allora scrivilo in questo modo. Se qualcuno si lamenta, ascolta il reclamo, ma se è principalmente sulla falsariga di "questo è il mio codice", spiega che è un membro di una squadra che sta lavorando alla base di codice nel suo complesso e nessuno può davvero rivendicare la proprietà. Ricorda inoltre che, legalmente parlando a causa dei documenti che ha firmato quando è stato assunto, è non "il suo" codice, è quello dell'azienda, e tu lavori anche per quella società.

Ora, ci possono essere problemi legittimi riguardo alla modifica dell '"interfaccia" del codice (il modo in cui gli oggetti codice appaiono e interagiscono con altro codice) senza prima consultare il team. Se qualcuno ha una copia funzionante, sta apportando il proprio set di grandi cambiamenti, basato pesantemente sull'interfaccia più vecchia, e tu entri e lo cambi sotto il loro naso, hanno un sacco di refactoring da fare. C'è una soluzione semplice a questo; manda una e-mail alla squadra dicendo "hey ho bisogno di cambiare questo codice, qualcuno sta lavorando su qualcosa in locale che potrebbe rompere la build se l'ho cambiata?". Aspetta qualche minuto e se qualcuno solleva un'obiezione, risolvilo in un canale di comunicazione più personale. In caso contrario, refactoring via.

È difficile descrivere cosa fare in una situazione come questa. La maggior parte delle persone che sono brave nel refactoring conoscono già la risposta e non devono fare la domanda. Immagino che tu stia ancora imparando, e se questo è il caso, ti aspetta un viaggio più lungo per la costruzione del personaggio.

Inizia in piccolo. Fai bollire la rana, non l'oceano.

Non dovresti refactoring solo per refactoring. Sicuramente imparerai molto più velocemente risolvendo casualmente le cose, ma il tuo ambiente non si nutre in quel modo. Invece stai 'cambiando il mio codice senza una buona ragione', e servirà solo a farti marchiare come una persona che divide: un cretino. Scommetto che stai già imparando su questo, ed è per questo che hai chiesto.

Codice di refactoring che è attivamente sulla tua strada. "Ho cambiato questo perché ho dovuto correggere un bug / aggiungere una funzionalità." Una volta che va bene per te, una volta capito che questo è il modo in cui lavori, passa al codice di refactoring che è discutibilmente nel modo. "Ho cambiato questo perché era più facile correggere un bug / aggiungere una funzionalità." Questo è quando inizi a entrare nella regola del campeggio, e spiegandola agli altri, e perché pensi che questo sia il modo in cui dovrebbero funzionare (piuttosto per favore con lo zucchero in cima). Cerca collaboratori, persone che ti lasciano armeggiare con il loro codice per renderlo più brillante.

Solo questi tre compiti ti terranno impegnato per molto tempo.

Un giorno, nel futuro remoto, potresti arrivare a spiegare il fenomeno delle finestre rotte, ma ti raccomando di non farti illusioni. Non dare per scontato che questa squadra arriverà mai lì, per la tua sanità mentale. Invece dovresti solo pianificare di salvare quella conversazione per il tuo prossimo lavoro, o anche quello successivo. Sii un consumatore informato durante il processo di intervista. Ti aiuterà a evitare questo scenario e vedranno che sei serio sul tuo mestiere.

Buona fortuna!