Qual è / C'è un modo giusto per dire alla direzione che il nostro codice fa schifo?

Assicurati di non esagerare. Sei fresco, probabilmente non hai lavorato un sacco di (altri?) Altri posti, e quindi non sei preparato per il mondo del "codice della vita reale". Il codice della vita reale è una cosa orribile. È come il tuo bel codice scolastico e il tuo codice di progetto personale ritoccato ossessivamente ha fatto sesso nel seminterrato di un reattore nucleare e il bambino è cresciuto in una fogna di rifiuti tossici; è un odioso mutante.

Ma supponendo che tu abbia ragione, e il codice è pessimo come dici tu (cioè peggio del solo codice tipicamente cattivo), allora hai ragione a essere preoccupato. Parla con la tua squadra e determina se tutti gli altri sono dalla parte. Ci vorrà del lavoro per migliorare la situazione - se il resto della squadra riconosce il problema ma non ti interessa, stai perdendo tempo.

Essendo un junior, probabilmente non sei in grado di guidare. Se vai in gestione da solo, come nuovo assunto che è anche un junior, la tua opinione sarà probabilmente ignorata. Ottieni il tuo sviluppatore principale o uno dei ragazzi più anziani coinvolti. Di nuovo, se nessuna delle persone anziane è interessata, stai perdendo tempo.

Supponendo che tu possa interessare un po 'di tecnici esperti, mi piacerebbe lavorare per identificare le aree problematiche e le possibili soluzioni. Ad esempio, se "tutto è fondamentalmente una funzione gigante", la prossima volta che lavori in quella "funzione gigante", forse dovresti rifattorici un po '. Ancora una volta, devi prendere tutti i fuorigioco. Se elimini frammenti del tuo problema e amp; migliorare pezzo dopo pezzo alla fine diventeranno molto meno di un problema. Ogni volta che tocchi un pezzo di codice, considera se può essere migliorato.

Non hai intenzione di sederti con il management e dire "tutto è brutto e deve essere riscritto". Ciò non ha senso per loro: costa molto ed è potenzialmente molto rischioso. Invece dovrebbero essere resi consapevoli che ci sono problemi, e che c'è un piano per migliorare lentamente quando vengono apportate modifiche. Dovrebbero essere istruiti sui vantaggi del codice gestibile. Questo dovrebbe venire da una persona di alto livello che si fida tecnicamente e professionalmente - non da te.

Completa riscrittura? Quasi sempre una cattiva idea.

In fin dei conti non c'è molto che tu possa fare perché sei nuovo. Se nessuno vuole migliorare le cose, raccogli la tua esperienza e passa al prossimo posto.

Leggi Joel On Software - cose che non dovresti mai fare. Comprendi il suo ragionamento, poi leggi qualche altro articolo su software non valido e su come sistemarlo, scritto da manager, non programmatori. Armati di queste informazioni sarete in grado di presentare un caso per risolverlo, in termini che i dirigenti capiscono e si preoccupano. Suggerimento: i buoni manager non spendono tempo e denaro basandosi esclusivamente sulle opinioni e sui sentimenti dei programmatori su ciò che deve essere fatto.

"Questo codice fa schifo e ha bisogno di riscrivere" sicuramente ti verrà respinto, anche se sei tecnicamente corretto.

"Possiamo prendere mesi di pausa dal programma attuale del progetto, con un costo inferiore e renderlo più affidabile." attirerà la loro attenzione (notare la mancanza di menzione del modo in cui intendete farlo al suo stadio.

Qualunque cosa tu dica, assicurati di aver ragione. Se dici che è male, la tua riscrittura deve essere dannatamente buona. Se dici che ci vorrà una settimana, è meglio essere sicuri che sarà una settimana, e sii brava. Qualsiasi difetto nel codice rielaborato ti costerà, personalmente, caro, indipendentemente da ciò che potrebbe essere accaduto se non avessi eseguito la rilavorazione. Se qualcuno è stato lì prima di te e ha rovinato o soverchiato una riscrittura, rinunciare, ai manager non piace essere preso in giro e non lasciare che accada due volte. Per quel token, non rovinare tutto per i ragazzi che seguono, hai solo una possibilità in questo ...

Trova i modi per distribuire il costo su un periodo di tempo o numero di progetti. I gestori odiano il rischio, gli investimenti speculativi e il flusso di cassa negativo - lavorano all'interno delle tolleranze dei manager di questi. Inizia con una proposta a basso rischio, a basso costo. Una volta provato, puoi andare per il pesce più grande.

Prima di tutto, troverai roba legacy ovunque lavori come programmatore, a meno che non lavori in una start-up e sei tu a creare il codice legacy originale. Devi essere in grado di rotolare con questi pugni se hai intenzione di avere una carriera nella programmazione.

In secondo luogo, ci sono spesso considerazioni sui costi per migliorare i vecchi sistemi. Ad esempio, ho visto più di una società con VB6 di 10 anni e applicazioni ASP classiche ancora in funzione. In alcuni casi, ciò era dovuto al fatto che un grosso progetto di spostamento di .NET non funzionava correttamente. In altri, la ragione era "se non è rotto, non aggiustarlo". Ma, in altri, il costo della mossa è giustificabile poiché i problemi causati dal sistema legacy sono troppo grandi da ignorare.

Nelle situazioni in cui c'è stato un grosso fallimento in passato è quasi impossibile apportare un cambiamento. In tal caso, ripulisci il tuo curriculum e inizia a cercare un nuovo lavoro. Se non è rotto, probabilmente non avrai motivo di lamentarti del codice stesso, ma di non essere in un percorso di carriera soddisfacente e in crescita. Se è rotto, e sembra che sia nel tuo caso, è quando hai una possibilità di cambiare.

L'approccio migliore che ho visto è non mordere troppo ma iniziare con cambiamenti incrementali che avranno l'impatto più positivo. In base alla tua descrizione, una migliore gestione delle richieste di modifica sarebbe un punto di partenza. Una volta sotto controllo, puoi iniziare a guardare alla creazione di un framework di servizi o ad altri miglioramenti di progettazione / codice incrementali.

L'approccio peggiore che ho visto è quello di provare a fare un grande salto direttamente da un sistema legacy al più recente e più grande, ad esempio, passando da un sistema VB6 / Classic ASP / COM + funzionante ma goffo a un MVC / Entity Sistema quadro.

"Ehi Boss, dopo Big Project io e il team vorremmo un po 'di tempo, idealmente X mesi, per organizzare il nostro codice.Le cose che dovrebbero essere in grado di essere fatte in pochi minuti richiedono ore perché è tutto molto disorganizzato. possibile farlo subito dopo il Big Project, vorremmo pianificare un programma realistico. "

(parzialmente parafrasato dal commento di Azkar sulla domanda)

Inizia a leggere Joel on Software (Joel Spolsky / Founder of Stack Exchange) ...

La PRIMA cosa che farei è eseguire un test di Joel .

Questo ti permetterà di presentarlo come "Mentre stavo cercando dei modi per migliorare come sviluppatore ... mi sono imbattuto in questo test di 12 domande sugli ambienti di sviluppo, quindi per divertirmi ho risposto loro su dove lavoro". ... Questo a sua volta lo rende una terza parte che delinea qual è il problema con il tuo codice e non tu personalmente.

Mentre leggi di più su Pratiche pratiche migliorerai te stesso e implementerai cose come red / green / refactor e questo a sua volta ti permetterà di pulire il codice base in modo che diventi manutenibile. (nel tempo)

Spero che ti aiuti! Benvenuti in programmazione (il codice di ieri di solito fa schifo) ;-)

Suggerimento: se proponi la gestione con un elenco di motivi perché dovresti codificare in modo diverso, includi come argomento "Miglioramento del morale / condizioni di lavoro per i programmatori".

Metti in chiaro che il team tecnico sarà più impegnato a scrivere contenuti e mantenere un codice pulito rispetto a questo pasticcio attuale, e ciò può sicuramente migliorare il tuo atteggiamento nei confronti del lavoro. Potrebbe essere un argomento utile.

• La direzione impone effettivamente il design? Se hai la maggior parte della squadra dietro di te, cosa ti ferma? Sii proattivo e decidi come gruppo. Crea un piano per implementarlo in modo incrementale . Allora fallo.
• La direzione impone gli strumenti di sviluppo che usi? A meno che non ci sia un costo per lo swapping di una gestione degli strumenti, di solito non interessa. Sii proattivo e decidi in gruppo quali strumenti di sviluppo desideri utilizzare. Se hai bisogno di acquistare dalla gestione, mostra loro un piano di migrazione e un'analisi costi / benefici. Quindi esegui.
• La direzione impone le lingue che usi? Sii proattivo e decidi come gruppo cosa usare al posto di VBScript. Crea un piano per implementarlo in modo incrementale e fallo. Se hai bisogno di un management buy off mostra loro il piano. Allora fallo.
• Non ho niente per le specifiche. Di solito è altamente dipendente dalle persone e dai processi nel tuo lavoro. Identificare ciò che è rotto e le modifiche minime necessarie per risolvere il processo richiede tempo, analisi e comprensione di come le cose funzionano attualmente e come dovrebbero funzionare. Se sai che puoi elaborare un piano e provare a convincere la direzione.

Ottieni più cambiamenti e rispetto se proponi modi di cambiamento che non comportano grandi quantità di tempo dedicato senza alcun valore aziendale (o morbido) da mostrare per questo.

Parlando dall'esperienza: non è facile. È quasi impossibile. Il management non si preoccupa del fatto che il codice faccia schifo e più che probabile sia completamente ignorante e / o clueless dei problemi affrontati, o lo avrebbero risolto molto tempo fa e non si sarebbe rimasti bloccati oggi. La cosa migliore che puoi fare è fare una lista dei motivi per cui il codice fa schifo, e quindi il ragionamento alla base di perché fa schifo per dimostrare il valore commerciale effettivo nel refactoring / riscrittura.

Un esempio potrebbe essere per "Il codice non è gestibile":

Il codice corrente non è mantenibile a causa di X , Y e Z (elenca i motivi per cui non è possibile tenerlo). Ciò rende molto difficili le richieste di modifica e le nuove funzionalità, perché X , Y , Z (motivi per cui apportare modifiche è difficile). Poiché i cambiamenti sono difficili, il team di sviluppo non può facilmente rispondere a correzioni di bug e miglioramenti.

La tua unica speranza è che il tuo capo e il tuo senior management non siano troppo stupidi per capire quali implicazioni hanno per il codice e sono disposti a smettere di pubblicare nuove richieste di funzionalità per risolvere i problemi, altrimenti i tuoi sforzi saranno essere invano Parlando di esperienze passate, è molto probabile che non vedano nulla di sbagliato nel codice e / o che i tuoi colleghi siano troppo privi di spina per portare le loro preoccupazioni alla gestione.

Buona fortuna. Ne avrai bisogno.

"Ho iniziato appena uscito dal college" - dovrebbe rispondere alla tua domanda.

La direzione probabilmente sa che il codice non è ottimale. La maggior parte del codice è a meno che tu non abbia ingaggiato Ray Gosling, Guido Van Rossum o qualcun altro veramente buono e costoso a scriverlo.

Il management sa anche che funziona usando qualsiasi definizione di "works" valida per la tua azienda (non va in crash, vende, consegna i report o qualsiasi altra cosa).

Vogliono che tu mantenga il codice "funzionante" a costi minimi. Non vogliono una proposta per un progetto costoso per riscrivere tutto.

Il business case è quasi impossibile da realizzare perché il tuo deliverable è un software funzionante (quello che hanno già) non un codice elegante.

Aggiungete il fatto che nel software vi è una grande opportunità di ottenere sul mercato le funzionalità prima di tutto. Se ci pensi davvero, il ritorno sull'investimento a lungo termine non è garantito.

Detto questo, è ancora un buon piano per refactoring e risolvere le piccole cose (come ottenere un buon VSS) lungo il percorso in morsi gestibili. In fin dei conti questo è un problema tecnico non di gestione. Basta fare ciò che deve essere fatto pur continuando a mantenere ciò che prometti e starai bene. La gestione probabilmente non sarà interessata ai dettagli nitidi della qualità del codice, anche se si fa un caso strong.

Esci appena possibile (forse non lasciarti presto perché non vuoi sembrare un tipo di lavoro). Il fatto che codificano è un casino e le persone restano lì significa che probabilmente lavorerai con sviluppatori poveri. Qualsiasi sviluppatore decente che si preoccupa del loro lavoro non starebbe a lungo lavorando su tali schifezze.

La possibilità che una riscrittura si verifichi è piuttosto bassa, a meno che tu non possa dimostrare chiaramente che valga la pena di investire in dollari.

La gestione non si preoccupa del codice. Si preoccupano di avere un prodotto da vendere.

Se il sistema legacy è davvero, davvero brutto e si aggiunge una quantità ridicola di spese generali per la maggior parte della squadra (dico maggioranza perché c'è sempre un ragazzo che ha codificato pezzi grandi o tutti e lo sa come il dorso della mano) quindi avvicinarsi e dire che sta costando il denaro aziendale in fase di sviluppo, e avrà un impatto con la soddisfazione del cliente.

Ma ancora una volta, non si preoccupano ancora del codice, si preoccupano di un prodotto, quindi mentre quella risposta potrebbe farli andare "Sì, lascia fare", si potrebbe anche riordinare il codice senza chiedere il permesso di un manager. Non esagerare, assicurati di parlare prima con il team, a nessuno piace venire e provare a usare quella funzione che ti ha richiesto 3 mesi per scrivere e ora sembra non funzionare perché è stato violato.

Affronta la gestione in modo tale da mostrare che comprendi l'impatto sul budget di apportare grandi cambiamenti al codice e gli impatti del budget di NON apportare le modifiche. Mi è piaciuto il testo di Emilio.

È importante tenere a mente che quel codice "vecchio" sarà sempre terribile. Con questo voglio dire, cresciamo costantemente come sviluppatori. Scriviamo un buon codice, quindi impariamo a scrivere codice migliore in seguito e il precedente codice "buono" sembra terribile. Troppi sviluppatori vengono costantemente coinvolti nel cercare di renderlo migliore e sprecare più denaro a lungo termine. È un atto di equilibrio. Detto questo, è sempre bello se riesci a renderlo migliore man mano che vai. Quando vai a modificare quella gigantesca funzione, dividi! Alla fine otterrai qualcosa.

Non farlo.

Riscrivere un grosso progetto da zero è comunque un grosso errore la maggior parte delle volte.

Non ho mai pensato che sia facile dire ai manager, in particolare ai Project Manager, il codice errato e il refactoring. In primo luogo, devono fidarsi di te, anche se sei un ragazzo anziano, hai ancora bisogno di tempo per avere fiducia. In secondo luogo, semplicemente non capiscono quanto sia grave il problema. Se oggi è l'ultimo giorno di rilascio di una nuova build, la compilazione fallisce. Sanno quanto sia grave, ma non sanno mai che la build è fallita solo perché molti problemi come codice errato, test inadeguati ecc.

Ho svolto attività di configurazione e distribuzione in un progetto web. Richiede spesso molto tempo per risolvere problemi imprevisti ogni volta che distribuisco una nuova build. La maggior parte dei problemi riguardava la sicurezza e l'integrazione (tra diverse applicazioni Web / Windows). Il nostro codice fa schifo, il codice degli altri fa schifo, sono completamente spaghetti code.

Stavamo pianificando una nuova versione e ho chiesto con forza qualche refactoring, basta aggiungere il log dei dettagli al codice di login / autenticazione dove spesso si sono verificati errori. I manager erano d'accordo, ma poi è stato inserito in una lista di cose da fare e non so se sarà fatto poiché avevamo già una grande lista di funzionalità e un periodo di tempo limitato.

Ci sono due tipi di manager: quelli che pretendono di capire quello che fai e quelli che non lo fanno. Quelli che pretendono di capire il software saranno ostili a te. Quelli che non sono semplicemente infastiditi da te.

In ogni caso, i manager sono tutti bugiardi e quindi hanno una strong inclinazione ad assumere tutti gli altri.

Il mio punto è che, se dici che il software non è aggiornato, lo prenderanno solo come scusa. A loro non interessa.