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

Il nostro codice è sbagliato. Potrebbe non essere sempre stato considerato negativo, ma è negativo e va solo in discesa. Ho iniziato appena uscito dal college meno di un anno fa e molte cose del nostro codice mi lasciano senza parole. All'inizio ho pensato che come nuovo ragazzo avrei dovuto tenere la bocca chiusa finché non avessi appreso qualcosa in più sulla nostra base di codice, ma ho visto molte cose sapere che è un male.

Alcuni dei punti salienti:

• Usiamo ancora i frame (prova a ottenere qualcosa da una stringa di query, quasi impossibile)
• VBScript
• Fonte sicura
• 'Usiamo' .NET - intendo dire che abbiamo wrapper .net che chiamano DLL COM rendendo quasi impossibile il debug facile
• Tutto è sostanzialmente una funzione gigante
• Il codice non è gestibile. Ogni pagina ha più file che vengono creati ogni volta che viene creata una nuova pagina. La pagina principale fondamentalmente fa Response.Write () un sacco di volte per rendere l'HTML (runat = "server"? Assolutamente no). Dopodiché può esserci molta logica sul lato client (VBScript), e infine la pagina si sottomette a se stessa (spesso memorizzando molte cose in campi nascosti) dove poi si inserisce in una pagina di elaborazione che può fare cose come salvare il dati al database.
• Le specifiche che otteniamo sono ridicole. Spesso chiamano cose come "popolare automaticamente il campo X con il campo Y o il campo Z" senza alcuna indicazione di quando scegliere il campo Y o il campo Z.

Sono sicuro che parte di questo è il risultato del fatto di non essere impiegato in una società di software, ma ho la sensazione che le persone che scrivono software debbano preoccuparsi almeno della qualità del loro codice. Non riesco nemmeno a immaginare che se dovessi far apparire qualcosa che presto verrebbe fatto, dato che si profila una lunga scadenza, ma stiamo continuando a scrivere codice cattivo e ad usare cattive pratiche.

Cosa posso fare? Come faccio a sollevare questi problemi? Il 75% della mia squadra è d'accordo con me e ha sollevato questi problemi in passato, ma nulla è cambiato.

Assicurati di non esagerare. Sei fresco, probabilmente non hai lavorato in molti (nessuno?) Altri posti, quindi non sei preparato per il mondo del "codice di vita reale". Il codice della vita reale è una cosa orribile. È come se il tuo bel codice scolastico e il tuo codice personale di progetto ottimizzato e modificato facessero sesso nel seminterrato di un reattore nucleare e il bambino fosse cresciuto in una fogna di rifiuti tossici; è un orribile mutante.

Ma supponendo che tu abbia ragione e che il codice sia cattivo come dici (cioè peggio del solo codice generalmente cattivo), allora hai ragione a preoccuparti. Parla con il tuo team e determina se tutti gli altri sono dalla parte. Ci vorrà del lavoro per migliorare la situazione: se il resto del team riconosce il problema ma non si preoccupa, allora stai perdendo tempo.

Essendo un junior, probabilmente non sei in grado di guidare. Se vai alla direzione 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. Ancora una volta, se nessuna delle persone anziane è interessata, allora stai perdendo tempo.

Supponendo che tu possa interessare alcuni tecnici senior, lavorerei per identificare le aree problematiche e le possibili soluzioni. Ad esempio, se "tutto è fondamentalmente una funzione gigante", la prossima volta che stai lavorando in quella "funzione gigante" forse dovresti rifattorizzare un po '. Ancora una volta, devi coinvolgere tutti. Se tagli via piccoli pezzi del tuo problema e migliorerai pezzo per pezzo, alla fine diventeranno molto meno 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 è male e deve essere riscritto". 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 man mano che vengono apportate modifiche. Dovrebbero essere istruiti sui vantaggi del codice gestibile. Questo dovrebbe provenire da una persona anziana di cui si fidano tecnicamente e professionalmente, non da te.

Completa riscrittura? Quasi sempre una cattiva idea.

Alla fine non c'è molto che puoi fare perché sei nuovo. Se nessuno vuole migliorare le cose, allora raccogli la tua esperienza e vai al posto successivo.

Leggi Joel On Software - cose che non dovresti mai fare. Comprendi il suo ragionamento, quindi leggi qualche altro articolo su software difettoso e su come risolverlo, scritto da manager, non da programmatori. Grazie a queste informazioni sarai in grado di presentare un caso per risolverlo, in termini che i manager comprendono e si preoccupano. Suggerimento: i bravi manager non spendono tempo e denaro esclusivamente in base alle opinioni e ai sentimenti dei programmatori su ciò che deve essere fatto.

"Questo codice è una schifezza e deve essere riscritto" ti verrà sicuramente respinto, anche se tecnicamente hai ragione.

"Possiamo prendere mesi dal programma del progetto attuale, costando meno e rendendolo più affidabile." attirerà la loro attenzione (nota la mancanza di menzione del HOW che intendi fare nel suo stadio.

Qualunque cosa tu dica, assicurati di avere 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 ed essere buono. Qualsiasi difetto nel codice rielaborato ti costerà, personalmente, a caro prezzo, indipendentemente da ciò che sarebbe potuto accadere se non avessi eseguito la rielaborazione. Se qualcuno è stato lì prima di te e ha rovinato o ipervenduto una riscrittura, rinuncia, ai manager non piace essere preso in giro e non lo lasceranno accadere due volte. A proposito, non rovinarlo per i ragazzi che seguono, hai solo un colpo in questo ...

Trova modi per distribuire il costo su un periodo di tempo o numero di progetti. I manager odiano il rischio, gli investimenti speculativi e il flusso di cassa negativo: rispettate le tolleranze dei vostri manager. Inizia con un piccolo suggerimento a basso rischio e basso costo. Una volta che hai dimostrato di avere ragione, puoi scegliere il pesce più grosso.

Prima di tutto, troverai cose legacy sciocche ovunque tu lavori come programmatore a meno che tu non lavori all'avvio e tu sia colui che crea il codice legacy sciocco originale. Devi essere in grado di tirare con questi pugni se hai intenzione di avere una carriera nella programmazione.

In secondo luogo, ci sono spesso considerazioni di costo per migliorare i vecchi sistemi. Ad esempio, ho visto più di un'azienda con VB6 di 10 anni e applicazioni ASP classiche ancora in funzione. In alcuni casi, ciò è dovuto al fatto che un grande progetto per spostare .NET non è riuscito correttamente. In altri, il motivo 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.

In situazioni in cui si è verificato un grave fallimento in passato, è quasi impossibile apportare un cambiamento. In tal caso, perfeziona il tuo curriculum e inizia a cercare un nuovo lavoro. Se non è rotto, probabilmente non avrai motivo di lamentarti del codice stesso ma che non eri in un percorso di carriera soddisfacente e in crescita. Se è rotto e sembra che sia nel tuo caso, è allora che hai la possibilità di cambiare.

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

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

"Ehi capo, 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 fatte in pochi minuti richiedono ore perché è tutto molto disorganizzato. Se non è possibile farlo subito dopo 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 vorrei fare è eseguire un Joel Test .

Questo ti permetterà di presentarlo come "Mentre cercavo modi per migliorare come sviluppatore ... Mi sono imbattuto in questo test di 12 domande sugli ambienti di sviluppo, quindi per divertimento ho risposto loro dove lavoro." ... Questo a sua volta lo rende un delineato da terze parti cosa c'è di sbagliato nel tuo codice e non tu personalmente.

Mentre leggi di più su Pragmatic Practices , migliorerai te stesso e implementerai cose come red / green / refactor e questo a sua volta ti permetterà di ripulire la base di codice in modo che diventi mantenibile. (col tempo)

Spero che aiuti! Benvenuto in Programmazione (il codice di ieri di solito fa schifo) ;-)

Suggerimento rapido: se proponi una gestione con un elenco di motivi per cui dovresti codificare diversamente, includi come argomento "Condizioni morale / lavorative migliorate per i programmatori".

Metti in chiaro che il team tecnico sarà più contento di scrivere e mantenere un codice pulito rispetto a questo pasticcio attuale, e questo può sicuramente migliorare il tuo atteggiamento verso il lavoro. Potrebbe essere un argomento utile.

• Il management determina davvero il design? Se hai la maggior parte della squadra dietro di te, cosa ti impedisce? Sii proattivo e decidi come gruppo. Elaborare un piano per implementarlo in modo incrementale . Allora fallo.
• Il management determina gli strumenti di sviluppo che usi? A meno che non ci sia un costo in termini di tempo per lo scambio di una gestione degli strumenti di solito non importa. Sii proattivo e decidi come gruppo quali strumenti di sviluppo vuoi usare. Se hai bisogno di acquistare dalla direzione, mostra loro un piano di migrazione e un'analisi costi-benefici. Allora fallo.
• La direzione impone le lingue che usi? Sii proattivo e decidi come gruppo cosa usare al posto di VBScript. Elaborare un piano per implementarlo in modo incrementale e farlo. Se hai bisogno di un buy-in di gestione, mostra loro il piano. Allora fallo.
• Non ho nulla per le specifiche. Di solito dipende molto dalle persone e dai processi del tuo lavoro. Identificare ciò che è rotto e le modifiche minime necessarie per correggere il processo richiede tempo, analisi e comprensione di come funzionano le cose 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 cambiare che non comportano grandi quantità di tempo dedicato senza valore commerciale (o soft) da mostrare per questo.

Parlando per esperienza: non è facile. È quasi impossibile Alla direzione non importa che il codice faccia schifo e che molto probabilmente sono completamente ignoranti e / o all'oscuro dei problemi affrontati, o che lo avrebbero risolto molto tempo fa e che oggi non ci si incastrerebbe. La cosa migliore che puoi fare è fare un elenco dei motivi per cui il codice fa schifo, e quindi il ragionamento alla base del perché fa schifo per dimostrare l'effettivo valore commerciale nel refactoring / riscriverlo.

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

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

La tua unica speranza è che il tuo capo e il senior management non siano troppo stupidi per capire quali ramificazioni ha per il codice e sono disposti a smettere di venire fuori con nuove richieste di funzionalità per affrontare i problemi, altrimenti i tuoi sforzi saranno vani . Parlando dell'esperienza passata, è molto probabile che non vedano nulla di sbagliato nel codice e / o i tuoi colleghi sono troppo spineless per portare le loro preoccupazioni al management.

In bocca al lupo. Ne avrai bisogno.

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

Il management probabilmente sa che il codice non è ottimale. La maggior parte del codice è a meno che tu non abbia assunto Ray Gosling, Guido Van Rossum o qualcun altro davvero bravo e costoso per scriverlo.

Il management sa anche che funziona utilizzando qualsiasi definizione di "lavori" applicabile alla tua azienda (non si arresta in modo anomalo, vende, consegna i rapporti o altro).

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

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

Aggiungete il fatto che nel software vi è un grande costo opportunità per arrivare sul mercato con le caratteristiche prima. Se ci pensate davvero, il rimborso a lungo termine sull'investimento nel tempo non è garantito.

Detto questo, è ancora un buon piano per riformattare e riparare le piccole cose (come ottenere un buon VSS) lungo la strada in morsi gestibili. In definitiva questo è un problema tecnico, non di gestione. Fai solo ciò che deve essere fatto, pur mantenendo ciò che prometti e andrà tutto bene. La direzione probabilmente non sarà interessata ai dettagli grintosi della qualità del codice, anche se si tratta di un caso valido.

Basta andartene il più presto possibile (forse non andartene troppo presto perché non vuoi apparire come un saltatore di lavoro). Il fatto che il loro codice sia un casino e che le persone stiano lì significa che probabilmente stai lavorando con sviluppatori poveri. Qualsiasi sviluppatore decente che si preoccupa del proprio lavoro non rimarrebbe a lungo a lavorare su tali schifezze.

La possibilità che si verifichi una riscrittura è piuttosto bassa a meno che non si possa dimostrare chiaramente che varrà l'investimento in termini di prezzo.

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

Se il sistema legacy è davvero, davvero male e sta aggiungendo una quantità ridicola di spese generali per la maggior parte della squadra (dico maggioranza perché c'è sempre un ragazzo che ha codificato grossi pezzi o tutto e lo sa come il retro di la sua mano) quindi avvicinarsi a loro e dire che sta costando i soldi dell'azienda in tempo di sviluppo, e avrà un effetto a catena con la soddisfazione del cliente.

Ma ancora una volta, a loro non importa ancora del codice, si preoccupano di un prodotto, quindi mentre quella risposta potrebbe farli andare "Sì, lasciamolo fare", potresti 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 hackerato.

Approccio alla gestione in modo tale da dimostrare di comprendere gli impatti sul budget derivanti dall'apportare grandi modifiche al codice e gli impatti sul budget di NON apportare le modifiche. Mi è piaciuta la frase di Emilio.

È importante ricordare che quel codice "vecchio" sarà sempre terribile. Con questo intendo, tutti noi sviluppiamo costantemente come sviluppatori. Scriviamo un buon codice, quindi impariamo a scrivere un codice migliore in seguito e il precedente codice "buono" sembra terribile. Troppi sviluppatori vengono coinvolti costantemente nel tentativo di migliorarlo e sprecare più denaro nel lungo periodo. È un atto di bilanciamento. Detto questo, è sempre bello se riesci a migliorarlo mentre vai. Quando vai a modificare quella funzione gigante, dividila! Alla fine arriverai da qualche parte.

Non farlo

Riscrivere da zero un grande progetto è comunque un grosso errore.

Non ho mai pensato che fosse facile dire ai manager, in particolare ai Project Manager, su codici errati e refactoring. In primo luogo, devono fidarsi di te, anche se sei un ragazzo anziano hai ancora bisogno di tempo per fidarti. In secondo luogo, semplicemente non capiscono quanto sia grave il problema. Se oggi è l'ultimo giorno per rilasciare una nuova build e la build non riesce. 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. Spesso ci vuole 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 degli spaghetti.

Stavamo pianificando una nuova versione e ho fortemente chiesto un po 'di refactoring, basta aggiungere il registro dei dettagli al codice di login / autenticazione dove spesso si sono verificati dei bug. I gestori hanno concordato, ma poi è stato inserito in un elenco piacevole e non so se sarà fatto poiché avevamo già un grande elenco di funzionalità e un intervallo di tempo ristretto.

Esistono due tipi di manager: quelli che fingono di capire cosa fai e quelli che non lo fanno. Quelli che fingono di capire il software ti saranno ostili. Quelli che non sono semplicemente infastiditi da te.

In ogni caso, i manager sono tutti bugiardi, quindi hanno una forte predisposizione ad assumere che lo siano tutti gli altri.

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