Il progetto è quasi finito, ma codice spaghetti procedurale. Riscrivo o continuo a provare a spedirlo? [chiuso]

Sei inciampato sul tallone d'Achille della maggior parte delle educazioni CS: ti insegnano gli strumenti e le tecniche, ma non il mestiere. Il software di costruzione è un mestiere, che acquisisci solo attraverso anni di pratica e l'esperienza di avere il tuo software utilizzato (gli utenti sono critici molto più severi degli insegnanti). Spesso anche il software di costruzione è un business, in cui gli obiettivi aziendali possono prevalere sulle ambizioni tecniche.

Prima di tutto, spedisci. Se mostri al proprietario dell'azienda il software e ritengono che sia pronto per la spedizione, spedisci. Se non è fino a quel punto, ma chiudi, finiscila. L'unico software che conta è quello che viene effettivamente utilizzato. L'unica azienda di software che guadagna soldi è quella che ha un prodotto.

In secondo luogo, hai imparato molte cose preziose, quindi dovresti apprezzare l'esperienza per ciò che ti ha insegnato :

1. L'imbroglio del codice senza un piano o un'architettura è una ricetta per il disastro
2. C'è molto di più nella programmazione rispetto alla scrittura del codice
3. I proprietari di attività non tecniche spesso non comprendono l'impatto delle decisioni tecniche (come chi assumere) e spetta agli sviluppatori spiegare loro le cose.
4. La maggior parte dei problemi sono già stati risolti molto meglio di come li avresti risolti, in framework esistenti. Vale la pena conoscere i framework esistenti e quando usarli.
5. Le persone appena uscite da scuola assegnate a un grande progetto con poca guida tendono a produrre una ciotola di codice spaghetti. Questo è normale.

Ecco alcuni consigli su come procedere:

1. Comunicare, comunicare, comunicare. Devi essere molto aperto e schietto sullo stato del progetto e le tue idee su come procedere, anche se non sei sicuro e vedi più percorsi. Ciò lascia all'azienda la scelta su cosa fare. Se mantieni la conoscenza per te stesso, li priverai delle scelte.
2. Resisti alla tentazione della riscrittura completa. Mentre stai riscrivendo, l'azienda non ha prodotto. Inoltre, una riscrittura si rivela raramente valida come l'hai immaginata. Scegli invece un'architettura e migra gradualmente la base di codici. Anche una base di codice orribile può essere salvata in questo modo. Leggi i libri sul refactoring per aiutarti.
3. Informazioni sui test automatici / test dell'unità . Devi aumentare la fiducia nel codice e il modo per farlo è coprirlo con test automatici. Questo va di pari passo con il refactoring. Finché non hai i test, prova manualmente e in modo completo (prova a infrangere il tuo codice, perché i tuoi utenti lo faranno). Registra tutti i bug che trovi in modo da poter stabilire le priorità e correggerli (non avrai il tempo di correggere tutti i bug, nessun software verrà rilasciato senza errori nel mondo reale).
4. Informazioni su come distribuire un'applicazione Web e mantenerla in esecuzione. Il libro Operazioni web: mantenere i dati in tempo è un buon inizio.

Questo suona come ogni altro sistema che mi è stato lanciato per risolvere.

Rilassati, questo succede a molte persone. Un giovane gettato nella parte più profonda senza esperienza, che non ha aiuto, nessun supporto e nessuna guida non è esattamente una ricetta per il successo. Assumere e pretendere che un programmatore junior costruisca da zero un sistema completamente nuovo, che funzioni bene, che funzioni bene e che sia manutenibile in modo non realistico. Al diavolo sei fortunato se tutto questo accade con un programmatore esperto.

Secondo me devi essere pulito. Questo non sarà divertente. Di 'loro che hai fatto del tuo meglio, funziona (soprattutto), ma temono che potrebbe non funzionare bene e che ci saranno molti bug (ci sono errori sempre ). Deve essere esaminato da un programmatore esperto, e dovrebbero essere in grado di correggere eventuali evidenti problemi di prestazioni / sicurezza molto rapidamente. Oppure possono dispiegarlo e incrociare le dita. Andrà tutto bene o andrà in fumo. Forse puoi risolvere i problemi mentre vengono fuori. Se hai una grande base di utenti forse no.

Oppure potresti fare ciò che la maggior parte delle persone fa in questa situazione: prendi i soldi, sparisci e lascia che li risolvano. Lascio a te il compito di capire quale sia la scelta etica.

Modifica (dato che questa domanda ha molti voti, potrei anche aggiungere dell'altro contenuto)

Parte delle gioie dell'essere un programmatore è che le persone non tecniche (probabilmente il tuo manager, sicuramente il resto del business) non hanno idea di cosa fai. Questo è sia bene che male. Parte del male è che devi costantemente spiegare come funzionano i progetti di sviluppo software. Pianificazione, requisiti, revisioni del codice, test, distribuzione e correzione dei bug. È il tuo lavoro per spiegare l'importanza dei test e dedicare del tempo al test. hai per mantenere la tua posizione qui. La gente non capirà l'importanza ( "non possiamo iniziare a usarlo?" ) ma una volta che iniziano a testare (non nell'ambiente live!) Capiranno rapidamente i vantaggi. Uno dei motivi per cui ti hanno assunto è perché non sanno nulla sullo sviluppo del software, quindi spetta a te educarli. Devi enfatizzare l'importanza dei test e dei bug fix qui - ricorda, non sono programmatori, non conoscono la differenza tra una divisione per zero e un tag html rotto.

Spesso molti dei problemi che emergono non sono in realtà bug. Saranno problemi di usabilità, requisiti mancati, requisiti che sono cambiati, aspettative degli utenti (perché non posso usarli sul mio cellulare?) E quindi i veri e propri veri bug. È necessario stirare questi prima di andare in diretta - spesso un sacco di bug possono essere risolti o riparati qualche giorno dopo. Se le persone si aspettano un sistema perfetto, avranno molto dolore. Se si aspettano bug, la tua vita sarà più facile nelle prossime due settimane.

Oh e non confondere i test degli utenti con i test unitari né con i test di sistema.

• Test unità - la funzione codice restituisce il valore corretto
• Test di sistema - genera un errore quando faccio clic su X
• Test di accettazione degli utenti (UAT) - il programma è conforme ai requisiti? Fa quello che ti hanno chiesto di fargli fare? Può andare in diretta?

Se non hai annotato i requisiti di ciò che ti hanno chiesto di fare, UAT sarà molto, molto più difficile. Qui è dove molte persone cadono. Avere quello che volevano che il sistema facesse scritto su carta renderà la tua vita molto più semplice. Diranno "Perché non fa X?" e puoi dire "Mi hai detto di farlo fare Y". Se il programma è sbagliato, risolvilo. Se i requisiti sono errati, correggi il documento, richiedi un giorno o due in più (no, insistici), apporta la modifica, aggiorna la documentazione e riprova.

Dopo aver passato questo processo un po 'di volte, puoi iniziare a guardare in Agile .. ma questo è un altro mondo:)

TL; DR Il test è buono

Ogni volta che inizi da zero, quasi sicuramente farai la stessa quantità di errori o più a causa del Second System Syndromme . I tuoi nuovi errori saranno diversi, ma la quantità di tempo necessaria per il debug sarà simile e quindi dispererai su come non sia una buona idea. Ritarderà inoltre la distribuzione in produzione o l'implementazione di nuove funzionalità se viene distribuita la prima versione, il che sarà un problema grave per l'azienda. Joel Spolsky lo chiama "singolo peggior errore strategico" che qualsiasi azienda o sviluppatore possa fare.

L'approccio consigliato è invece quello di pulire il pasticcio iniziale a poco a poco durante la manutenzione. E non provare nemmeno a rifattorizzarlo solo per il gusto di farlo. Inoltre, i manager di solito lo considerano uno spreco di denaro (cosa che spesso accade) e porta il rischio non necessario di introdurre nuovi bug. Una volta eseguito il debug del codice, potrebbe non essere bello, ma funzionerà. Quindi lasciatelo stare fino a quando non è necessario toccarlo per altri motivi (sia esso un bug fix, una nuova funzionalità o solo una modifica richiesta dal marketing). Quindi ripulisci le parti che sono più difficili da regolare. Questa è spesso chiamata la Regola dei Boy Scout .

E a quel punto non devi discuterne con il manager. Basta includere il minimo refactoring desiderato nella stima della richiesta. Imparerai attraverso l'esperienza quando potresti permetterti di arrendersi un po 'perché la società è davvero in difficoltà e quando non vuoi creare problemi in futuro e non ammetti alcuna possibilità di hackerarlo rapidamente.

Ultimo, un altro po 'di lettura consigliata: Big Ball of Mud .

Ho dimenticato dove l'ho letto per la prima volta, ma volevo solo echeggiare, un po 'più energicamente, ciò che altre persone hanno detto:

Shipping is a feature.

Non c'è niente di peggio di quel ragazzo che continua a "pulire" il codice esistente (possibilmente hacky, brutto, sporco) che funziona perfettamente , introducendo nuovi bug, ecc. Ciò che conta nel reale il mondo è portare a termine il tuo lavoro. L'hai fatto. Spedisci. Non perderti nella riprogettazione di un progetto che funziona perfettamente, anche se è brutto sotto il cofano. Quando lo aggiusti, fallo in modo incrementale e renditi una buona suite di test in modo da avere il minor numero possibile di regressioni.

Ogni progetto ti lascia più intelligente di prima. Dopo ogni progetto avrai accumulato più esperienza che sarebbe stato molto utile quando l'hai avuto fin dall'inizio. So che è difficile non rivisitare tutto e applicare ciò che hai imparato. Ma ricorda:

Perfetto è il nemico del bene.

Per il cliente è sempre meglio avere un buon software ora di un software perfetto che non verrà mai rilasciato.

Questo era solo il tuo primo progetto. Ci saranno molti altri progetti in futuro in cui potrai applicare tutto ciò che hai imparato dall'inizio.

I [...] read Uncle's Bob clean code.

I'm having this persistent thought that I have to rewrite the whole project.

Questo libro ha una sezione chiamata, molto appropriatamente, "The Grand Redesign in the Sky".

Non cercare di riscrivere tutto perché, nell'improbabile eventualità che tu abbia il tempo di farlo, dovrai comunque affrontare gli stessi problemi. Una volta completata la riprogettazione, avrai appreso nuove cose e ti renderai conto che le prime parti sono molto poco professionali, quindi vorresti riscriverlo di nuovo.

La riprogettazione e la riscrittura sono buone, ma solo se eseguite in modo incrementale su un sistema funzionante. Come ha fatto notare un altro utente, segui la Regola dei Boy Scout, rielaborando il tuo codice man mano che ci lavori.

Stai andando bene.

Dici che il tuo codice funziona ed è quasi pronto per la spedizione, giusto? E tu ritieni che il tuo codice possa essere notevolmente migliorato. Buona.

Il tuo dilemma mi ricorda molto la mia prima esperienza con il freelance (essere assunto durante il mio secondo anno all'università per creare un sistema POS multilingue). Ho fatto interminabili domande perché non ero mai soddisfatto del codice, volevo la scalabilità, volevo reinventare ruote migliori ... Ma ho solo ritardato il progetto (circa 12 mesi circa) e ... cosa? Una volta implementata la cosa, sono necessari ancora molti test, prove, patch, ecc ...

Hai esperienza nel lavorare con basi di codice professionali? Molte basi di codice sono piene di codice bizzarro e difficile da gestire. Un'alternativa alla scoperta della complessità del software cercando di creare un programma di grandi dimensioni sarebbe mantenere / estendere codice ugualmente disordinato scritto da altre persone.

Gli unici casi in cui ho visto le riscritture complete fanno molto bene quando il team ha adottato contemporaneamente una nuova toolchain / framework.

Se la logica sottostante (ciò che fa il programma, non come è definito come funzioni, classi e così via ...) è valido, funzionerà altrettanto bene, quindi, pensando che sia il codice spaghetti non lo fa t significa che non dovrebbe essere implementato.

Devi lasciare che i tuoi clienti abbiano qualcosa che possono usare. Poi, quando ti chiedono di migliorarlo / aggiungere funzionalità, decidi se un refactor è necessario, e va bene comunicare al tuo cliente che "sono necessari alcuni lavori tecnici per integrare la nuova funzionalità". Con il quale capiranno che costerà loro più denaro e dovranno aspettare più a lungo. E capiranno (o puoi tirare fuori).

Un momento migliore per riscrivere tutto sarebbe quando un altro cliente ti chiede di creare qualcosa di simile.

In breve, a meno che tu non possa dimostrare che l'intera faccenda esploderà in faccia a tutti se verrà dispiegata, ritardare l'implementazione sarebbe poco professionale e non porterà benefici né a te né ai tuoi clienti. Imparare a fare piccoli refactoring durante la correzione dei bug o l'aggiunta di nuove funzionalità, sarà un'esperienza preziosa per te.

La maggior parte di ciò che direi in risposta alla tua domanda è stato detto da altri. Leggi "Cose che non dovresti mai fare, parte I" di Joel Spolsky (insieme ad alcuni dei suoi altri post su "astronauti di architettura"). Ricorda che "il perfetto è il nemico del bene". Impara a refactoring in modo incrementale. La spedizione è importante, ecc.

Ciò che aggiungerei è questo: sei stato incaricato di qualcosa che è stato considerato fattibile da un singolo neolaureato che lavora con un budget / periodo di tempo di avvio ridotto. Non dovresti aver bisogno di qualcosa di molto più sofisticato di una buona, strutturata, programmazione procedurale. (E, FYI, "programmazione procedurale" non è una parolaccia, è una necessità a un certo livello nella maggior parte dei casi, ed è del tutto adeguata per molti interi progetti.)

Assicurati di avere do programmazione strutturata e procedurale. La ripetizione nel tuo codice non è necessariamente un segno che hai bisogno di grandi strutture polimorfiche. Potrebbe semplicemente essere un segno che devi prendere il codice ripetuto e inserirlo in una subroutine. Il flusso di controllo degli "spaghetti" può semplicemente essere un'opportunità per sbarazzarsi di un globale.

Se ci sono aspetti del progetto che legittimamente richiedono il polimorfismo, l'ereditarietà dell'implementazione, ecc., suggerirei che forse la dimensione del progetto è stata sottostimata.

Se sei davvero interessato al dilemma che hai, dovresti anche leggere "Lean Startup". Molti dei consigli che ti vengono dati qui ti risuoneranno di più se leggerai quel libro. Fondamentalmente, la frequenza di utilizzo delle risorse è il tuo peggior nemico e niente è più prezioso per te e per te organizzazione rispetto al feedback dell'utente finale / cliente. Quindi, porta il tuo prodotto a uno stato vitale (il Prodotto minimo vitale - o MVP) e poi spediscilo fuori dalla porta (indipendentemente da come sia effettivamente il codice). Lascia che i tuoi clienti dettino i tuoi futuri changeset e versioni, non il contrario. Se ti concentri su questo approccio, sia tu che il tuo capo sarete più felici nel lungo periodo.

Per motivi che altri hanno ampiamente spiegato, è giunto il momento di terminare il progetto e spedirlo, per quanto possa essere doloroso.

Vorrei solo sottolineare che testing anche l'app fa parte di "finirlo". Se funzionalità significative non sono state completamente esercitate e corrette i risultati confermati, quindi sei giustificato nella tua preoccupazione che le persone avranno problemi con questa app quando viene distribuita.

I test unitari e i test automatici di livello superiore sono ottimi e sono cose che dovresti avere il più possibile prima di provare a rifattare (o riscrivere) questa applicazione. Ma in questo momento hai principalmente bisogno di test , anche se devi eseguire ogni test "a mano" e confermare il corretto funzionamento "a occhio". Se riesci a capire come automatizzare i test in un secondo momento, ciò ti aiuterà quando sarà il momento di iniziare a lavorare sulla prossima versione del prodotto.

Alcune persone hanno l'abilità di sedersi di fronte a un nuovo progetto software come utente alfa-test e far sì che le cose vadano storte. Cioè, sono bravi a rompere le cose. Se sei abbastanza fortunato da avere una persona così talentuosa che lavora con te, lascia che provino prima l'app in modo da avere la possibilità di correggere presto eventuali bug ovvi. Se devi svolgere questa attività da solo, allora:

• Sii metodico.
• Prova tutte le funzioni.
• Fai finta di essere un utente inesperto della tua applicazione. Fai errori stupidi e vedi come li gestisce il software.
• Annota ciò che stai facendo in modo che tu possa riprovare dopo aver pensato di aver risolto i problemi.

La tua domanda dice: "Iniziato male, dovrei ricominciare" mentre il testo aggiuntivo in realtà dice "Progetto finito, ma ha sbagliato, dovrei ricominciare". Solo per la domanda: se la quantità di lavoro di programmazione che hai fatto è piccola rispetto al lavoro totale necessario, allora ricominciare da capo. Ciò accade molto quando il problema è complesso e mal compreso, e un bel po 'di tempo è dedicato a capire quale sia il problema. Inutile continuare con una brutta partenza, se buttarlo via e ricominciare da capo, questa volta con una buona comprensione del problema, significa che finirai per essere più veloce.

Questo è quello che farei personalmente:

1. Esci, scusami e rinuncia (puoi anche restituire parte del tuo stipendio in modo da non apparire male)
2. Pulisci il tuo codice il più possibile
3. Fai documentazione su tutte le parti buone del tuo lavoro come il tuo buon design, buone idee, ecc ...

Perché ti suggerisco tutti questi?

Perché pensa al futuro. Ci sarà del tempo in futuro quando certe persone prenderanno possesso di questo codice. Faranno ogni sorta di supposizioni e giudizi su di te e sulle tue capacità. A loro non importa quando l'hai scritto, a loro non importa della circostanza. Vogliono solo vedere in esso ciò che vogliono vedere per confermare ciò che vogliono confermare.

Sarai marchiato come un brutto nome, termine con cui possono venire in mente per avere un impatto negativo su di te. E anche se in futuro il tuo potrebbe essere totalmente diverso in termini di abilità tecniche, abilità, conoscenza, stile e situazione saranno così diversi, questo codice sarà usato contro di te in ogni modo possibile. È come un tribunale dove possono dire tutte le cose brutte su di te, il tuo codice e il tuo design e non ne sei nemmeno consapevole, quindi puoi spiegarti e difenderti. (e potresti imparare molto spesso che hanno torto profondamente, ripetutamente) Quindi non farlo. Arrenditi.

Credimi, ci sono persone che hanno fatto molte supposizioni su di te perché hai fatto qualcosa per qualsiasi scopo in qualsiasi momento. Per loro, se ti piace questo nella situazione A, lo farai nella situazione B. Pensano molto semplice.

Altri due suggerimenti, scommetto che almeno uno di questi non è stato eseguito.

1) Metti un bug tracker sul posto e insegna al tuo capo a usarlo. Questo può essere parte della conversazione su come hai sbagliato, hai imparato meglio e lo sistemerai in modo pianificato

2) Inizia a utilizzare il controllo della versione, anche se si spera che lo faccia già.

Ci sono un sacco di sistemi ospitati là fuori che forniscono entrambi i suddetti gratuitamente su piccoli account. Sono particolarmente affezionato a FogBugz che ha anche un ottimo sistema di stima e di completamento delle attività che darà al tuo capo ancora più certezza che stai affrontando le cose in modo ben gestito.

modifica

Wow, a qualcuno non è piaciuto molto questo: un downvote E una flag di cancellazione? Perché?

Ho sviluppato software da oltre trent'anni, compreso un sacco di lavoro di consulenza e di ereditare il codice di altre persone. Un gran numero di sistemi di problemi che ho visto sono stati dove le persone hanno scavato una fossa e non avevano note dettagliate su come ci sono arrivati né avevano il controllo della versione.

Per rispondere alla tua domanda: come hanno detto molti altri, no. Spediscilo e puliscilo a mano a mano nel processo di correzione dei bug.

Inoltre, mentre i libri / StackExchange / webforums sono buone risorse di apprendimento, è probabile che non si possa trovare nulla che possa corrispondere all'apprendimento che si riceve lavorando (o anche solo discutendo di lavoro) con altri programmatori. Trovare e frequentare un gruppo locale per una tecnologia che stai utilizzando o vorresti imparare è un meraviglioso investimento del tuo tempo. Oltre alle conoscenze tecniche da acquisire, è un modo semplice per fare rete che ha un valore inestimabile mentre guardi al futuro.

Il tuo capo era a conoscenza del tuo livello di esperienza quando ti ha assunto. Esprimi le tue preoccupazioni e fagli sapere che sei nervoso al riguardo. Informagli anche quanto hai imparato e quanto meglio puoi fare il prossimo progetto.

Sei uno sviluppatore web principiante, senza un buon presentatore di sviluppatori che ti consigli, il tuo capo ti ha assoldato sapendolo perfettamente. Penso che tu stia facendo altrettanto bene che chiunque potrebbe aspettarti che tu faccia. In realtà, il fatto che tu abbia l'intuizione che il lavoro avrebbe potuto essere migliore, e che hai effettivamente imparato cose che ti avrebbero permesso di farlo meglio, significa che stai facendo meglio di molti altri. Ricorda per la tua stessa sanità mentale che la versione di te che ha iniziato il lavoro non avrebbe potuto farlo meglio. Qualcuno più esperto (e quindi meglio retribuito), o con un progetto degno di esperienza, avrebbe potuto farlo meglio.

Che cosa fare ora : sii felice di essere uno sviluppatore migliore di un anno fa. Il prossimo progetto lo farai meglio (e alla fine sarai di nuovo più esperto e non felice di quello che hai fatto, è normale). Cambiare o riscrivere l'ultimo progetto darà al business un beneficio molto basso per il costo. Quello che puoi fare è sostituire il codice cattivo con un buon codice quando devi comunque apportare delle modifiche; questo ha senso perché modificare codice malamente gestibile può essere più difficile che sostituirlo con un buon codice. E se ti viene in aiuto un nuovo sviluppatore inesperto, digli che il codice questo non è un esempio da copiare.