Come provare che un'applicazione è costruita su una base di codice errata?

Attualmente sto rivedendo un sistema creato da alcuni sviluppatori che in precedenza ha lavorato nel mio lavoro. Il sistema funziona abbastanza bene dal punto di vista dell'utente, ma quando si analizza la revisione del codice è un vero casino. Sono più che convinto che il modo in cui l'applicazione è costruita non regge per gli aggiornamenti futuri, per non parlare degli alti aumenti nell'utilizzo.

Il problema è che so quanto sia grave, ma i miei superiori no. Come posso dimostrarlo al mio manager in modo che veda effettivamente il problema e possa essere convinto a fare un triage minimo sull'attuale base di codice e nel prossimo futuro avviare una nuova linea di sviluppo per la prossima versione dell'applicazione?

"Ma ora funziona" è la risposta gestionale standard alle legittime frustrazioni degli ingegneri del software. La prima cosa che farei sarebbe quella di compilare la documentazione (se presente) e usarla per dimostrare contraddizioni tra il codice e la documentazione.

Se puoi, metti insieme una suite completa di test unitari. Eseguili con ogni modifica in modo da poter documentare le regressioni che possono essere incolpate sulla base di codice esistente.

Infine, se riesci a richiamare uno sviluppatore di un altro reparto di cui ti fidi del lavoro, ottieni un secondo paio di occhi sul codice. Uno sviluppatore che dice "questa è una schifezza" è più facile da liquidare, rispetto a quando uno sviluppatore senior che è in giro da un po 'lo garantisce e dice: "No, Jim, ha ragione. Questa è una merda su un cracker.

Naturalmente, tutto dipende dal tuo ambiente, dalle dimensioni dell'azienda, ecc.

Consiglio sempre di dare un'occhiata a The Pragmatic Programmer Se non l'hai letto. Non solo dovrebbe essere richiesto di leggere per ogni professionista del software, ma ha anche alcuni buoni suggerimenti per trattare con dirigenti, colleghi, utenti, ecc. Che non vedono l'ingegneria del software come un mestiere.

Dal punto di vista della gestione, non c'è niente di sbagliato nel sistema e ti stai solo lamentando perché [vuoi solo riscriverlo / non capisci cosa hanno fatto gli ingegneri precedenti / vuoi che il tuo lavoro sia facile]. Un po 'un uomo di paglia, ma quando qualcuno in cima vede che le cose stanno funzionando bene in questo momento, non sono inclini a vedere una crisi in cui lo fai (sono sicuro che ci sia un'allegoria dei cambiamenti climatici lì da qualche parte ...) .

In una certa misura, hanno ragione. Il management vede problemi quando i rilasci vanno ben oltre la loro stima originale, le stime sembrano troppo alte per il lavoro svolto, "questo è impossibile con la nostra base di codice esistente", e si verificano alti episodi di bug che superano il QA. Se le cose stanno facendo le fusa bene, è facile darti una pacca sulla testa e dirti di fare del tuo meglio, perché non influisce sulla linea di fondo.

Cosa fare dipende dalla tua organizzazione e dal software stesso. Fondamentalmente, tuttavia, suggerisco di documentare ogni complicazione derivante da un codice legacy scadente. Quando si stimano le attività, chiarire al management perché pensi che ci vorrà così tanto tempo, con spiegazioni dettagliate su quali aspetti della vecchia base di codice stanno aggiungendo questo costo aggiuntivo. Quando i bug vengono introdotti nel codice, includere i motivi per cui questo bug è stato in grado di insinuarsi e come sono responsabili i problemi nella vecchia base di codice.

Suggerirei di esprimere le tue preoccupazioni agli stakeholder in un modo che suggerisca che il software ha superato il suo design originale ed è ora problematico continuare a migliorare.

Sono disponibili vari strumenti che possono eseguire la copertura del codice e la revisione del codice. Strumenti di Google adatti alla tua tecnologia, si tratta normalmente di strumenti standard del settore. Ti suggerirei di utilizzare questi strumenti e di presentare un rapporto sulla qualità del codice e presentarlo a Manager. Assicurati che le tue critiche siano contruttive e non politiche.

Scegli un esempio facile da capire dove la gestione potrebbe pensare che si tratti di una semplice richiesta di modifica, ma a causa del design esistente è molto più difficile.

Non vuoi che si soffermino sulla specifica richiesta, ma assicurati di far loro sapere che è così che QUALUNQUE richiesta di cambiamento sarà. Nessuno vuole essere dipinto in un angolo con un'applicazione. Gli sviluppatori credono in YAGNI, ma il management crede nel CYA.

I suggerimenti per i test di carico potrebbero essere un buon approccio, ma potrebbero non essere convinti che i maggiori problemi di utilizzo soddisfino qualsiasi potenziale di crescita del mondo reale (la società non raddoppierà entro un anno).

Tutto è relativo. Potrebbero non voler mettere le risorse in questo progetto quando hanno in programma progetti più importanti su cui trascorrere il tuo tempo. Non essere etichettato come non vedendo il quadro generale.

Quando parli di provare qualcosa, tutte le cose del metodo scientifico entrano in gioco, e parte di ciò che significa è che se accetti standard oggettivi per decidere ciò che è vero, devi accettare la possibilità che, dopo un'indagine, quei fatti fastidiosi risulta non essere dalla tua parte.

Nel tuo caso, penso che ci siano 2 cose da dimostrare.

Innanzitutto, l'attuale base di codice è "errata". Quello che probabilmente puoi provare è che "l'opinione professionale di quasi tutti gli sviluppatori che esaminano questo codice è che è negativa".

Secondo, che la società sarebbe meglio riscrivere la base di codice. Questo è un problema perché anche se il primo punto è vero, il secondo potrebbe non esserlo. Inoltre, non sai abbastanza per prendere questa determinazione. Questo è il lavoro del management, e se vuoi che rispettino il tuo giudizio professionale sul primo punto, dovresti rispettarne il secondo.

Ma non possono prendere la decisione sul secondo punto senza le informazioni fornite. Devi comunicare ciò che sai su come i problemi nel codice avranno un impatto sull'azienda e ciò che sai su come una riscrittura avrebbe un impatto sull'azienda. Questo è difficile, poiché entrambi prevedono la previsione di un futuro che presenta molte incertezze.

Ma puoi provare a dichiarare il problema in termini commerciali. Quanto tempo extra viene speso per i cambiamenti e le regressioni? Quanto costerebbe una riscrittura? Con quale velocità i costi del sistema attuale aumenteranno nel tempo se non riscritti? Che cosa succede se si verifica un aumento dell'utilizzo, qual è la possibilità di un disastro se viene mantenuto il codice corrente? Non puoi davvero sapere nulla di tutto questo, ma puoi dare un'ipotesi migliore di chiunque altro. Fornisci un intervallo o qualcosa per comunicare in che modo pensi di poter prevedere queste cose.

Alla maggior parte degli sviluppatori non piace mantenere il codice scadente. Questo è il motivo per cui può essere sfortunato che il codice che è un gioco da ragazzi riscrivere dal punto di vista dello sviluppatore non valga la pena riscrivere dal punto di vista aziendale.

Ad esempio, anche se la riscrittura risulta redditizia, potrebbe valere meno del costo opportunità di spendere il denaro altrove nell'azienda. Oppure la base di codice errata potrebbe richiedere più tempo per cambiare e avere più regressioni, ma non abbastanza per rendere redditizia una riscrittura. Potrebbero cercare di essere acquistati nei prossimi mesi e spendere soldi per una riscrittura apparirà sui libri, ma il software difettoso non lo farà.

Prova a pensarci dal punto di vista aziendale e non cucinare i numeri per ottenere quello che vuoi. Una grande riscrittura non è quasi un gioco da ragazzi dal punto di vista commerciale. Se vuoi provare qualcosa che non è direttamente dimostrabile, fai del tuo meglio per confutarlo. Se continui a provare il vostro meglio per venire con un modo non di riscrivere da zero, ma nulla si arriva con un senso, forse allora è davvero il momento di riscrivere da zero. E fare questo sforzo mostrerà al vostro management che siete seriamente intenzionati a rappresentare gli interessi dell'azienda, non i vostri (rappresentate gli interessi dell'azienda, non i vostri, giusto?).

Immagino che dipenda da cosa c'è di male nella base di codice. Essere "Non il modo in cui farei le cose" non significa che sia una cattiva base di codice.

Cose che effettivamente fanno una cattiva base di codice:

• Falle di sicurezza

  Problemi che rendono vulnerabili il server, l'applicazione e / o i dati. Soprattutto tutto ciò che mette a rischio i dati sensibili dell'azienda, del cliente o del cliente. Dovrebbero essere facili da documentare.

• Funzionante rotto

  Funziona solo perché si massaggiano i dati e si esegue la manutenzione sull'applicazione quasi continuamente per mantenerlo funzionante. Se dovessi andartene e nessuno prendesse il sopravvento, non funzionerebbe più. - Documenta quanto tempo stai impiegando a fare questo. E nota quanto potresti risparmiare. Molto spesso questi processi sono inefficienti anche per gli utenti e potresti essere in grado di documentarlo.

• In realtà non funziona

  Sembra funzionare ma i risultati non sono corretti. Questo generalmente causa problemi lungo la linea come numeri non corrispondenti, alta percentuale di difetti, ecc.

Cosa non è cattiva base di codice (semplicemente non buona):

• Scritto su tecnologia obsoleta non supportata. (VB6, COBOL, .net1.1 Ecc.)

Nota i vantaggi della migrazione a una nuova tecnologia. Prova a trovare un percorso di migrazione che sposta i pezzi alla volta in modo da ridurre al minimo i rischi e rafforzare la fiducia degli utenti e della direzione. Assicurarsi che la logica funzioni sostanzialmente come l'originale.

• Codice non documentato / mal formattato

Questo è il metodo più semplice da correggere perché in genere è possibile aggiungere commenti e correggere la formattazione senza influire sul codice. Ma non richiede una riscrittura. Se ritieni che ciò sia combinato con altri problemi, la prima cosa da fare è risolvere il problema in modo da poter valutare meglio la fattibilità del codice.

Hai risposto alla tua domanda in un certo senso.

Il modo per convincerli a spendere soldi per il sistema è aspettare fino a quando non funziona bene per l'utente. Se pensi che non si ridimensiona, attendi che ciò accada o esegui un test di carico per dimostrarlo.

È quindi una semplice proposta di pulizia di questo ridimensionamento costerà X ore.

Questa è una situazione difficile da affrontare perché dal punto di vista dell'utente ora tutto è in un punto accettabile e stabile. Principalmente con gestori non tecnici, non c'è nulla di cui preoccuparsi al momento, ma chiedere di riscrivere la base di codice è una decisione enorme e una che non dovrebbe essere presa alla leggera, specialmente sull'opinione e sugli sforzi di un singolo uomo (te stesso) .

Quindi sei in una situazione difficile nel cercare di far valere una riscrittura a causa del travolgente debito tecnico (secondo te, non abbiamo alcun esempio e dobbiamo prenderti in parola) oltre ad essere nel punto difficile di avere la difficoltà di mantenere e aggiungere funzionalità in questo sistema.

Le tue stime per le nuove funzionalità saranno elevate, giustificando questi numeri elevati con i fatti, dimostrando che queste cose richiederanno davvero molto tempo. Se non lo comunichi correttamente, il tuo manager potrebbe semplicemente presumere che tu sia incompetente e certamente non lo desideri. Quando mette in dubbio le stime elevate, spiega perché ritieni che il debito tecnico accumulato stia ostacolando la possibilità di aggiungere rapidamente ed economicamente funzionalità al software attuale. Se il tuo manager ha due cellule cerebrali da strofinare, inizierà a capire molto rapidamente.

Il punto è che non dovresti cercare di convincere il tuo manager, ma guidare il tuo manager con informazioni appropriate (e accuratamente selezionate) che lui / lei può convincersi che una riscrittura è un corso accettabile. Devi far pensare al manager che fosse sempre stata una sua idea.

Per prima cosa determina il debito tecnico accumulato nel tuo codebase. Quindi dai un'occhiata a questa domanda e risposte , dove viene spiegato come convincere il management a ripagare il debito tecnico prima di procedere oltre.

C'è una ragione per cui tutto il software maturo sembra un disastro:

1. Tutto il caos sta codificando la logica critica su cui si basa l'azienda. Senza di essa nulla funziona. Tutto ciò era necessario per risolvere il problema dell'utente.
2. Sta usando una tecnologia leggermente obsoleta. Gli attuali programmatori sembrano pensare che se non usa qualche template magico, è solo un casino. Questa è una visione spezzata. Chi arriva in ritardo a un progetto più grande avrà questo stadio mentre apprenderà tutti i dettagli.
3. I requisiti che erano critici qualche tempo fa non sono più così critici. Questo perché il software ha già risolto questi problemi. Arrivando in ritardo al progetto, potrebbe sembrare che il software sia complesso senza una buona ragione: il problema non esiste più, ma la complessità del codice è ancora presente.