Come gestisci il brutto codice che hai scritto? [chiuso]

Ottieni un altro lavoro e lascia che siano gli altri a occuparsene. Muahahahhahahaa.

.....

Sto scherzando. :)

Ma in tutta serietà: stimation padding è tuo amico. Generalmente faccio una stima realistica decente, quindi raddoppiamo. Questo potrebbe sembrare eccessivo, a volte lo è, ma è meglio sopravvalutare un po 'e anche guardare un po' lento a volte - piuttosto che lasciare cattive impressioni risultando codice buggato e sempre soffiando le tue stime. E naturalmente, tu incoraggi il debito tecnico lasciando che il codebase diventi hacky.

Un altro suggerimento (correlato): stimare sempre le attività apparentemente minuscole e non impegnative in un blocco di dimensioni decenti. Supponiamo, ad esempio, che un articolo di cui sei quasi sicuro sarà una semplice modifica di una riga di 30 secondi, assegnagli 1 ora (o forse qualunque sia il blocco temporale più basso sulla scheda attività o sul sistema CR, ad esempio 15 minuti / 0,25 ore) . E dai blocchi di mezza giornata o di 1 giorno per gli oggetti leggermente più grandi ma ancora relativamente banali.

La ragione di ciò è principalmente psicologica: trovo che se si abitua ad hackerare rapidamente piccoli cambiamenti, il lavoro si sente affrettato e non si finisce mai seduti a sedersi, a fare il punto e a riorganizzare le cose che devono essere refactoring. Inoltre, a livello pratico: a volte si verificano piccoli cambiamenti, ma non banali, e non si vuole sentirsi costantemente indietro rispetto ai programmi e spegnere gli incendi. È parte integrante del motivo per cui le basi di codice diventano hacky nel tempo.

Infine, ricorda sempre che le persone non devono sapere che stai un po 'riempendo le tue stime. Finché sei uno sviluppatore competente e stai esaurendo il lavoro a un ritmo decente, questa imbottitura non sarà evidente. cioè non dire al PHB "La mia stima iniziale è che ci vorranno due ore, ma dammi mezza giornata". Digli solo "Penso che ci vorrà circa mezza giornata". e lascialo lì.

Sovrastimare deliberatamente il tempo necessario per le tue prossime funzioni. Usa quel tempo extra per ripulire.

Non sarai mai in grado di giustificare la manutenzione, e il cliente ne ha bisogno a prescindere, quindi offri loro una medicina amara (costi leggermente maggiori per le funzionalità successive) in modo che possano migliorare.

Cerca di riprogettare correttamente integrando nuove funzionalità. Non c'è più tardi. Senza la riprogettazione, si aggiungono sempre più attriti per ulteriori modifiche e nuove funzionalità.

Ad un certo punto arriverete ad una fermata vicino dove tutto sembra richiedere anni. La maggior parte delle aziende, a questo punto, probabilmente optano per la grande riscrittura, la versione 2. Ha un'economia piuttosto scadente ed è un buon momento per i tuoi clienti di provare una festa di sviluppo diversa se si sentono inclini.

Una corretta riprogettazione / refactoring può proteggere gli investimenti dei clienti e mantenere le cose sostenibili. È necessario creare questo in. Ottimizza per il cambiamento, viaggiare leggero.

Con tutti i commenti sulla sovrastima, penso che ci sia una modesta quantità di punti (ben opportunità) che vengono persi.

Non si tratta di stimare il tempo impiegato a fare la modifica (solo) e quindi aggiungerne alcuni, si tratta di stimare il tempo necessario per modificare il codice (refactor!) per portarlo a un punto in cui la modifica può essere fatta quindi apportare il cambiamento (probabilmente un po 'munging insieme). Ok, questo equivale alla stessa cosa ... ma non si tratta di fondere o allungare o sovrastimare, si tratta semplicemente di dire che per fare questo ho prima bisogno di farlo e questo è quanto ci vorrà in totale. La chiave qui è che lavori su quelle parti del sistema da cui dipende il cambiamento e non più - se c'è un codice orribile altrove ... difficile, prendilo quando ci sei.

Per tornare alla domanda originale un po '- dopo molti anni è venuto giù per questo per me, quando realizzi qualcosa a meno che tu conosci (non credi, non ti aspetti (sospetto?) , non pensare ma sapere ) che sono necessari anche elementi aggiuntivi, quindi dovresti fare ciò che ti serve per implementare quel requisito e non più in modo più ordinato ed elegante che puoi.

Quando si arriva a implementare la prossima cosa - qualche tempo dopo - si prendono i passi necessari per portare la base di codici (e il database e qualsiasi altra cosa) allo stato necessario per implementare quella funzionalità in modo ordinato ed elegante come voi può. Questo refactoring è il punto in cui gestisci il disordine che sorge spontaneamente mentre un progetto si evolve, e si spera che eviti di creare più disordine (o almeno di mantenere il livello coerente).

Una delle aree di discussione qui è "Debito tecnico" - è come uno scoperto, devi ripagarlo e più a lungo lo lasci più interesse (in questo caso il tempo necessario per correggere) che maturi - che dà sei un buon argomento per passare un po 'del tuo tempo a minimizzare il debito tecnico.

Questo è anche il punto in cui i test unitari e altri test automatici iniziano a entrare (se potessi fare altrettanto bene come dico che sono abbastanza certo che sarei una persona più felice!) combinato con un server di build appropriato (che può essere eseguito almeno alcuni dei tuoi test). Combinati con quelli - ma di valore in se stessi - sono schemi come l'iniezione di dipendenza e l'inversione di controllo (mai abbastanza sicuro quanto siano "uguali" quei due) perché rendono più facile cambiare l'impianto idraulico e quindi affrontare i cambiamenti in l'isolamento.

Infine - ricorda, se non è rotto non aggiustarlo. Riordinare il tuo codice puramente per mettere in ordine può essere soddisfacente, ma è anche un'occasione per introdurre degli errori, mentre può essere doloroso se non hai bisogno di cambiarlo e non lo costruisci potrebbe essere meglio lasciare alcuni grumi da solo - l'opportunità di riparare o sostituire rotolerà alla fine!

1) Un adeguato controllo delle modifiche è tuo amico

Se il cliente cambia le specifiche va bene, è un suo diritto, tuttavia è una modifica e deve essere addebitata (o essere pagata in qualsiasi modo sia appropriata alla struttura / relazione del progetto).

La stima di tale modifica dovrebbe includere il costo del refactoring necessario . Il cliente potrebbe trovarsi a un costo elevato, ma a quel punto è necessario spiegargli che, poiché il codice è già scritto per metà, ci sono elementi che devono essere riscritti per garantire che sia solido e supportabile in futuro e che se non viene eseguito, è probabile che abbia problemi con il supporto futuro o che le modifiche diventino ancora più costose.

2) Il refactoring deve essere eseguito in modo tale da garantire al cliente vantaggi reali a lungo termine

Quando si prende in considerazione il refactoring, è sempre necessario prendere in considerazione ciò che è effettivamente necessario e ciò che è importante e assicurarsi che il lavoro di refactoring offra un reale valore a lungo termine per il denaro.

Dopotutto, dovremmo fare queste cose in modo che il codice rimanga estensibile e supportabile a medio / lungo termine per garantire che l'investimento del cliente rimanga valido piuttosto che per una spinta alla perfezione teorica. Il lavoro di refactoring (e le stime corrispondenti) dovrebbero essere fatti con questo scopo, e non solo perché ora pensi che ci potrebbe essere un modo leggermente migliore per farlo.

Alcuni programmatori suggeriscono che un modo per controllare il problema con i client è avere il segno del cliente e autorizzare la specifica iniziale. ALLORA, quando richiedono una modifica del requisito che non rientra nelle specifiche iniziali, gli comunichi che è necessario consultare il calendario del contratto e del progetto per calcolare costi aggiuntivi e ritardi, quindi creare un allegato al contratto. Apparentemente fa miracoli nel impedire ai clienti di insistere su nuove funzionalità (imprevedibili).

Ho il seguente commento in un codice base su cui sto lavorando attualmente:

/*
 * Every time I see this function, I want to take a shower.
 */

Lo so, molto bene la situazione che stai descrivendo. Quello che faccio è provare (il mio meglio) ad aspettare che le cose si calmino e ogni tipo di "strisciamento" abbia "insinuato" tutto ciò che sta per fare. A quel punto, probabilmente avrai rilasciato qualcosa di utile, e potresti richiedere del tempo per ripulire le cose e implementare le cose in modo un po 'diverso.

Non puoi andare in giro a ripulire ripetutamente un sacco di piccoli pasticci. Questo triplica solo il tuo lavoro e la frustrazione. Aspetta che diventi un pasticcio più grande, ma difficilmente in movimento e quindi puoi fare qualcosa al riguardo.

La mia preferenza è di evitare questa situazione in primo luogo.

Dipende tutto da COME leggi le specifiche. È facile pensarli come compresse di pietra, ma in realtà la maggior parte delle specifiche cambia. Quando si progetta il codice, prendere in considerazione la probabilità che ogni parte della specifica cambierà. Col tempo, sarai abbastanza bravo a prevederlo.

Essendo entrato nel caos, l'esperienza e il giudizio sono molto importanti. Stai scrivendo nuovi bug a causa di questo codice spaghetti? ci vuole più tempo per implementare? questi farebbero riferimento a un refactoring tattico.

per il futuro, sembra che tu debba lavorare in collaborazione con il tuo cliente. Dicendo loro, "guarda questo prodotto si sta espandendo significativamente oltre le specifiche originali, mentre il design originale era buono per quel livello, espandendolo in direzione X e le direzioni Y ha bisogno di un po 'di ristrutturazione nel design" gestito bene, e avrai anche il tuo cliente a pagare per questo.

Carica ogni ora e se vuole modifiche dirlo va bene, ma incorporare il tempo necessario per scrivere un buon codice nell'equazione. Ricorda inoltre che scrivere codice più ordinato paga a lungo termine quando devi mantenerlo. Risparmiare tempo ora potrebbe costarti più tardi.

Penso che scrivere software debba andare di pari passo con le esigenze aziendali. Se si tratta di un progetto "usa e getta" (come un prototipo che deve essere costruito in una settimana, con nuovi input in arrivo ogni giorno), non c'è bisogno di preoccuparsi della manutenibilità del codice e di altre cose - il tempo è cruciale e devi solo spingere il codice fuori dalla porta il più velocemente possibile.

Ma se stai scrivendo un'app a lungo termine, allora ha senso prendere in considerazione tutto questo, perché c'è un impatto considerevole sul tempo necessario per costruire nuove funzionalità, per correggere bug esistenti, per integrarsi in altre applicazioni e altre roba - e questo si traduce in impatto sul business (a causa di più tempo richiesto in seguito e più costi).

Quindi è meglio sensibilizzare chi prende le decisioni sui costi effettivi del codice di non refactoring quando necessario - nella mia esperienza, se i costi e l'impatto sul tempo di entrambe le opzioni sono spiegati in termini misurabili al proprietario della decisione, allora la decisione può essere un gioco da ragazzi. Non aspettarti che la gente ti dica 'Sì, vai avanti, scrivi un bel codice, anche se ci vuole il doppio del tempo e non mi dà alcun beneficio extra'. Semplicemente non funziona in questo modo.

Fallo parte del tuo processo, lo chiamo "refactoring estremo" e sarà grande! ;) Basta fare cose velocemente e quando sono state aggiunte abbastanza nuove funzionalità che c'è tessuto cicatriziale, refactarlo. Chiedi continuamente a te stesso "Ora se avessi iniziato da zero, come avrei fatto"

Le persone che pensano di poter progettare e pensare a tutto in anticipo si stanno prendendo in giro da sole, tu (e il tuo cliente) impari sempre le cose mentre vai avanti. Usa quelle lezioni.

Dato che sei un buon programmatore, sarai in grado di effettuare il refactoring abbastanza rapidamente e, mentre lo fai, il codice inizierà a prendere la sua "forma corretta", il che significa che diventerà più flessibile con meno dipendenze.

I clienti potrebbero essere seccati se sapessero che stai "perdendo del tempo" a rielaborare le cose, quindi aiuta a non chiedere / dire e ad essere molto veloce a riguardo.

Il codice sviluppato in questo modo ti farà risparmiare un sacco di tempo alla fine e renderà sempre più facile aggiungere nuove funzionalità.

Direi anche che uno dei più grandi motivi per il brutto codice è la paura che alcuni programmatori hanno di fare un refactoring strutturale più ampio, e più a lungo si aspetta e peggio diventa.

Fai affidamento su una potenza più elevata

Non intendo pregare. Voglio dire, assicurati che ci sia un uomo d'affari (ad esempio project manager o equivalente) che puoi inserire come padding tra te e il cliente. Se il cliente sta chiedendo troppo lascia che l'uomo d'affari metta giù il piede ed essere pronto a maneggiare "è fattibile, ma non sono sicuro che ciò rientri nello scopo della specifica, vedi [uomo d'affari]".

In un normale flusso di progetto, le specifiche generali dovrebbero essere congelate prima che avvenga un serio sviluppo.

Molti clienti continueranno a guidare per modifiche / miglioramenti / miglioramenti finché li lascerai. Molti abuseranno di questa capacità al massimo perché li fa sentire come se stessero ottenendo il massimo dai loro soldi (anche se sabotano il tuo progetto).

Avere una persona dedicata a perfezionare e congelare le specifiche in anticipo e applicarle in un secondo momento.

Non c'è niente di sbagliato nel fare un piccolo extra per un po 'di buon karma con il cliente, ma essere pronti a rimandare a una potenza più alta quando sfuggono di mano. Se la specifica richiede una quantità ridicola di modifiche, forse è il momento di tornare indietro nel ciclo aziendale e rivalutare il contratto e / o aggiungere aggiunte al contratto (con equo compenso monetario).

Il fatto che tu abbia questo problema ha poco a che fare con il codice. È un segno che il tuo project manager è sottoutilizzato nel progetto (che sia colpa tua, colpa sua o entrambi).

Come altri hanno già detto in molte risposte, è anche necessario aggiungere un buffer temporale per le eventualità su qualsiasi progetto, ma determinare che debba essere deciso a porte chiuse prima che la specifica sia congelata e consegnata al cliente dal PM.

La progettazione corretta iniziale non può aiutare a evitare il problema. Ed è quasi impossibile (o molto, molto difficile) considerare tutti i futuri requisiti "forse". Quindi dopo un po 'arriverà il Big Re-factoring. E la soluzione migliore è riscrivere tutto.

In poche parole: invece di montare una torretta sulla Ferrari rossa, ri-considera i requisiti e costruisci un carro armato.

Uccidilo con il fuoco.

Il refactore Aka non appena possibile: ad esempio quando il brutto codice deriva dal correre per una scadenza, sarei refactor dopo la scadenza perché non puoi (o almeno non dovresti) aggiungere più funzioni finché il codice esistente non è manutenibile, altrimenti renderà molto più difficile il debug dei futuri codici.

Scrivi test unitari per i tuoi progetti che testano lo stato corrente e poi refactoring quando hai tempo, in questo modo eviti di rompere il tuo progetto mentre stai cercando di ripulirlo.

Risposta più semplice. Vorrei smettere di scrivere codice di qualsiasi tipo, fino a quando non ha una specifica finale per esattamente ciò che lui / lei vuole sin d'ora.

Quindi devono dare la priorità a quell'elenco di funzionalità, ecc., per confermare quali elementi devono avere al momento e cosa possono essere fatti in seguito ....

Usando le tue esperienze per determinare quale sia il tempo / il costo di ogni funzione, e poi diglielo, se lo vogliono, ci vorranno x quantità di tempo e amp; i soldi.

Hai a che fare con il grande crimine di creep del feature scope, e continueranno ad aggiungere infinite funzionalità, fino a quando non avremo mai fatto nulla o non avremo fatto così male.

Dì loro che una volta che hai un elenco definitivo, che apporterai modifiche future, come preferiscono, ma devi concentrarti sui 15/20 principali che devono avere al momento.

Quindi, in base al tempo di completamento, di 'loro che dopo che questo è stato rilasciato, sarai aperto a discutere / a fare il brainstorming della prossima versione.

Una volta che è stata presa una decisione definitiva su ciò che deve essere fatto per la versione attuale, tutte le discussioni / idee / suggerimenti devono essere interrotte al 100%.

Se ottiene infinite idee, digli di scriverle, nella loro lista delle funzionalità per la prossima versione, e ti concentri sul fornire le funzionalità più importanti che vogliono in questo momento.

Se continuano a perdere tempo, continua a cambiare idea. Poi mi limiterei a lavorare sul progetto e a lavorare su altri progetti, fino a quando non avranno portato a termine le loro decisioni ..

È difficile da fare, ma la creep dello scope è così distruttiva di tempo, energia, motivazione e idee chiare.

Da una prospettiva completa del progetto:

Impara dal codice con il tuo team, vedi cosa può essere rielaborato e riutilizzato la prossima volta, quindi vai a bere una birra.

Da una prospettiva in sviluppo:

Spiega pazientemente perché lo sviluppo si è fermato e spiega perché non può continuare finché tutte le specifiche sono sul tavolo e comprese. Quindi, vai a bere una birra.

Da una prospettiva di pianificazione:

Richiedi tutte le specifiche in anticipo e collabora con tutti per avere una chiara comprensione del percorso di sviluppo. Coinvolgi il cliente / gli stakeholder il più vicino possibile per assicurarti che tutti siano sulla stessa pagina. Più tardi quella notte, prendi tutte le birre. Domani, inizia il progetto.