Devo passare il tempo a pulire il mio codice una volta che funziona, se non è pulito? [chiuso]

Questa è l'idea alla base delle revisioni del codice: rendere il codice più pulito dopo che è stato eseguito, per mantenerlo disponibile. Ma immagino che nella tua azienda non si facciano nemmeno le revisioni del codice, altrimenti non lo avresti chiesto. Quindi inizia con quello.

Tuttavia, consiglio strongmente di evitare di ottenere codice troppo sporco in primo luogo. La prossima volta che aggiungi qualcosa a un codice esistente, prova a seguire il "principio boy scout": lascia il posto (codice) in una forma migliore di quella che hai trovato. Allora questa domanda diventa obsoleta.

La saggezza di investire tempo in codice che è "oltre funzionale" - più di quanto tu abbia bisogno di ottenere qualcosa per fare ciò che ti serve - dipende dal tuo ambiente particolare.

Codice One-Off

Se non hai mai intenzione di usare di nuovo il codice, spesso sotto forma di prototipi gettare via, prove di concetti, ecc., potrebbe non avere senso andare oltre il minimo necessario per portare a termine il lavoro. Gli hack sporchi possono essere un prezioso metodo per risparmiare tempo.

È una gara!

In alcune aziende, specialmente nelle startup, a volte arrivano seconde in "time to market" è solo il primo a perdere. Saltare un giro di finanziamenti perché non eri disposto a fare assolutamente tutto per ottenere la pietra miliare nel tempo minimo può a volte significare che sei appena uscito da un lavoro completamente. Quel codice è diventato un "one-off", perché probabilmente non verrà mai più utilizzato.

Ancora una volta, gli hack sporchi abbondano e potresti benissimo aver bisogno di buttare via quello che ti viene in mente per raggiungere l'obiettivo più immediato, se la tua compagnia sopravvive abbastanza a lungo da preoccuparsi del punteggio 1-2. Puoi pianificare un refactoring pesantemente, ricostruire se ciò che il tuo nuovo obiettivo è semplicemente non è compatibile con quello che hai (che è raramente una buona idea, ma può avere senso se hai davvero sbagliato su tecnologia / piattaforma, o tu stanno facendo un grande pivot strategico), o soffrono per il caos e rischiano di avere il debito tecnico sopraffare la tua capacità di rispondere alle esigenze del mercato / dei clienti.

Lo scrivi una sola volta, chiunque altro lo legge 100 volte

Specialmente quando ti trovi in una organizzazione stabile o in team di grandi dimensioni, un codice difficile da capire, difficile da leggere e in ultima analisi difficile da mantenere può essere una responsabilità molto costosa. Quando l'applicazione media ha una durata di 5-10 anni e sarà lavorata da decine di persone, risparmiando 1-2 ore del tuo tempo invece di pulire, migliorare la denominazione e documentare in modo appropriato, può facilmente costare un ordine di grandezza di tempo sprecato attraverso la durata dei codici.

Imparare ciò che è abbastanza buono è un'arte, un'abilità e un'asina selvaggia

Puoi sempre migliorare il codice. Non so di aver mai visto un codice che sia perfettamente eloquente, e il tempo necessario per produrlo regolarmente sarebbe probabilmente così proibitivo che non avrebbe senso in nessun ambiente. Per tutto il valore del mestiere, la maggior parte dei programmatori non vengono assunti come artisti eccellenti - più come gli artisti commerciali, dove le scadenze e i costi sono importanti. Ogni programma che scrivi non è un opus magnum, quindi devi trovare un equilibrio tra "Potrei renderlo migliore" e "è orribile, ma funziona".

Il giusto compromesso varierà per progetto, persona, squadra ed eventualmente anche per ora del giorno / settimana / mese / anno. Più ti eserciti sulla codifica pulita, più sarà facile produrla, quindi devi solo regolare il dial "più pulito / più veloce" per adattarlo alla tua situazione.

Nella mia esperienza, se il tuo codice non è pulito, non hai idea se funzioni "o meno". Il codice di pulizia che usi è parte per assicurarti che funzioni bene, non semplicemente cosmetico. È molto difficile vedere errori in condizioni limite, codice duplicato, codice raramente esercitato, ecc. In codice disordinato. Il codice di messaggistica è più difficile da testare. È più difficile eseguire il debug. È più difficile cambiare senza causare regressioni.

Il mio unico cavillo è che non dovresti aspettare di aver "finito" per pulire il tuo codice. Fallo lungo il percorso, una funzione alla volta, una lezione alla volta.

Sì

Puoi passare il tempo ora a pagare il debito tecnico , oppure puoi aspettare e passare molto più tempo in seguito risolvendo gli inevitabili bug.

No

A meno che la tua azienda non fatturhi per il lavoro, non farlo.

Risposta utente avanzata:

No

Avresti dovuto farlo la prima volta.