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

Sono uno sviluppatore web principiante (un anno di esperienza).

Un paio di settimane dopo la laurea, mi è stato offerto un lavoro per creare un'applicazione web per un'azienda il cui proprietario non è molto esperto di tecnologia. Mi ha reclutato per evitare il furto della sua idea, l'alto costo di sviluppo addebitato da una società di servizi e per avere qualcuno di cui si può fidare a bordo per mantenere il progetto a lungo termine (sono arrivato a queste conclusioni da solo molto tempo dopo essere stato assunto ).

Pazzo come ero allora, con un diploma in informatica, ho accettato l'offerta pensando di poter costruire qualsiasi cosa.

Stavo chiamando i colpi. Dopo alcune ricerche ho optato per PHP, e ho iniziato con PHP semplice, senza oggetti, solo brutto codice procedurale. Due mesi dopo, tutto stava diventando confuso ed era difficile fare progressi. L'applicazione web è enorme. Così ho deciso di provare un framework MVC che mi avrebbe semplificato la vita. È lì che mi sono imbattuto nel ragazzo cool della comunità PHP: Laravel. L'ho adorato, è stato facile da imparare e ho iniziato subito a scrivere codice. Il mio codice sembrava più pulito, più organizzato. Sembrava molto buono.

Ma ancora una volta l'applicazione web è stata enorme. La compagnia mi stava facendo pressioni per consegnare la prima versione, che volevano distribuire, ovviamente, e iniziare a cercare clienti.

Poiché Laravel è stato divertente lavorare con me, mi ha fatto ricordare perché ho scelto questo settore in primo luogo - qualcosa che ho dimenticato mentre ero bloccato nel sistema educativo di merda.

Così ho iniziato a lavorare su piccoli progetti di notte, leggendo metodologie e buone pratiche. Ho rivisitato OOP, sono passato al design e all'analisi orientati agli oggetti e ho letto il libro di zio Bob Clean Code .

Questo mi ha aiutato a capire che non sapevo davvero nulla. Non sapevo come creare software THE RIGHT WAY. Ma a questo punto era troppo tardi, e ora ho quasi finito. Il mio codice non è affatto pulito, solo il codice spaghetti, un vero dolore per correggere un bug, tutta la logica è nei controller e c'è poco design orientato agli oggetti.

Sto avendo questo pensiero persistente che devo riscrivere l'intero progetto. Tuttavia, non posso farlo ... Continuano a chiedersi quando sarà tutto fatto.

Non riesco a immaginare questo codice distribuito su un server. Inoltre, non so ancora nulla sull'efficienza del codice e sulle prestazioni dell'applicazione Web.

Da un lato, l'azienda sta aspettando il prodotto e non può più aspettare. D'altra parte non riesco a vedermi andare oltre con il codice attuale. Potrei finire, avvolgerlo e dispiegarlo, ma dio sa solo cosa potrebbe accadere quando le persone iniziano a usarlo.

Riscrivo o continuo a provare a spedire o c'è un'altra opzione che mi è sfuggita?

Ti sei imbattuto nel tallone d'Achille della maggior parte delle educazioni CS: ti insegnano gli strumenti e le tecniche, ma non il commercio. Il software di costruzione è un mestiere, che acquisisci solo attraverso anni di pratica e l'esperienza di utilizzo del tuo software (gli utenti sono critici molto più severi degli insegnanti). La costruzione di software è anche abbastanza spesso un business, uno in cui gli obiettivi aziendali possono prevalere sulle ambizioni tecniche.

Prima di tutto, nave. Se mostri al proprietario dell'attività il software e ritengono che sia pronto per la spedizione, quindi spedisci. Se non è a quel punto, ma vicino, finiscilo. L'unico software che conta è quello che viene effettivamente utilizzato. L'unica attività di software che guadagna denaro è 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. Il codice di imbracatura senza un piano o un'architettura è una ricetta per il disastro
2. C'è molto di più nella programmazione oltre alla scrittura di codice
3. I proprietari di attività non tecniche spesso non comprendono l'impatto delle decisioni tecniche (ad esempio chi assumere) e spetta agli sviluppatori spiegare loro le cose.
4. La maggior parte dei problemi è già stata risolta molto meglio di come li risolveresti, nei framework esistenti. Vale la pena conoscere i quadri esistenti e quando usarli.
5. Le persone appena fuori dalla scuola assegnate a un grande progetto con poca guida tendono a produrre una scodella di codice spaghetti. E 'normale.

Ecco alcuni consigli per te su come procedere:

1. Comunicare, comunicare, comunicare. Devi essere molto aperto e sincero riguardo allo stato del progetto e alle tue idee su come procedere, anche se non sei sicuro e vedi più percorsi. Questo lascia al proprietario la scelta su cosa fare. Se mantieni la conoscenza per te stesso, li privi di scelte.
2. Resisti alla tentazione della riscrittura completa. Durante la riscrittura, l'azienda non ha prodotto. Inoltre, una riscrittura raramente risulta buona come l'hai immaginata. Scegli invece un'architettura e migra gradualmente la base di codice su di essa. Anche un codice orribile può essere salvato in questo modo. Leggi libri sul refactoring per aiutarti.
3. Ulteriori informazioni sui test automatici / test unitari . Devi rafforzare la fiducia nel codice e il modo per farlo è quello di coprirlo con test automatizzati. Questo va di pari passo con il refactoring. Finché non hai i test, esegui il test manualmente e in modo completo (prova a violare il codice, perché gli utenti lo faranno). Registra tutti i bug che trovi in ​​modo da poter stabilire le priorità e correggerli (non avrai tempo per correggere tutti i bug, nessun software viene distribuito senza errori nel mondo reale).
4. Scopri come distribuire un'applicazione Web e mantenerla in esecuzione. Il libro Web Operations: Keeping the Data On Time è un buon inizio.

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

Rilassati, questo succede a molte persone. Un giovane coinvolto nel profondo senza esperienza, che non ha aiuto, sostegno e guida non è esattamente una ricetta per il successo. Assumere e aspettarsi che un programmatore junior costruisca da zero un nuovo sistema che funzioni bene, funzioni bene e sia mantenibile non è realistico. Cavolo sei fortunato se tutto ciò che accade con un programmatore senior.

Secondo me devi purificarti. Questo non sarà divertente. Dì loro che hai fatto del tuo meglio, funziona (principalmente), ma sei preoccupato che potrebbe non funzionare bene e che ci saranno molti bug (ci sono sempre bug). Deve essere esaminato da un programmatore senior e dovrebbero essere in grado di risolvere abbastanza rapidamente eventuali problemi di prestazioni / sicurezza. Oppure possono schierarlo e incrociare le dita. O andrà bene, o andrà in fumo. Forse puoi risolvere i problemi man mano che si presentano. Se hai una grande base di utenti forse no.

Oppure potresti fare quello che la maggior parte delle persone fa in questa situazione: prendi i soldi, sparisci e lasciali risolvere. Lascio a te decidere quale sia la scelta etica.

Modifica (poiché questa domanda ha molti voti, potrei anche aggiungere un po 'più di contenuto)

Parte della gioia di 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 spiegare costantemente come funzionano i progetti di sviluppo software. Pianificazione, requisiti, revisioni del codice, test, distribuzione e correzione di errori. Spetta a te spiegare l'importanza dei test e dedicare tempo ai test. È necessario per sopportare la tua terra qui. Le persone non capiranno l'importanza ( "non possiamo iniziare a usarlo?") ma una volta avviati i test (non nell'ambiente live!) capiranno rapidamente i vantaggi. Uno dei motivi per cui ti hanno assunto è perché non sanno nulla dello sviluppo del software, quindi spetta a te educarli. È necessario sottolineare l'importanza del test e della correzione dei bug qui - ricorda, non sono programmatori, non conoscono la differenza tra una divisione per zero e un tag HTML non funzionante.

Spesso molti dei problemi che sorgono non sono in realtà bug. Saranno problemi di usabilità, requisiti mancati, requisiti che sono cambiati, aspettative degli utenti (perché non posso usarlo sul mio cellulare?) E quindi i veri e propri bug reali. Devi risolverli prima di andare a vivere - spesso molti bug possono essere risolti o risolti pochi giorni dopo. Se le persone si aspettano un sistema perfetto, soffriranno molto. Se si aspettano bug, la tua vita sarà molto più facile nelle prossime due settimane.

Oh, e non confondere i test degli utenti con i test delle unità né con i test di sistema.

• Unit Testing - la mia funzione di codice restituisce il valore corretto?
• Test di sistema - genera un errore quando faccio clic su X
• User Acceptance Testing (UAT) - il programma è conforme ai requisiti? Fa quello che ti hanno chiesto di farlo? Può andare in diretta?

Se non hai scritto i requisiti di ciò che ti hanno chiesto di fare, l' UAT sarà molto, molto più difficile. Questo è dove molte persone cadono. Avere ciò che volevano che il sistema facesse scrivere 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, correggilo. Se i requisiti sono errati, correggi il documento, richiedi uno o due giorni extra (no, insistici), apporta le modifiche, aggiorna la documentazione e riprova.

Dopo aver eseguito questo processo alcune volte, puoi iniziare a esaminare Agile .. ma questo è un altro mondo :)

TL; Test DR è buono

Ogni volta che inizi da zero, quasi sicuramente commetterai 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 si disperherà per il modo in cui non si adatta. Ritarderà inoltre l'implementazione nella produzione o l'implementazione di nuove funzionalità se viene distribuita la prima versione, il che rappresenterà un grave problema per l'azienda. Joel Spolsky lo chiama "unico peggior errore strategico" che qualsiasi azienda o sviluppatore può fare.

L'approccio consigliato è invece quello di pulire il disordine iniziale bit per bit durante la manutenzione. E non provare nemmeno a riformattarlo solo per il gusto di farlo. Inoltre, i manager di solito lo vedono come uno spreco di denaro (cosa che spesso accade) e comporta un rischio non necessario di introdurre nuovi bug. Una volta eseguito il debug doloroso del codice, potrebbe non essere carino, ma funzionerà. Quindi lascia che sia fino a quando non è necessario toccarlo per altri motivi (che si tratti di una correzione di bug, di nuove funzionalità o solo di una modifica richiesta dal marketing). Quindi ripulire le parti più difficili da regolare. Questa è spesso chiamata la regola del boy scout .

E a quel punto non devi discutere con il manager. Includi solo il refactoring desiderato minimo nel preventivo per la richiesta. Imparerai attraverso l'esperienza quando puoi permetterti di cedere un po 'perché la società è davvero in una correzione e quando non vuoi creare problemi in futuro e semplicemente non ammetti alcuna possibilità di hackerarla rapidamente.

Infine, un'altra lettura consigliata: la Big Ball of Mud .

Dimentico dove l'ho letto per la prima volta, ma volevo solo fare eco, un po 'più energicamente, a ciò che gli altri hanno detto:

La spedizione è una caratteristica.

Non c'è niente di peggio di quel tizio che continua a "ripulire" il codice esistente (possibilmente burrascoso, brutto, sporco) che funziona perfettamente bene , introducendo nuovi bug, ecc. Ciò che conta nel mondo reale è fare il tuo lavoro. L'hai fatto. Nave. Non perderti nelle riprogettazioni di un progetto che funziona perfettamente bene, anche se è brutto sotto il cofano. Quando lo risolvi, 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 stata molto utile quando l'avresti avuto dall'inizio. So che è difficile non rivedere tutto e applicare ciò che hai imparato. Ma ricorda:

Perfetto è il nemico del bene.

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

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

Ho letto [...] il codice pulito di Bob di zio.

Sto avendo questo pensiero persistente che devo riscrivere l'intero progetto.

Questo libro ha una sezione intitolata, molto appropriatamente, "La grande riprogettazione nel cielo".

Non provare a riscrivere tutto perché, nell'improbabile caso in cui hai il tempo di farlo, dovrai comunque affrontare gli stessi problemi. Una volta terminata la riprogettazione, avrai imparato cose nuove e ti accorgerai che le prime parti sono molto poco professionali, quindi vorrai riscriverle di nuovo.

Riprogettazione e riscrittura sono buone, ma solo se fatte in modo incrementale su un sistema funzionante. Come ha sottolineato un altro utente, segui la regola del boy scout, riformattando il codice a poco a poco mentre ci lavori.

Stai andando bene.

Dici che il tuo codice funziona ed è quasi pronto per la spedizione, giusto? E percepisci che il tuo codice potrebbe essere notevolmente migliorato. Buono.

Il tuo dilemma mi ricorda molto la mia prima esperienza con il libero professionista (essere assunto mentre ero al mio secondo anno in uni per creare un sistema POS multilingue). Ho fatto infinite domande perché non ero mai soddisfatto del codice, volevo la scalabilità, volevo reinventare ruote migliori ... Ma ho solo ritardato il progetto (tipo, circa 12 mesi circa) e ... cosa? Una volta distribuito, è necessario ancora un sacco di prove, prove, patch ecc ...

Hai esperienza di lavoro con basi di codice professionali? Molte basi di codice sono piene di codice bizzarro, difficile da mantenere. Un'alternativa alla scoperta della complessità del software provando a costruire un programma di grandi dimensioni sarebbe quella di mantenere / estendere un codice altrettanto disordinato scritto da altre persone.

Gli unici casi in cui ho visto fare riscritture complete fanno molto bene quando il team ha adottato contemporaneamente un nuovo toolchain / framework.

Se la logica di base (cosa fa il programma, non come è strutturato come funzioni, classi e così via ...) è sana, funzionerà altrettanto bene, quindi, pensando che sia il codice spaghetti non significa non dovrebbe essere distribuito.

Devi lasciare che i tuoi clienti abbiano qualcosa che possono usare. Quindi quando ti chiedono di migliorarlo / aggiungere funzionalità decidi se è necessario un refactor, e va bene far sapere ai tuoi clienti che "è necessario un lavoro tecnico per integrare detta nuova funzionalità". Con ciò capiranno che costerà loro più soldi e dovranno aspettare più a lungo. E capiranno (o puoi tirarlo fuori).

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

In breve, a meno che tu non possa dimostrare che l'intera cosa esploderà in faccia a tutti se verrà distribuita, ritardare l'implementazione sarebbe poco professionale e non andrà a beneficio di te o dei tuoi clienti. Imparare a fare piccoli refactor mentre correggi i bug o aggiungi nuove funzionalità, sarà un'esperienza preziosa per te.

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

Quello che aggiungerei è questo: ti è stato affidato il compito di qualcosa che era considerato fattibile da un singolo neolaureato che lavorava con un piccolo budget di avvio / periodo di tempo. Non dovresti aver bisogno di qualcosa di molto più sofisticato di una buona programmazione strutturata e procedurale. (E, FYI, "programmazione procedurale" non è una parolaccia. È una necessità ad un certo livello nella maggior parte dei casi ed è del tutto adeguata per molti interi progetti.)

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

Se ci sono aspetti del progetto che richiedono legittimamente polimorfismo, eredità di implementazione, ecc., Suggerirei che forse la dimensione del progetto è stata sottovalutata.

Se sei veramente interessato al dilemma che hai, dovresti anche leggere "Lean Startup". Molti dei consigli che ti vengono dati qui risuoneranno di più con te se leggi quel libro. Fondamentalmente, il tasso di combustione delle risorse è il tuo peggior nemico e nulla è più prezioso per te e la tua organizzazione del feedback dell'utente finale / cliente. Quindi, porta il tuo prodotto in uno stato fattibile (il Prodotto minimo valido - o MVP) e poi spediscilo fuori dalla porta (indipendentemente da come appare effettivamente il codice). Lascia che i tuoi clienti dettino i tuoi cambiamenti e le versioni future, non viceversa. Se ti concentri su questo approccio, sia tu che il tuo capo sarete più felici nel lungo periodo.

Per ragioni che altri hanno spiegato a fondo, è tempo di finire il progetto e spedirlo, per quanto doloroso possa essere.

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

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

Alcune persone hanno un talento per sedersi di fronte a un nuovo progetto software come utente alfa-test e far andare le cose male. Cioè, sono bravi a rompere le cose. Se sei abbastanza fortunato da avere una persona così talentuosa che lavora con te, lascia che provi prima l'app in modo da avere la possibilità di correggere in anticipo eventuali ovvi bug. Se devi svolgere questo compito da solo, allora:

• Sii metodico.
• Prova ogni funzione.
• Fai finta di essere un utente inesperto con la tua applicazione. Fai errori stupidi e vedi come li gestisce il software.
• Annota ciò che stai facendo in modo da poter riprovare dopo aver pensato di aver risolto i problemi.

La tua domanda dice: "Iniziato male, dovrei ricominciare" mentre il testo aggiuntivo dice in realtà "Progetto finito, ma ho sbagliato, dovrei ricominciare". Solo per il titolo della domanda: se la quantità di lavoro di programmazione che hai svolto è piccola rispetto al lavoro totale necessario, allora ricominciare da capo avrà senso. Ciò accade molto quando il problema è complesso e mal compreso e si impiega un po 'di tempo a capire quale sia effettivamente il problema. Non ha senso continuare con un brutto inizio, se buttarlo via e ricominciare tutto da capo, questa volta con una buona comprensione del problema, significa che in realtà finirai più velocemente.

Questo è quello che farei personalmente:

1. Esci, trova una scusa e arrenditi (puoi anche restituire una parte del tuo stipendio in modo da non sembrare cattivo)
2. Pulisci il tuo codice il più possibile
3. Fai la 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à tempo per il futuro in cui alcune persone riceveranno questo codice. Faranno ogni sorta di ipotesi e giudizi su di te e sulla tua abilità. A loro non importa quando lo hai scritto, a loro non importa della circostanza. Vogliono solo vedere in ciò che vogliono vedere per confermare ciò che vogliono confermare.

Verrai marchiato come qualsiasi brutto nome, termine che possono trovare per avere un impatto negativo su di te. E anche se in futuro potresti essere completamente diverso in termini di capacità tecnica, abilità, conoscenza, stile e la situazione sarà così diversa, questo codice verrà usato contro di te in ogni modo possibile. È come un tribunale in cui possono dire tutte le cose cattive su di te, sul tuo codice e sul tuo design e non ne sei nemmeno consapevole, così puoi spiegarti e difenderti. (e potresti imparare molto spesso che sono profondamente sbagliati, ripetutamente) Quindi non farlo. Abbandonare.

Fidati di me, ci sono persone che hanno fatto molte ipotesi su di te perché hai fatto qualcosa per qualsiasi scopo in qualsiasi momento. A loro, se ti è piaciuto questo nella situazione A, lo farai nella situazione B. Pensano molto semplice.

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

1) Metti un localizzatore di bug in atto e insegna al tuo capo ad usarlo. Questo può far parte della conversazione su come hai sbagliato, hai imparato meglio e lo risolverai in modo pianificato

2) Inizia a utilizzare il controllo versione, anche se si spera lo stia già facendo.

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

modificare

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

Sto sviluppando software da oltre trent'anni, incluso molto lavoro di consulenza ed ereditando il codice di altre persone. Un gran numero di sistemi problematici che ho visto sono stati quelli in cui le persone hanno scavato una fossa e non avevano note dettagliate su come ci fossero arrivati ​​né avevano il controllo della versione.

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

Inoltre, mentre i libri / StackExchange / webforum sono buone risorse di apprendimento, è probabile che nulla possa eguagliare l'apprendimento che riceverai lavorando (o anche solo discutendo di lavoro) con altri programmatori. Trovare e partecipare a un gruppo locale per una tecnologia che stai utilizzando o che vorresti imparare è un ottimo investimento del tuo tempo. Oltre alle conoscenze tecniche da acquisire, è un modo semplice per collegarsi in rete che è prezioso in vista di futuri concerti.

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 per questo. Fagli anche sapere quanto hai imparato e quanto meglio puoi fare nel prossimo progetto.

Sei uno sviluppatore web principiante, senza un buon sviluppatore presente per consigliarti, il tuo capo ti ha assunto conoscendolo perfettamente. Penso che tu stia facendo altrettanto bene come chiunque potrebbe aspettarsi che tu faccia. In realtà, il fatto che tu abbia la consapevolezza che il lavoro avrebbe potuto essere migliore e che hai effettivamente imparato cose che ti permetterebbero di farlo meglio, significa che stai facendo meglio di molti altri. Ricorda per la tua sanità mentale che la versione di te che ha iniziato il lavoro non avrebbe potuto farlo meglio. Qualcuno più esperto (e quindi meglio pagato), o tu con un progetto degno di esperienza, avresti potuto farlo meglio.

Cosa fare ora : sii felice di essere uno sviluppatore migliore rispetto a un anno fa. Il prossimo progetto farai meglio (e alla fine sarai di nuovo più esperto e non contento di quello che hai fatto; è normale). La modifica o la riscrittura dell'ultimo progetto darà all'azienda pochissimi benefici per il costo. Quello che puoi fare è sostituire il codice errato con un buon codice quando devi comunque apportare modifiche; questo ha senso perché modificare un codice mal gestibile può essere più difficile che sostituirlo con un buon codice. E se ottieni un nuovo sviluppatore inesperto per aiutarti, di 'loro che questo codice non è un esempio che dovrebbero copiare.