Cosa posso fare per mantenere il rispetto di una base di codice scritta male? [duplicare]

Avendo lavorato con un certo C # veramente orrendo al mio primo lavoro, mi sono imbattuto in questo problema. Mentre me ne andavo, nel tempo che trascorrevo con lui ho preso la mentalità di trattare il codice come paziente.

Tutto il codice, non importa quanto orribile, WTF-driven, mal concepito, implementato in modo inadeguato o semplicemente cattivo era destinato dai suoi sviluppatori a risolvere un problema, con gli strumenti avevano a loro disposizione. Questo rende il codice buono? No. Questo lo rende meno doloroso? Assolutamente no. Ovviamente, la tua domanda non riguarda il dolore dello sviluppatore; Riguarda se puoi guardare questo codice giorno dopo giorno per tutto il tempo in cui lavori presso il tuo attuale negozio.

A tal fine, quando lavoro con il codice, lo vedo come un medico potrebbe: un'entità che sta esibendo i sintomi di un particolare tratto.

Chiamiamo i sintomi del comportamento corretto dei comportamenti previsti per la maggior parte del tempo ... tranne quando il ragionamento alla base del comportamento "destinato" è negativo. Quando si verifica questa circostanza, potrebbe essere utile riunire qualcosa che puoi presentare al tuo management per spiegare il comportamento che stai vedendo, e un processo ottimale che migliorerebbe il funzionamento dell'app, e infine il changeset minimo a modificare quei sintomi . Se tutto va bene, approveranno e ti permetteranno di fare ciò che uno sviluppatore fa meglio: lascia il codice in condizioni migliori di quanto lo trovi. Altrimenti? Potrebbe non essere così male, potrebbero avere solo un motivo commerciale (troppo poco tempo, troppi pochi soldi).

Quando incontro i sintomi di un comportamento involontario, preferisco seguire qualsiasi flusso di lavoro di segnalazione degli errori nel mio negozio; è il modo più rapido ed efficiente per informare i tuoi dirigenti dei problemi che affliggono la tua app. Nel mio primo lavoro, ci sono stati alcuni problemi che non abbiamo avuto modo di affrontare per circa due mesi a causa della natura del settore in cui operiamo, ma non segnalarlo (o peggio, apportare modifiche canaglia) avrebbe avuto un lato molto peggiore -effetti, che porta ad un rispetto ancora inferiore per la tua base di codice.

Ancora meglio, prova a trovare modi costruttivi per convincere i tuoi manager ad accelerare il processo a cui i bug rispondono (questo era un problema in quel mio primo negozio), perché più a lungo sai che un bug è in circolazione meno il tuo rispetto per il codice sarà alla fine della giornata. Il morale conta!

Quando vedo codice malformato che non corrisponde agli standard per il linguaggio, non incolpo il codice per essere stato malformato, ma considero lo sviluppatore che lo ha scritto; forse non hanno familiarità con la lingua? (Ho incontrato questo caso con un collega che non aveva esperienza di programmazione, ma una ricca storia come tester manuale: questa persona ha scritto un codice copia / incolla veramente orribile che mi ci è voluto settimane per stabilizzare.)

Quando incontri questo caso, hai due opzioni. Se lo sviluppatore è lì e in un facile accesso, renditi disponibile come risorsa didattica; puoi influenzare questa persona per scrivere codice per gli standard della tua lingua e del tuo negozio. Aiutali ad essere uno sviluppatore migliore, è probabile che stiano vivendo un momento difficile, ma stanno facendo una faccia dura e stanno facendo una smorfia proprio come te. Meglio ancora, puoi dormire sonni tranquilli sapendo che i volumi di codice scadente saranno decrescenti nel tempo, il che è sempre il benvenuto.

Se la persona non è in facile accesso, o se ne è già andata, quando una scusa per rivedere il codice appare in modo positivo, a basso rischio, prendila. Stai facendo la tua organizzare un favore essendo il cambiamento che si desidera creare.

Se in poche settimane hai provato tutto questo e non hai ancora notato alcun miglioramento per la tua considerazione della tua base di codice, e per il trattamento da parte degli altri, non c'è niente per questo: non dovresti supportare qualcosa che odi, come farai sotto-par come per far peggiorare tutti i sintomi di cui ho appena parlato. Ma, prima di iniziare a chiacchierare con quel reclutatore, rendi assolutamente sicuro che hai esaurito ogni opzione per migliorare la base di codice e per fare in modo che i tuoi colleghi facciano lo stesso. Immagino che se ti credi in questo dolore, questo non può essere piacevole per loro, neanche!

A volte devi capire queste cose nel contesto in cui sono state inserite, poi integrate, quindi mantenute.

Alcuni dei criminali peggiori che ho visto probabilmente hanno iniziato come programmi scritti molto bene. Puoi vedere un po 'di architettura ben pensata che cerca di emergere attraverso il caos. Ma come è successo, i requisiti cambiano durante la fine della build iniziale, quindi alcune cose diventano un po 'sciatte, per garantire che le scadenze siano rispettate, ecc ... Quindi il team iniziale di appaltatori passa al team di sviluppo interno che ha un modo diverso di fare le cose. Quella squadra potrebbe avere una dozzina di persone e, con uno o due membri che girano ogni anno, e con persone diverse che cambiano il loro focus sul sistema, è facile capire quanto velocemente e facilmente una buona base di codice possa diventare un abominio. Quando ci sono arrivato, era pieno di tutti i tipi di "WTF" e di eccentricità. Alcuni di essi non avevano senso, alcuni erano anti-pattern chiari, alcuni dovevano risolvere problemi specifici della piattaforma con uno specifico componente del fornitore che potrebbe avere o meno problemi nelle versioni attuali (ma nessuno ha avuto il tempo di testare e il codice attuale funziona in modo che nessuno voglia pasticciarlo).

Almeno è così che si sono evoluti gli orribili gruppi di codici legacy sui quali ho lavorato. Naturalmente c'erano probabilmente molte cose che avrebbero potuto essere fatte in molti di questi cicli per mitigare il fattore WTF, ma se ciò fosse accaduto allora non avrei nulla da scrivere. ;)

Per quanto riguarda il lavoro: pensavo al mio lavoro su uno di quei sistemi come un aereo da caccia con battito di precisione: vola veloce e veloce su un terreno ostile e consegna quella piccola linea di codice che fa saltare l'insetto a pezzi. A volte è stato più divertente pensare al processo di correzione più lungo e più complesso come un mistero di Sherlock Holmes: il caso del messaggio in coda confuso (o qualcosa del genere).

Bene, stai indirizzando molta energia verso un oggetto inanimato. In realtà mi occupo di esso assaporando la sfida, nel concorso stesso. È come affrontare un avversario sul campo sportivo. Vuoi vincere. Sono un ostacolo a vincere, ma non li odi per questo.

La prossima cosa che faccio è una fase di refactoring prima , mentre sto ancora cercando di capire il codice. Se il mio cambiamento deve andare in una funzione di 1000 linee, suddivido quella funzione. Se c'è un codice di codice ripetuto dappertutto, lo estraggo nella sua funzione. Sostituisco i numeri magici con le costanti nominate. Non sto parlando di rielaborazioni importanti che richiedono una profonda comprensione del codice, solo semplici trasformazioni che possono essere applicate quasi meccanicamente.

A quel punto, sono pronto a fare il mio cambiamento, ed è molto più facile farlo, di solito più che compensare il tempo impiegato per il refactoring. Alcuni dei miei lavori migliori si concludono con una perdita netta di linee di codice, anche quando ho aggiunto nuove funzionalità. Quando sto affrontando una battaglia in salita, cerco di ricordare quanto mi sentirai bene quando finirò.

Forse non c'è orgoglio nel codice, ma non l'hai scritto. Ciò che puoi riconoscere per te è rendere l'esperienza utente migliore rimuovendo i bug. Non glorioso, ma gli utenti ti ameranno per questo.

Inoltre, lasci il codice un po 'meglio per il prossimo.