Difficoltà nel leggere il codice

1

Non ho più di 6 mesi di esperienza e sono un po 'pigro. Lavoro sulla piattaforma Android. Ho ottime capacità nel capire cosa sta succedendo in generale. Il problema è che non ho l'esperienza per leggere e capire il codice di qualcuno (a parte ho appena ottenuto un nuovo progetto che svilupperò una nuova funzionalità in Android). Vorrei chiedere qualche consiglio su come essere un buon debugger e capire cosa sta succedendo nei dettagli. Sto affrontando molti problemi a leggerlo. Non so nemmeno scrivere test unitari.

    
posta Stavro Xhardha 14.04.2018 - 16:44
fonte

3 risposte

11

Ho più di 20 anni di esperienza e sono profondamente pigro. Lavoro su molte piattaforme.

Il modo in cui leggo e capisco il codice di qualcun altro è principalmente con le dita.

Perché sì, sono il bambino a cui viene sempre detto di non guardare con le dita. Sto per sempre toccando i segni che dicono di non toccare.

Ho la fortuna di lavorare in un negozio dove facciamo test. Quando arriva il momento per me di capire il codice di qualcun altro, non lo leggo. Lo gestisco Lo collaudo. Corro i vecchi test per questo. I più piccoli che riesco a trovare. Scrivo nuovi test per questo. Faccio domande a riguardo. Sfido il codice in tutti i modi in cui riesco a pensare. Da qualche parte lì dentro trovo il tempo per leggerlo e ridere delle bugie che chiamiamo commenti. Solo una volta che ho fatto tutto ciò, comincio a pensare che potrei capirlo. Questo è quando comincio a refactoring. Lo cambio per essere qualcosa di diverso da quello che era, pur non cambiando ancora quello che fa. Lo faccio per rendere più semplice l'aggiunta di una nuova funzione o per prepararmi a far sparire un vecchio bug. Dopo aver aggiunto test che mostrano le mie intenzioni, apporto le mie modifiche. Cerco anche altre piccole modifiche da apportare in modo che possa lasciarlo un po 'più bello di come l'ho trovato. Poi vado a fare qualcos'altro e, per un po ', dimentico che questo codice esiste.

La capacità di farlo è perché mi interessa dei test. I test mi aiutano a leggere il codice. I test non dimostrano che il tuo programma fa ciò che dovrebbe fare. Mostrano cosa fa in realtà. Devi capire se questo è quello che dovrebbe fare.

Quando sei nuovo è così allettante da trovare modi di pensare pigri. Uno dei più dannosi è concentrarsi sulla meccanica e sulla struttura. È molto meglio concentrarsi sulle idee. Per aiutarti in questo, lascia che ti insegni un modello davvero valido per sapere quando apprendi i test. Si chiama oggetto umile .

Qualcuno della mentalità meccanica / strutturale insisterà su ogni classe, ogni metodo, sarà sotto esame o insisterà sul fatto che il test non funzioni ed è una perdita di tempo. Diranno che l'unico buon numero di copertura del codice è del 100% o che la copertura del codice è una fantasia inutile e irraggiungibile. Tutto ciò è vero, per qualcuno che la pensa in questo modo.

Il modello di oggetto umile appena fuori ammette che esiste una cosa difficile da testare il codice. Questo è molto salutare da capire. A volte il problema non sei tu. È il codice richiesto dal problema.

Nulla è completamente non testabile, ma piuttosto che lanciare ogni magico trucco di derisione e riflessione sul codice per testarlo così come lo è l'umile modello di oggetto che si aspetta che noi facciamo un po 'di re-architecting. Modifichiamo il codice per separare il comportamento testabile dal codice di colla strutturale non interessante che francamente non ha bisogno di test. Perché? Perché il test riguarda la comprensione del codice.

Questo è esattamente il motivo per cui visualizzazioni e relatori non sono la stessa cosa. Le view, supportate dai presentatori, hanno rimosso il loro interessante comportamento. Non sono altro che noiosi codici strutturali. Le decisioni interessanti stanno accadendo tutti nei presentatori. Testiamo i presentatori. Non testiamo le visualizzazioni.

Le visualizzazioni e i presentatori non sono gli unici posti in cui lo facciamo. Tutto ciò che ha una meccanica noiosa deve essere cablato può beneficiare del modello di oggetto umile. Parlando con il DB, un servizio, un chip, un driver, tutto può finire con questa stessa dinamica. Offri loro il cablaggio di cui hanno bisogno e raschia via qualsiasi comportamento interessante che l'app deve esibire in un bel modulo testabile che dimostra che il comportamento è quello di cui abbiamo bisogno.

In questo modo è possibile incorporare qualsiasi comportamento necessario nel codice testabile indipendentemente da qualsiasi esigenza meccanica o strutturale di creare codice difficile da testare. In questo modo puoi concentrarti sulla tua vera idea.

Ci sono molte cose da studiare per aiutarti a sviluppare le tue capacità di test, ma capire perché non tutti i grumi di codice accolgono i tuoi sforzi di test, o anche i loro bisogni, sono in cima alla mia lista.

    
risposta data 14.04.2018 - 17:56
fonte
1

Questo è qualcosa che devo dire che non capisco del tutto. Mi sono imbattuto in diverse occasioni in cui qualcuno mi ha fatto una domanda su perché qualcosa è successo senza aver effettivamente attivato un debugger e inserito il codice per cercare.

Questo è tutto ciò che devi fare per un punto di partenza: apri l'applicazione, apri il tuo strumento di debug preferito ed entra nel codice. Guarda dove va, vedi se riesci a vedere i modelli utilizzati.

Una volta che hai appreso come il tuo collega ha strutturato il suo codice (ma è che lo hanno fatto), prova a scrivere la tua nuova funzione in un modello simile, poiché questo renderà la vita notevolmente più facile per il prossimo nuovo sviluppatore di venire avanti.

Il punto qui è che non devi solo leggere il codice - abbiamo gli strumenti che ti permettono di seguire il flusso. Usali.

    
risposta data 26.04.2018 - 15:00
fonte
0

Codice di lettura

Il modo in cui ho imparato a migliorare leggendo il codice è spesso leggendo altre cose. Leggo blog, libri e domande e risposte qui sui vari siti Stack Exchange sulla programmazione e l'architettura. Può essere difficile separare i bit utili dal dogma che lo circonda, ma farlo è estremamente utile.

Per esempio, ci sono delle regole che le persone menzionano frequentemente quando discutono dell'architettura del software. SOLID , la legge di Demeter , schemi di progettazione , ecc. Ognuna di queste idee è utile in una certa misura. Quindi imparali e provali. Probabilmente scoprirai che ci sono dei limiti in cui queste idee falliscono. Ad esempio, le funzioni brevi sono generalmente una buona idea. È più facile capire il flusso di controllo e la logica in una funzione più breve. Ma può essere portato ad un estremo. Ho visto persone raccomandare che nessuna funzione dovrebbe essere più lunga di circa 3 righe. Sfortunatamente, ho dovuto lavorare con un codice del genere ed è in realtà più difficile da seguire perché non c'è abbastanza contesto in una data funzione. Quindi prova queste cose e scopri dove sono i loro limiti.

Debug

Per il debug, imparare a usare il debugger è un ottimo primo passo. Sappi che i designer di debugger sono sadici e l'interfaccia utente per la maggior parte dei debugger è atroce. Se è possibile utilizzare un IDE con un debugger con una GUI, lo consiglio vivamente. Non sono perfetti, ma sono un passo avanti rispetto all'utilizzo delle terribili interfacce della riga di comando per la maggior parte dei debugger.

Ma hai bisogno di altri strumenti oltre al debugger. Hai bisogno di strumenti per osservare la memoria; hai bisogno di analizzatori statici; hai bisogno di profiler, ecc. Ognuno si rivolge a una serie specifica di problemi. Ad esempio, ci sono strumenti per trovare perdite di memoria durante l'esecuzione. Un profiler cronometrerà il tuo codice per trovare quali parti utilizzano il tempo di CPU più elevato, ecc.

Gli strumenti aiutano a semplificare il lavoro di debug.

    
risposta data 28.05.2018 - 03:56
fonte

Leggi altre domande sui tag