Come dimostrare che un'applicazione è basata su una base di codice errata?

'Ma funziona ora' è la risposta standard della gestione alle frustrazioni legittime degli ingegneri del software. La prima cosa che farei sarebbe compilare la documentazione (se esiste) e usarla per dimostrare le contraddizioni tra il codice e la documentazione.

Se puoi, crea una suite completa di test unitari. Esegui queste modifiche ad ogni modifica in modo da poter documentare regressioni che possono essere attribuite alla base di codice esistente.

Infine, se riesci a coinvolgere uno sviluppatore di un altro dipartimento di cui ti fidi, ottieni un secondo paio di occhi sul codice. Uno sviluppatore che dice "questa è una schifezza" è più facile da respingere, rispetto a quando uno sviluppatore senior che è in giro da un po 'gli garantisce e dice: "No, Jim, ha ragione. Questa è una schifezza da schifo. '

Ovviamente tutto dipende dal tuo ambiente, dalla dimensione dell'azienda, ecc.

Consiglio sempre di dare un'occhiata a The Pragmatic Programmer se non l'hai letto. Non solo dovrebbe essere richiesta la lettura per ogni professionista del software, ma ha alcuni buoni suggerimenti per trattare con la gestione, i colleghi, gli utenti, ecc. Che non vedono l'ingegneria del software come un mestiere.

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

In una certa misura, hanno un punto. La direzione vede i problemi quando le pubblicazioni 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 le alte occorrenze di errori che scivolano oltre il QA. Se le cose vanno bene, è facile darti una pacca sulla testa e dirti di fare del tuo meglio, perché non sta influenzando la linea di fondo.

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

Suggerirei di esprimere le tue preoccupazioni alle parti interessate in un modo che suggerisce che il software ha superato il suo progetto originale e che 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, questi sono normalmente strumenti standard del settore. Ti suggerirei di utilizzare questi strumenti e di elaborare un rapporto sulla qualità del codice e presentarlo a Manager. Assicurati che le tue critiche siano costruttive e non politiche.

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

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

I suggerimenti per il test di carico potrebbero essere un buon approccio, ma potrebbero non essere convinti che le crescenti preoccupazioni sull'utilizzo soddisfino qualsiasi potenziale di crescita nel mondo reale (la compagnia non raddoppierà in un anno.)

Tutto è relativo. Potrebbero non voler mettere le risorse in questo progetto quando hanno progetti per progetti più importanti su cui passare il tempo. Non essere etichettato come non vedere l'immagine grande.

Quando parli di provare qualcosa, tutta quella roba del metodo scientifico entra in gioco, e parte di ciò che significa è che se accetti standard oggettivi per decidere cosa è vero, devi accettare la possibilità che, dopo un'indagine, quei fastidiosi fatti risultano non essere dalla tua parte.

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

Innanzitutto, il codice attuale è "cattivo". Quello che probabilmente puoi provare è che "l'opinione professionale di quasi tutti gli sviluppatori che esaminano questo codice è che è male".

In secondo luogo, la società sarebbe meglio riscrivere il codice base. Questo è un problema perché anche se il primo punto è vero, il secondo potrebbe non esserlo. Inoltre, non ne sai abbastanza per fare questa determinazione. Questo è il lavoro della direzione e se vuoi che rispettino il tuo giudizio professionale sul primo punto, dovresti rispettare il loro riguardo al secondo.

Ma non possono stabilire il secondo punto senza le informazioni che fornisci. Devi comunicare ciò che sai su come i problemi nel codice avranno un impatto sul business e cosa sai su come una riscrittura potrebbe avere un impatto sul business. Questo è difficile, dal momento che entrambi implicano la previsione di un futuro che ha molte incertezze.

Ma puoi provare a indicare il problema in termini commerciali. Quanto tempo extra viene speso per cambiamenti e regressioni? Cosa costerebbe una riscrittura? Quanto velocemente i costi del sistema attuale saliranno nel tempo se non vengono riscritti? Cosa succede se c'è un aumento nell'uso, qual è la possibilità di un disastro se il codice corrente viene mantenuto? Non puoi davvero sapere nulla di tutto ciò, ma puoi fare una supposizione migliore di chiunque altro. Offri un intervallo o qualcosa per comunicare quanto accuratamente pensi di poter prevedere queste cose.

Alla maggior parte degli sviluppatori non piace il mantenimento di un codice scadente. Questo è il motivo per cui può essere un peccato che il codice che è un gioco da ragazzi per riscrivere dal punto di vista dello sviluppatore potrebbe non valere la pena riscriverlo dal punto di vista del business.

Ad esempio, anche se la riscrittura diventa redditizia, potrebbe valere meno del costo opportunità di spendere i soldi altrove nella società. Oppure il codice errato potrebbe richiedere più tempo per cambiare e avere più regressioni, ma non abbastanza per rendere redditizia una riscrittura. Potrebbero cercare di essere comprati nei prossimi mesi, e spendere soldi per una riscrittura verrà mostrato nei libri ma il software non sarà buggato.

Cerca di pensarci dal punto di vista del business e non cucinare i numeri per ottenere quello che vuoi. Una grande riscrittura non è quasi mai un gioco da ragazzi dal punto di vista del business. Se vuoi provare qualcosa di non direttamente dimostrabile, fai del tuo meglio per smentirlo. Se continui a fare del tuo meglio per trovare un modo non di riscrivere da zero, ma non ha senso, forse allora è davvero il momento di riscrivere da zero. E facendo questo sforzo mostrerai alla tua direzione che sei serio nel rappresentare gli interessi della compagnia, non i tuoi (stai rappresentando l'interesse della compagnia, non la tua, giusto?).

I Indovina dipende da ciò che è male sulla base del codice. Essere "Non come vorrei fare le cose" non significa che sia una cattiva base di codice.

Cose che in realtà fanno una cattiva base di codice:

• Fori di sicurezza

  Problemi che rendono vulnerabili server, applicazioni e / o dati. Soprattutto qualsiasi cosa che possa mettere a rischio i dati sensibili dell'azienda, del cliente o del cliente. Questi dovrebbero essere facili da documentare.

• Funzionamento interrotto

  Funziona solo perché si massaggiano i dati e si esegue la manutenzione dell'applicazione quasi continuamente per mantenerla funzionante. Se tu dovessi andartene e nessuno prendesse il gioco, non funzionerebbe più. - Documenta quanto tempo stai spendendo in questo modo. E nota quanto potresti risparmiare. Molto spesso questi processi sono inefficienti anche per gli utenti e potresti essere in grado di documentarli anche.

• In realtà non funziona

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

Che cosa non è una base di codice errata (semplicemente non va bene):

• 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 creare confidenza con gli utenti e la gestione. Assicurati che la logica funzioni fondamentalmente come l'originale.

• Codice non formattato / formattato in modo non corretto

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

Hai risposto alla tua stessa domanda in un modo.

Il modo in cui convincerli a spendere soldi per il sistema è aspettare che non funzioni bene per l'utente. Se pensi che non verrà ridimensionato, attendi che ciò accada o esegui un test di carico per provarlo.

È quindi una semplice proposta di pulire questo in scala costerà X ore.

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

Quindi ti trovi nel difficile momento di tentare di fare una riscrittura a causa del travolgente debito tecnico (secondo te, non abbiamo esempi e devi crederti sulla parola) così come essere in il punto difficile di avere la difficoltà di mantenere e aggiungere funzionalità in questo sistema.

Le tue stime per le nuove funzionalità saranno alte, giustificare questi numeri elevati con i fatti, dimostrando che queste cose impiegheranno davvero molto tempo. Se non lo comunichi in modo corretto, il tuo manager potrebbe semplicemente considerarti incompetente e certamente non lo vorrai. Quando mette in dubbio le stime elevate, spiega perché ritieni che il debito tecnico accumulato ostacoli la possibilità di aggiungere funzionalità al software attuale in modo rapido ed economico. Se il tuo manager ha due cellule cerebrali da massaggiare, inizierà a capire molto rapidamente.

Il punto è che non dovresti cercare di convincere il tuo manager, ma indirizzare il tuo manager con informazioni appropriate (e accuratamente selezionate) che lui / lei può convincere se stesso che una riscrittura è un corso accettabile. Devi fare in modo che il gestore pensi che sia stata la sua idea.

Per prima cosa determina il debito tecnico accumulato nella tua base di codice. Quindi dai un'occhiata a questa domanda e risposta , dove viene spiegato come convincere la direzione a estinguere il debito tecnico prima di procedere ulteriormente.

C'è una ragione per cui il tutti software maturo sembra un pasticcio:

1. Tutto il casino sta codificando la logica critica su cui si basa l'azienda. Senza di esso niente funziona. Era necessario risolvere ogni problema per risolvere il problema degli utenti.
2. Sta usando una tecnologia un po 'obsoleta. I programmatori attuali sembrano pensare che se non usa qualche modello magico, è solo un casino. Questa è una visione spezzata. Chiunque arrivi in ritardo a un progetto più grande avrà questa fase mentre impara tutti i dettagli.
3. I requisiti critici qualche tempo fa non sono più così importanti. 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.