Metodi di codice di debug (situazione Nightmare)

16

Ho spesso il compito di eseguire il debug di un'applicazione nel mio lavoro. È un'applicazione BI che distribuiamo alle aziende, che include un ambiente di test e un ambiente di produzione. Mi chiedo se ci siano app / strumenti / metodi che le persone possono suggerire, in base a questi vincoli:

  1. Il debugger non può essere utilizzato sul sito del cliente o localmente, perché il software dipende da applicazioni di terze parti personalizzate per le quali non abbiamo ambienti di test. (EDIT: per essere onesti, è possibile eseguire il debug localmente in alcuni casi.Se non usiamo altro che il codice core.Molto del codice problematico risiede in una DLL che incapsula comunicazioni specifiche di terze parti: socket, pipe di processo, chiamate di sapone, logica personalizzata che modifica il comportamento del codice core. Tipicamente durante un'implementazione o un miglioramento per un cliente, scriveremmo un nuovo codice in quest'area.)

  2. Non c'è praticamente nessuna registrazione nelle nostre app. Non ci sono test unitari.

  3. Il controllo versione ha solo 1 versione della soluzione completa (usando source safe 2005). Quindi non è possibile ottenere una versione precedente dell'intera soluzione, solo singoli file. (A meno che qualcuno non sappia come aggirare questo).

  4. Impossibile riprodurre localmente, spesso i tempi non possono riprodursi sull'ambiente di test (alta probabilità che test e produzione non siano la stessa versione).

  5. C'è un'alta probabilità che la versione che il client sta usando sia diversa da quella sulla fonte sicura. Questo perché i singoli file vengono aggiornati, con logica personalizzata incorporata per quel client specifico. Spesso ciò che accade è un aggiornamento a un binario, che richiede modifiche a molti altri binari, ma quando viene eseguito un commit, nessuno ne ha alcuna conoscenza o conoscenza. Un errore piuttosto comune che vedo è "Funzione / Metodo non trovato" o "Chiamata al metodo ha troppi / troppi pochi parametri specificati" in un ambiente client.

  6. Questa è una soluzione .net VB

  7. Impossibile installare alcun software sui siti client, ma può localmente

  8. La nostra applicazione è estremamente personalizzabile, ma sfortunatamente la logica di personalizzazione è distribuita su tutte le classi e file, dal front-end fino al livello dati, incluse le modifiche personalizzate apportate al database su un client base.

  9. Non ci sono praticamente commenti nel codice. Non c'è documentazione sull'architettura. Nessuna documentazione sull'API. L'unica cosa che abbiamo sono centinaia e centinaia di catene di e-mail che in qualche modo spiegano cosa sta succedendo. Le uniche persone che conoscono il codice sono quelle che lo hanno originariamente scritto, ma non sono più sviluppatori per dire, quindi non vengono coinvolti così tanto.

E prima che tu lo dica ... sì, lo so; Voglio spararmi anche io. Non aiuta che ci sia il codice spaghetti, centinaia di avvertenze sul compilatore e il polimorfismo rotto che VERAMENTE dovrebbe essere corretto, ma non ho voce in capitolo.

Il tipo più comune di errori che ho riscontrato sono errori di riferimento nulli, conversioni non valide e mancate corrispondenze di funzioni / funzioni mancanti. A volte sono fortunato e il visualizzatore di eventi registra la classe, il metodo e il messaggio di eccezione. Non è il più utile, ma è ancora qualcosa. Il peggiore sono gli errori che non hanno traccia, non ripropongono passaggi oltre a uno screenshot e sono messaggi di errore generici come quelli sopra menzionati. A volte non è possibile scoprire perché si sono verificati, solo per pregare che l'ambiente non sia configurato correttamente e che andrà via più tardi.

So che questo è un po 'esagerato, e in una certa misura lo è. Ma sono alla disperata ricerca di opzioni. Ci sono altri metodi / strumenti che posso usare?

    
posta Igneous01 14.01.2016 - 03:59
fonte

6 risposte

22

Il consiglio di Robert Harvey è probabilmente il migliore, ma dato che la consulenza di carriera è fuori tema, darò la risposta che può essere data:

Sei in fondo a una montagna molto ripida coperta di rovi e fango e capre di montagna irritabili. Non c'è un modo facile. Se vuoi arrivare in cima, devi costringerti a salire un passo tremendamente doloroso alla volta.

Sembra che tu sappia esattamente come funzionano dovrebbero . Se nessun altro ti aiuterà (di nuovo, ignorando i consigli di carriera), la tua unica scelta è iniziare a sistemare queste cose da solo.

Innanzitutto, per tutto ciò che è sacro, prendi quella roba in un sistema di controllo della versione reale . Praticamente qualsiasi cosa, ma Source Safe, che è ben noto come un mucchio di spazzatura puzzolente. git è gratuito e può essere impostato abbastanza facilmente. Non è possibile risolvere i problemi relativi alla passata mancanza di controllo della versione, ma almeno impedire che il problema prosegua nel futuro.

Quindi, controlla la registrazione. Trova, o il caso peggiore, scrivere un sistema di registrazione e iniziare a usarlo. Usane uno che può essere usato anche sui siti dei clienti, quindi quando le cose vanno di lato hai almeno qualcosa.

E inizia a scrivere test, almeno per le nuove modifiche che apporti.

Non c'è rivestimento di zucchero: non c'è una risposta qui che non implichi molto lavoro, o trattandolo come una questione di carriera.

    
risposta data 14.01.2016 - 05:06
fonte
8

1) Debugger cannot be used on client site ...

È perfettamente normale.

... or locally

Questo è un problema.

2) There is virtually no logging done in our apps.

La registrazione è il debug di produzione.

There are no unit tests.

Oh caro. Tutto a comune, però.

3) Version control only has 1 version of the full solution

Quindi non stai usando Controllo versione.

4) Cannot reproduce locally, often times cannot reproduce on test environment (High chance that test and production are not the same version).

Quindi solo l'ambiente client distribuito mostra gli errori.

In tal caso, è necessario il logging disgnostico incorporato nel codice dell'applicazione che (a) trap e [fully] record [fatal] error e (b) possano essere "compattati" su richiesta per produrre ulteriori, continui, diagnostics che sono utili nel rintracciare il / i problema / i.

5) There is a high chance that the version the client is using is different from the one on source safe.

Ancora una volta, non stai usando il controllo della versione a tuo vantaggio.

8) Our application is extremely customizable

Questo è abbastanza tipico.

Le differenze specifiche del sito devono essere gestite tramite Controllo versione "Branching".

9) There are virtually no comments in the code.

Ancora una volta, è fin troppo comune, perché gli sviluppatori scrivono codice "auto-documentante", vero?
O, almeno, codice che capiscono il giorno in cui lo scrivono.

There is no documentation about the architecture.

Oh caro.

No documentation about the api.

Oh caro, oh caro.

And before you say it... yes I know; I want to shoot myself as well.

No; vuoi sparare alle persone che hanno scritto tutta questa roba, creato un pasticcio non documentato, non gestibile e poi spostato verso nuovi pascoli, lasciando il disordine inconcepibile alle loro spalle.

Most common sort of errors I run into are null reference errors, invalid casts, and missing functions/function signature mismatches.

I riferimenti null e i cast non validi sono errori di runtime; in una certa misura, dovresti aspettarli e il fatto che li stai facendo spesso suggerisce una mancanza di programmazione difensiva (o un eccesso di ottimismo) da parte degli autori originali.

La mancata corrispondenza delle firme delle funzioni dovrebbe causare una build non funzionante; quelli dovrebbero causare "costruzioni rotte" e non dovrebbero mai uscire dalla porta!

    
risposta data 14.01.2016 - 13:37
fonte
5

Inizia con la registrazione. Questo avrà il maggiore impatto. Implementare un framework di registrazione nella base di codice, come Log4Net o simile. Inizia a registrare il codice.

Il debug dovrebbe essere possibile localmente. In caso contrario, lavorare per ottenere i file di simboli (PDB) in modo da poter eseguire il debug in dll di terze parti per ottenere un'immagine completa dei problemi che si verificano. Strumenti come WINDBG possono indicare quali DLL sono problematiche se il sistema si blocca. È possibile configurare qualsiasi server per eseguire un dump della memoria in caso di arresto anomalo. È fondamentalmente un'istantanea di cosa stava succedendo quando si è verificato il problema. Si possono esaminare localmente le discariche per trovare indizi su ciò che stava accadendo. Se il debug non è possibile, lavora per renderlo possibile. Documenta i passaggi necessari per il debug. A volte su sistemi complessi, c'è un bel po 'di setup necessario per il debug completo.

Monitoraggio dei bug ... Se non li usi, inizia a usarne uno. Questo va di pari passo con un sistema di controllo della versione appropriato. Fondamentalmente, inizia a monitorare i difetti e le revisioni del tuo codice. Inizia a creare una cronologia del sistema.

Esegui analisi del codice statico. Investire in uno strumento come ReSharper. Indicherà rapidamente tutte le possibili eccezioni di riferimento null e altre pratiche di codifica errate. Può aiutare a ottenere il codice in forma migliore con pochi clic e automatizzare elementi noiosi come la formattazione del codice, la denominazione delle variabili, ecc. Misurare il codice, scoprire dove sono i punti caldi per il refactoring tramite le metriche del codice.

Test del refactoring e dell'unità. Assumerò che probabilmente la maggior parte del codice scritto non è molto testabile, quindi non mi preoccuperei di provare ad aggiungere test per questo. Qualsiasi nuovo codice, creare un progetto di test e iniziare a scrivere test, sia l'unità che l'integrazione. Se l'unit test fallisce, fallire la build. Quindi, come refactoring, dovrebbero esserci dei test. Una cosa con i test è che si può scrivere un test per chiamare qualsiasi metodo e eseguire il debug in quel metodo senza caricare l'intera applicazione o la base di codice. Questo è utile per aiutare a risolvere i problemi.

Documenta le conoscenze tribali secondo necessità. Il codice dovrebbe essere auto-documentante, quindi i commenti devono essere sparsi, ma molti sistemi hanno modi "insoliti" di fare le cose, metterli in evidenza in un codice WIKI o in un altro tipo di repository informale. Inoltre, considera di venire con gli standard e le pratiche di codifica. Applicare tali standard tramite un set di strumenti come Resharper. Poiché la maggior parte del codice probabilmente non sta seguendo nessuno standard e linee guida, implementa gli standard sul nuovo codice che è stato scritto.

Dal tuo nuovo, lo tratterei come un giro del dovere. Da 6 mesi a 2 anni, quindi scegliere se rimanere o andare avanti. Soddisfazione nel rendere le cose leggermente migliori rispetto al giorno prima.

    
risposta data 14.01.2016 - 22:53
fonte
4

Primo, tutto quanto sopra ... idem.

Alcune euristiche:

  • Utilizza il controllo del codice sorgente sul tuo computer di sviluppo. È la cosa migliore che ho fatto. Non è un sostituto per il controllo della versione del progetto, che abbiamo. È uno strumento che offre una straordinaria libertà di sperimentare, hackerare, risolvere problemi di lavoro simultaneamente ma in modo indipendente, ecc. Sono più abile nell'usare il controllo di versione perché ho la libertà di essere audace, rovinare e imparare.
  • Nella misura in cui aggiungi commenti, dai la priorità agli elementi dell'interfaccia pubblica, per approfittare di intellisense. Fai questo come decifri durante le tue avventure di debug.
  • Sii persistente con piccoli refactoring. Prima o poi, per un determinato pezzo di codice, arriverete a una massa critica che consente di effettuare importanti refactoring come DRY su codice ridondante attraverso le classi.
  • Non mescolare la riformattazione del codice e le modifiche effettive nello stesso controllo della versione commettono.
  • Principi SOLIDI
    • Non ignorare mai le singole responsabilità. Ben fatto, questo è il percorso alla promessa orientata agli oggetti; IMHO.
    • Ignora sempre Apri / Chiuso.
    • Non stiamo parlando di nuovo codice qui.
    • La creazione di interfacce senza una progettazione specifica ostacola la manutenzione.
  • refactoring
  • Alcuni file di codice richiedono una completa riformattazione, rinominazione variabile, ecc. prima ancora di tentare il debug. Non essere timido nell'usare il menu refactoring di Visual Studio senza test unitari.
  • L'unica documentazione che non può essere riposta male è nei file di codice.
  • Quando ottieni il controllo della versione, ripensa al piano VC. E documentalo! E trovare una convenzione di denominazione per le filiali, tag che evidenzieranno le principali versioni e le pietre miliari del software.
  • Utilizzare una buona attrezzatura
  • Fai pratica Rubber Ducky Debugging
  • A volte la cosa peggiore che può succedere è che non ti licenzi.

Modifica

Sviluppo applicazioni brownfield in .NET

Prova questo libro. Una prima copertina da leggere è probabilmente la migliore. Questo libro ti aiuterà a pensare al quadro generale, alle possibilità e allo sviluppo di piani strategici e tattici di attacco.

Attaccandolo

Rimani, diciamo, 1,5 anni se puoi; abbastanza a lungo da sapere se stai facendo progressi esperienziali. Saprai se hai 2 anni di esperienza o 6 mesi di esperienza 4 volte.

Essere "junior con 1/2 anni di esperienza" Sono preoccupato che un potenziale datore di lavoro lo vedrà come un salvataggio anticipato perché non è possibile hackerarlo. Una cosa è dire che hai imparato che z, y, x, ha preso alcuni nomi e preso a calci in culo - ma non è stato permesso di contribuire alle tue capacità; e un altro semplicemente mettendo a repentaglio il lavoro, il codice, la gestione, ecc. a titolo di spiegazione.

Potrei non essere all'altezza, ma il mio "meglio dei tempi e dei periodi peggiori" è stato il mio primo lavoro, che è stato un codice letteralmente non gestibile. Ho avuto un grande supervisore (tutto il resto proveniva dal programma di gestione in allevamento) che mi ha dato lo spazio per riscrivere alcuni programmi chiave. Quell'esperienza fu rivelazione.

modifica fine

    
risposta data 15.01.2016 - 07:18
fonte
0

Direi (5) è quello che devi risolvere prima. Se non sai quale codice è in esecuzione in produzione, non hai un modo sicuro di riprodurre e risolvere i problemi. Questo rende ogni altro cambiamento che tu introduci pericoloso, poiché potrebbe causare problemi che non puoi prevedere e non riprodurre.

Potresti aver bisogno di fare un po 'di lavoro investigativo e magari di fare il reverse engineering per capire quale versione (s) di codice e quali librerie sono distribuite. (E 'necessario disporre di un sistema di compilazione e distribuzione coerente per portare tutto il codice distribuito in linea con il controllo del codice sorgente in corso.)

Potrebbe essere necessario creare più ambienti di test per replicare le varie distribuzioni. (Ovviamente la soluzione più semplice è creare una nuova build pulita e distribuirla in modo coerente ovunque, ma sembra che questo non sia possibile?)

Solo quando conosci le versioni esatte distribuite e disponi di ambienti di test corrispondenti, dovresti iniziare a provare a correggere / migliorare il codice.

La tua prossima priorità dovrebbe essere quella di consolidare in un unico codice base che può essere distribuito ovunque. Sembra che tu abbia varie versioni del codice distribuito a causa della personalizzazione? È necessario consolidare in una singola versione e quindi utilizzare le opzioni di configurazione per la logica personalizzata.

Dopo questo, puoi iniziare a migliorare attentamente il codice base per consentire un debugging più semplice. Aggiungere registrazioni è probabilmente il meno rischioso.

Dovrai aggiungere test automatici, ma spesso è difficile aggiungere unittest a un progetto che inizialmente non è stato progettato per i test. Invece, consiglio di iniziare con test di integrazione automatizzati end-to-end. Questi sono più difficili da configurare, ma non richiedono la riprogettazione della soluzione, quindi sono meno rischiosi.

    
risposta data 16.01.2016 - 16:56
fonte
0

Ignorando i problemi che hai nel tuo team, sembra che il primo a risolvere sia il debug del codice che corrisponde a ciò che è in produzione. Altrimenti potresti inseguire un bug che era già stato risolto nel codice che hai nel tuo "Controllo del codice sorgente". Poiché questo è .NET, puoi facilmente "decompilare" i file binari di produzione per confrontare il codice con quello che hai. Non è un compito facile, ma se ci riesci, questo è un argomento valido per un migliore strumento di controllo del codice sorgente in grado di taggare le versioni rilasciate.

    
risposta data 25.01.2016 - 11:08
fonte

Leggi altre domande sui tag