Come si fa a passare un programma dallo sviluppo allo sviluppo?

Ad un certo punto è in fase di sviluppo un programma. Le funzioni vengono aggiunte o rimosse o modificate continuamente. Ogni versione non è altro che un prototipo. Quindi non perdo molto tempo a scrivere codice super pulito a quel punto perché non so mai quanto dura qualcosa. Certo, cerco di mantenere la qualità del codice su determinati standard, ma il tempo è sempre un problema.

Poi arriva il punto in cui il programma è finito e il / i decisore / i dicono "questo è tutto". Ho un prototipo funzionante a questo punto, ma il codice all'interno è un po 'disordinato da tutto il avanti e indietro durante la fase di sviluppo. Mi aspetto di iniziare il test / debug finale, ma il mio istinto dice che ora dovrei in qualche modo ripulire e riscrivere le cose per dargli un'architettura adeguata che renda più facile la manutenzione, ecc.

Una volta che le cose sono state testate e approvate, non ha senso riscrivere allora. Su base regolare mi trovo lì con un prototipo "finito" funzionante e ricevo un bug durante i test e vedo che è il risultato di una codifica non intelligente che è il risultato dell'intero processo di sviluppo. Sono nel mezzo del test e la correzione di bug sarebbe una riscrittura ... è un casino!

Ci sono modi migliori / da manuale, ne sono sicuro. Ma devo lavorare in un vero ambiente di lavoro dove non tutto è un libro di testo.

Quindi, come posso trasferire il mio prototipo funzionante a una versione di rilascio con una base di codice stabile? Forse non dovrei considerare lo sviluppo finito una volta che lo faccio e in realtà vederlo come la fase di pulizia ... Non lo so, ho bisogno di aiuto qui.

MODIFICARE

Voglio chiarire alcune cose.

• Sono al 100% dalla parte del farlo prima e non dopo, il codice è pulito e leggibile. Ma devo anche fare le cose e non posso sognare la bellezza del codice tutto pulito e brillante. Devo trovare un compromesso.

• spesso una nuova funzionalità è davvero solo qualcosa che vogliamo provare e vedere se ha senso implementare qualcosa del genere. (specialmente nelle app mobili, per ottenere un aspetto reale su un dispositivo reale) Quindi è qualcosa di piccolo che (imho) non giustifica troppo lavoro in una prima iterazione "vediamo". Tuttavia a volte sorge la domanda QUANDO devo pagare questo tech.debt? Ecco di cosa tratta questa domanda.

Se so che la metà delle funzionalità verrà abbandonata il giorno dopo (esperienza sufficiente nella nostra azienda ormai) trovo davvero difficile credere che il modo migliore per affrontare il mio problema sia comunque investire tempo extra per scrivere tutto pulito anche se la maggior parte verrà abbandonata poco dopo. Mi sembra che risparmierò tempo se faccio una grande pulizia una volta che la cosa è solida, quindi la mia domanda.

Quindi non perdo molto tempo a scrivere codice super pulito a quel punto perché non so mai quanto dura qualcosa.

Non sapere quanto dura qualcosa non dovrebbe mai essere una scusa per la sciattezza, anzi il contrario. Il codice più pulito è IMHO quello che non ti ostacola quando devi cambiare qualcosa. Quindi la mia raccomandazione è: cerca sempre di scrivere il codice più pulito che puoi, specialmente durante la codifica di un prototipo. Perché sarà molto più facile adattarlo quando qualcosa deve essere cambiato (cosa che sicuramente accadrà).

Non fraintendetemi: la mia comprensione del "codice più pulito" non ha nulla a che fare con la bellezza del codice per motivi di bellezza. Questo è davvero qualcosa che può rallentarti. Dal mio punto di vista, il codice pulito è un codice che è per lo più autoesplicativo (non c'è bisogno di scrivere così tanti documenti - causa speedup), facile da capire (meno errori, quindi meno debugging necessario - speedup, meno tempo necessario per trovare il corretto posto da modificare - speedup), risolve il problema dato con la minima quantità di codice necessario (meno codice da debug - speedup evidente), è DRY (solo un posto dove cambiare quando qualcosa deve essere cambiato - speedup - e meno rischi da introdurre nuovi bug dimenticando di cambiare un secondo posto), segue gli standard di codifica (cose meno ingombranti a cui pensare - speedup), usa piccoli,

Mi aspetto di iniziare il test / debug finale, ma il mio istinto dice che ora dovrei in qualche modo ripulire e riscrivere le cose per dargli un'architettura adeguata che renda più facile la manutenzione, ecc.

Fare "pulizia" in seguito non funziona mai. Prendi in considerazione la pulizia prima di implementare una nuova funzionalità o quando inizi a implementarla, ma non in seguito. Ad esempio, ogni volta che inizi a toccare un metodo per una funzione e noti che supera le 10 righe, considera di rifattorizzarla in metodi più piccoli, immediatamente , prima di completare la funzionalità. Ogni volta che rilevi una variabile esistente o il nome di una funzione che non sai esattamente cosa significhi, scopri a cosa serve e rinomina la cosa prima di fare qualsiasi altra cosa. Se lo fai regolarmente, mantieni il codice almeno in uno stato "abbastanza pulito". E inizi a risparmiare tempo , perché hai bisogno di molto meno tempo per il debug.

Sono nel mezzo del test e la correzione dei bug sarebbe una riscrittura

... che è la vera prova di ciò che ho scritto sopra: essere "sporchi" ti perseguita immediatamente quando inizi a eseguire il debug del tuo codice e ti rallenterà.

Puoi evitarlo quasi completamente se esegui la pulizia immediatamente. Quindi le correzioni di bug significheranno principalmente piccole modifiche al codice, ma mai una grande modifica architettonica. Se si rilevano realmente prove di un miglioramento architettonico durante il test, lo si ritarda, lo si inserisce nel sistema di localizzazione dei problemi e lo si implementa la prossima volta che si deve implementare una funzionalità che beneficia di tale modifica ( prima di iniziare con quella funzionalità).

Ciò richiede un po 'di disciplina e, naturalmente, alcune esperienze di programmazione. È un'idea simile all'idea alla base dello "sviluppo guidato dai test", che fa prima queste cose invece di farle successivamente (anche il TDD può aiutare, ma quello che ho scritto funziona anche quando non si usa il TDD). Se lo fai di conseguenza, non avrai bisogno di alcuna speciale "fase di pulizia" prima di rilasciarla.

Hai due problemi separati, entrambi con lo stesso sintomo (codice sciatto):

Problema n. 1: controllo dei requisiti insufficiente Non intendo che i vostri stakeholder cambino i vostri requisiti troppo frequentemente, intendo che state permettendo cambiamenti ai requisiti durante un bugfix / ciclo di test. Perfino le metodologie agili non lo supportano; costruisci, collaudi, fornisci, inietti nuovi requisiti.

Problema n. 2: credi che le cose che stai scrivendo siano "solo per ora" nello sviluppo di software "solo per ora" il codice è davvero estremamente raro. Ti sei accorto che una volta soddisfatto un requisito dell'utente, i rigori della domanda e dell'offerta rendono molto difficile giustificare il ritorno e la reimplementazione di una funzionalità "completata". Quindi, cosa fare al riguardo? Scrivi sempre il codice di produzione. Funzionalmente per te, ciò significa che le stime per i tuoi stakeholder devono essere sostanzialmente più grandi, quindi hai del tempo per farlo nel modo giusto.

Inoltre, ti preghiamo di comprendere che stai lavorando nella posizione più difficile come sviluppatore: leggi la versione di Joel Spolsky sulla vita di uno sviluppatore interno . Quindi, devi essere molto vigile se vuoi arrivare intatto con la tua sanità mentale.

È un problema comune, specialmente quando si crea quello che è essenzialmente un fumetto di prova software per così dire.

Esistono diversi approcci che possono aiutare. In primo luogo l' approccio TDD può aiutare a ridurre la base di codice a ciò che è strettamente necessario. Se i tuoi test vanno di pari passo con il tuo codice, puoi almeno avere la certezza che il tuo codice si comporti come dovrebbe.

Prenditi del tempo per refactoring mentre procedi. Una volta che hai un prototipo e il cliente è ansioso di metterci le mani sopra, è una vendita difficile dire che hai bisogno di tempo per lucidare ciò che (per loro) è completo. Mi piace fare il check-in su base giornaliera, seguito da un check-in di refactor ma YMMV.

Gli sviluppatori che scrivono rapidamente il codice sono spesso richiesti: avevamo un tale sviluppatore nel mio ultimo dipartimento. Ogni squadra lo voleva perché lavorava molto velocemente. Una volta giunto il momento di testare e rilasciare il suo codice, tuttavia, le ruote si staccarono rapidamente. Roba codificata, hack e scorciatoie ovunque. Le sue azioni sono presto diminuite - in modo massiccio.

Tagliare il codice di produzione fin dall'inizio può sembrare una seccatura, ma a seconda del tuo ambiente, ci sono molti strumenti che possono eliminare lo sviluppo come Ghostdoc e Stylecop .

Vale la pena entrare fin dall'inizio nella giusta mentalità di sviluppo. Sareste sorpresi da quanti sistemi back-of-a-fag-packet che avrebbero dovuto essere solo soluzioni stop-gap diventano applicazioni fondamentali.

Continuamente

La velocità di sviluppo è la ragione principale per scrivere codice pulito, leggibile e testabile; non è fatto per la bellezza, né per altri valori astratti. Perché dovrei negarlo a me stesso e farlo solo in seguito per qualche futuro programmatore?

Certo, potrebbero esserci cambiamenti che sono per lo più cosmetici e quindi non essenziali; Direi che è molto più utile avere un codice moderatamente carino in questo momento, durante lo sviluppo, che avere un casino in questo momento e sperare di renderlo perfetto più tardi (il che, ammettiamolo, non accadrà mai, anche se tu avessi il tempo).

Puoi farlo differenziando tra il codice "Sto solo provando questo per vedere come funziona" e il codice "Questo è diretto nel prodotto". Esistono diversi modi per farlo.

Uno sta ramificando o qualunque sia la parola nel tuo sistema di controllo del codice sorgente. Si crea un ramo per il nuovo report o il nuovo layout di importazione o altro. Se alla gente piace, il compito di riportarlo nel ramo principale è un lavoro separato e tracciabile. Può essere assegnato a qualcuno e segnalato e non si prevede che accada magicamente il giorno in cui la direzione (o le vendite) concorda sul fatto che la funzionalità appartiene al prodotto.

Un altro è picchi. Non fai questo cambiamento nel prodotto. Vai in un'app separata, super semplice, che esiste solo per te per avere un posto dove mettere il codice. Puoi essere disordinato quanto vuoi perché stai solo esplorando la nuova API o qualsiasi altra cosa. E ancora, se torni e riferisci "sì, possiamo farlo, ho capito come" esiste un compito tracciabile, riportabile, assegnabile di scrivere codice pronto per il prodotto nel prodotto per fare quello che vuoi.

In entrambi i casi, pronto per il prodotto significa leggibile, pulito, secondo gli standard di denominazione, con test e aderendo allo stile del codice e agli obiettivi prestazionali. In entrambi i casi, rendi visibile quel lavoro. Sono d'accordo che non vuoi fare tutto ciò che funziona ogni volta che è molto probabile che qualcuno torni indietro la funzionalità dal prodotto. Ma non vuoi nemmeno rendere quel lavoro invisibile. Lavorare in copie separate del prodotto o in un prodotto non correlato che è a malapena più di un cablaggio di prova consente di far emergere il lavoro per creare codice pronto per il prodotto una volta che qualcuno decide di voler qualcosa.

Il rovescio della medaglia è che non possono decidere di volere qualcosa e spedirlo (intendendo la mezza versione semiaffacciata, disordinata, non testata, non documentata, possibilmente lenta che hai implementato come prova di concetto) domani. La prima volta che ottieni pushback su quel fronte, chiedi semplicemente se dovresti farlo nel modo più lungo (più costoso) ogni volta, nel caso, rallentando il percorso verso le funzionalità rifiutate. Se lo chiedi correttamente, otterrai un "no".

Davvero penso che tu capisca già il problema. Il problema è che il tuo stile di codifica ti richiede di fare troppe rielaborazioni. Il motivo per cui è necessaria una rielaborazione eccessiva è perché (a) è combinato con una previsione e una pianificazione insufficienti e (b) le patch incrementali a breve termine che vengono regolarmente inserite durante lo sviluppo aumentano in modo combinatorio la complessità di qualsiasi rilavorazione richiesta.

La risposta quindi è:

(a) sposta il tuo stile di sviluppo un po 'più verso la cascata e un po' meno agile. Non andare fino in fondo però, perché la classica cascata ha le sue insidie. C'è un sano equilibrio da avere. So che a volte può interessare solo pensare alle cose per qualche giorno, come se non si stesse realizzando alcuno sviluppo, ma devi fidarti del processo. In ingegneria non puoi semplicemente inchiodare le cose insieme e poi inchiodare le cose in cima e sperare di uscire con una soluzione elegante. Se nessuno fa architettura e progettazione tecnica di livello superiore, significa che è il tuo lavoro. Hai pagato il prezzo di trascurare quel lavoro.

(b) cerca di evitare di rattoppare le cose. Non pensare a lungo termine solo quando arriva il momento di fare il QA. Davvero dovresti testare ogni piccolo pezzo che costruisci, continuamente, e coprire tutti i casi di input, anche quelli che non sono sulla buona strada. Una patch / hack è quasi per definizione una soluzione a breve termine, che potrebbe anche avere un costo a lungo termine, colpisce il costo totale di proprietà dei clienti nel sistema. Ancora una volta, la pressione è su per ottenere il codice, quindi ci deve essere equilibrio. Ma cerca di non mettere in atto soluzioni a breve termine, esp. quelli che accoppiano strettamente i componenti che dovrebbero essere accoppiati in modo approssimativo. Ci saranno rilavorazioni, quindi fallo PRESTO per renderlo molto più semplice, per evitare gli hack e le patch che si accumuleranno nel tempo e diventeranno ingestibili.

Scrivi:

Ogni versione non è altro che un prototipo. Quindi non perdo molto tempo a scrivere codice super pulito a quel punto perché non so mai quanto dura qualcosa. ...

Poi arriva il punto in cui il programma è finito e il / i decisore / i dicono "questo è tutto". Ho un prototipo funzionante a questo punto, ma il codice all'interno è un po 'disordinato da tutto il avanti e indietro durante la fase di sviluppo.

Una versione archiviata può essere un "prototipo" in quanto manca di funzionalità o alcune funzionalità non vengono estinte, ma tutto il codice archiviato deve essere un codice di qualità di produzione che non deve essere necessariamente ripulito.

Penso che tu stia rimandando troppo la "pulizia".

La mia regola empirica è:

• Inizia con la (sotto) funzione
• sentiti libero di scrivere cose incomplete e incomplete, forse qualche c & p per avere un'idea di ciò che sto implementando o se devo grattare le ultime ore di codifica (nota che questo può andare di pari passo con TDD / test, è solo che tutto è attenuato un po 'per ottenere un rapido feedback sullo spazio di implementazione che sto esplorando)
• La funzione secondaria "funziona" abbastanza bene per ora
• Ora esegui la pulizia: prima di un commit SCC .
  • Guarda il codice per vedere cosa è ovvio
  • Esegui un commit diff o last per rivedere le modifiche e magari rilevare alcuni problemi
  • Risolve le cose che ho annotato sul mio scratchpad
• Ora eseguo il commit: questa qualità di codice è pronta per la spedizione

A questo punto, il codice impegnato può contenere ancora alcune soluzioni alternative o "debiti tecnici" che sarebbe bello ripulire, e forse lo ripulirò quando è la cosa naturale da fare per una seguente funzionalità secondaria, ma andrà bene se quel codice viene rilasciato così com'è.