Come posso chiedere al mio capo (in modo educato) di commentare il suo codice?

Sei nel "profondo" e, secondo me, è il modo migliore per imparare. Non perché stai guardando cose di cui non hai la minima idea, ma perché ti costringe ad essere più intraprendente e scoprire quali componenti svolgono quel ruolo in un sistema che sei nuovo.

Non aiuta il tuo capo a essere troppo occupato per gestire qualcuno che è curioso (e tu sei totalmente nei tuoi diritti di essere curioso, sei ansioso di imparare, che è buono). Ma, sfortunatamente, chiedere al tuo senior di cambiare stile e approccio per il tuo apprendimento potrebbe non andare troppo bene, soprattutto perché hai a che fare con qualcuno che dici che è occupato.

Essere seduti davanti a migliaia di righe di codice che non conosci è la norma. Non è sempre possibile spiegarlo in bianco e nero con i commenti. Tuttavia, per il gusto di apprendere quando sei nuovo, se senti che devi assolutamente chiedergli dei commenti, forse spiega perché. Spiega che è perché non vuoi disturbarlo con le domande perché è spesso impegnato. Non solo questo si presenterà molto meno come se gli dicessi di fare qualcosa, ma aprirà anche la parola a discussioni su come potrebbe preferire, invece, porre domande a parte.

In primo luogo, strisciare attraverso migliaia di righe di codice non familiare e sentirsi persi è come il progetto software ogni è, ovunque, dall'inizio del tempo.

La più grande differenza tra te e un programmatore esperto è che non ci sei abituato.

Alcuni punti da tenere a mente:

1. Con uno sforzo sufficiente, ogni bit di codice è comprensibile. Molte persone si sentono frustrate se non riescono a capire qualcosa in pochi minuti. Sii più paziente di quello.

2. Un buon capo è il più aperto possibile alle interruzioni e alle domande. Un buon dipendente cerca il più possibile di ridurre al minimo interruzioni e domande. Siate consapevoli di ciò.

3. Le interruzioni sono più costose delle domande. Puoi sfruttare meglio il tuo tempo e il tempo del tuo capo consolidando le tue discussioni, e senza mai finire una conversazione sentendoti confuso.

4. Il tuo capo è un programmatore migliore di te. (Probabilmente). Questo non vuol dire che non si può essere più forti in alcune aree, ma nel complesso la sua esperienza è maggiore. Fino a quando non avrai molta esperienza, assicurati di imparare dalla sua esperienza il più possibile.

5. Se sei sicuro che più commenti potrebbero aiutare significativamente il codice, chiedi al tuo capo. "È difficile per me capire cosa sta succedendo in alcuni punti, quando capisco le cose, ti dispiace se aggiungo commenti?" Forse odia i commenti. Forse lo adorerà. Forse sarà indifferente.

Alla fine, tuttavia, è possibile che tra un paio di mesi ricorderai di averlo fatto e pensi: "Huh, mi chiedo che problema ho avuto? Non è così male. Hm, beh, no materia ".

Se il tuo capo non ha tempo per rispondere a tutte le tue domande, perché pensi che avrà tempo per commentare il suo codice legacy? E inoltre, cosa ti fa pensare che i suoi commenti descrivessero davvero i pezzi che non capisci per ora? Per la mia esperienza, provare a cambiare lo stile di programmazione dei tuoi boss semplicemente chiedendo a lui non funzionerà, educatamente o meno.

La cosa migliore che puoi fare in una situazione del genere: commenta le parti del codice che devi capire per fare il tuo lavoro da solo - una volta comprese le parti, ovviamente, e dopo averle un impegno da parte del tuo capo che questo andrà bene. Se tu o il tuo capo temete di poter rompere qualcosa aggiungendo commenti, aggiungeteli in un ramo separato e chiedete al vostro capo se si prenderà il tempo di rivedere i vostri commenti prima che vengano uniti al tronco. Dal momento che il tuo capo ha un budget limitato di tempo, prova a capire cosa fa una certa parte da sola investendo una quantità ragionevole di tempo. Se ti blocchi davvero, scrivi la tua domanda in una lista e chiedi al tuo capo, per esempio, una volta al giorno invece di disturbarlo ogni 30 minuti. Secondo la mia esperienza, questo approccio funziona con molte persone, anche se sono molto impegnate, purché siano disposte ad aiutarti - il che è sicuramente il caso della tua situazione.

In questo modo, sei sicuro di ottenere i commenti di cui hai bisogno e il tuo capo vedrà dove hai bisogno di ulteriori informazioni e se hai le cose giuste. E finché ti limiti a commentare solo le cose non ovvie, c'è una buona probabilità che i tuoi commenti aumentino la qualità generale della base di codice, il che potrebbe non solo portare beneficio non solo a te, ma anche a tutti gli altri che ha a che fare con il codice, incluso il tuo capo.

Per prima cosa lascia che sia un esempio per commentare correttamente il tuo codice, cavalletta!

Quindi, devo farlo sempre. Ho controllato la mia copia locale, la analizzo e la commenterò personalmente. (Posso rimetterli tutti di nuovo fuori se devo controllarlo di nuovo - o lasciarli dentro, se nessuno ha problemi.) Poi, quando davvero non posso vedere oltre, posso chiedere a qualcuno, qui, penso che faccia questo (cosa ho commentato), ho ragione? Quindi potresti aver fatto il commento effettivo, ma è fatto e questo è il punto.

Questo è più di una semplice richiesta personale. Stai cercando di cambiare abitudini / cultura e non è facile. Non è certamente qualcosa che può essere realizzato da una conversazione di corridoio o una e-mail. Ci vorrà un po 'di sforzo da parte tua.

Be the change that you wish to see in the world.

La citazione può essere falsamente attribuita a Mahatma Gandhi, ma è un consiglio applicabile. Mentre provi a risolvere il problema con il codebase, scrivi i commenti che vorresti vedere, al meglio delle tue capacità e impegnali, dopo essere stati esaminati dal tuo capo. Vantaggi:

• Sei proattivo, piuttosto che fastidioso.
• Stai dando il buon esempio. Nel migliore dei casi, il tuo capo / team vedrà i benefici e seguirà l'esempio.
• Alcuni commenti probabilmente diranno /* Mystery parameter 3 */ o /* 2015-02-09 AidanQuinn: Is this code ever called? */ - queste sono opportunità per i tuoi colleghi per documentare correttamente il codice o correggere bug latenti.
• Se, durante la revisione pre-commit, viene rilevato che un commento che hai scritto è impreciso, i tuoi colleghi ora sanno che il codice non è chiaro.

Astenersi da qualsiasi riscrittura o refactoring mentre lo fai, e l'introduzione di commenti dovrebbe essere quasi priva di rischi. Se riscrivi qualsiasi cosa, mantieni le modifiche come commit separati.

(Prima di intraprendere questo progetto, però, assicurati che le tue aspettative per i commenti siano ragionevoli.) Se la tua idea di codice ben commentato è al di fuori della norma ( Esempio 1 , Esempio 2 ), quindi ti prenderai in giro di te stesso.)

Non vorrei chiedere ulteriori commenti, ma ecco alcune idee per te:

1. Pianifica una riunione con il tuo capo e fallo passare attraverso il codice ad alto livello. Questo dovrebbe farti cominciare. Mi aspetterei da poche ore a forse una mezza giornata, così puoi stare al passo. Questo dovrebbe includere la progettazione generale, i modelli usati, ecc.
2. Crea un progetto di test e inizia a scrivere test unitari contro il codice, questo ti aiuterà a capirlo senza alcun impatto. Potresti anche trovare alcuni bug!
3. Eseguire il debug del codice in base alle esigenze per comprendere determinate aree.
4. Prendi un miglioramento o un bug dal backlog e lavoraci sopra.

I commenti sono OK, ma se il codice è scritto in modo diretto dovrebbe essere comprensibile dopo alcuni giorni.

Inoltre, non aspettarti di capire tutto, è meglio concentrarti prima su aree chiave e poi espandere la conoscenza del codice base, se necessario.

Sono stato in una situazione molto simile alla tua all'incirca un anno fa. Ho iniziato a lavorare con poca esperienza di programmazione (sebbene conoscessi un po 'di OO e alcuni altri linguaggi per cominciare) e l'unica persona che mi ha insegnato ha avuto pochissimo tempo. Era sempre disponibile, ma sentivo che non avrei voluto porre ogni singola domanda che avevo.

Altri hanno già suggerito cose estremamente utili qui (scrivendo test di unità, ad esempio, ma dalla mia esperienza personale, è qualcosa che sarebbe andato un po 'troppo lontano per me da zero, o commentando parti del codice da soli, ma potrebbe essere difficile a seconda del primo punto / domanda che ti chiederò tra un minuto). I seguenti punti riassumono ciò che ho fatto e ciò che mi ha aiutato, ma dipende molto da dove si trovano esattamente i tuoi problemi.

Inoltre, devo concordare con @AK_ che ha affermato che non hai davvero bisogno di commenti in C #. Ciò potrebbe non essere corretto al 100% (ritengo che ci siano aree in cui i commenti aiutano sicuramente, ad esempio il codice di Reflection-heavy) ma in sostanza lo è. Se scrivi veramente "codice pulito" con metodi e variabili ben definiti e hai molti piccoli "morsi" di codice, saranno quasi del tutto inutili. Ogni volta che sentivo il bisogno di commenti quando leggevo il codice fino a quel momento, dopo aver capito che cosa faceva, ero molto scontento di come era fatto e pensavo che avrebbe potuto essere più chiaro in primo luogo con un buon refactoring. Modifica: sto specificatamente parlando di C # commenti qui, non di documentazione (che si tratti di documentazione separata o commenti XML), poiché ritengo che la documentazione sia sempre importante.

• Identifica quali sono esattamente i tuoi problemi e se puoi categorizzarli. Cioè, hai ancora problemi con la lingua stessa o non capisci una sintassi specifica (ad esempio espressioni lambda e LINQ in generale, o Reflection)? Se non capisci le linee di codice, non capirai cosa fa l'intero metodo / blocco, quindi commentarlo tu stesso sarà difficile. Piuttosto, prendi un buon libro ("C # in a Nutshell" era per me, ma ho sentito anche "C # in Depth" è spettacolare) e leggo le cose che incontri. La classificazione di questi problemi in anticipo rende tutto più semplice, in quanto è possibile colmare "lacune maggiori" contemporaneamente, o addirittura chiedere al proprio capo, poiché non sono più molte domande, ma piuttosto spiegare un singolo argomento o i costrutti più comunemente utilizzati in modo da può ottenere rapidamente un enorme 'boost' in quest'area.

• Parallelamente a quanto sopra, ho provato a familiarizzare con la "codifica pulita" e le migliori pratiche generali (non specifiche per la lingua). L'effetto di questo potrebbe non essere immediato, ma prima o poi lo ripagherà, o quando devi estendere materiale esistente o ti chiedi perché qualcuno abbia creato tanti piccoli metodi invece di uno in cui tutto è contenuto; -)

• Scopri i modelli di progettazione più comuni. Possono apparire qua e là nel codice che stai leggendo, e se li riconosci ti darà immediatamente un momento agli a-ha. Anche se capisci che cosa fa il codice che vedi, potrebbe farti chiedere perché è stato fatto in questo modo, e capire tutto questo da solo spesso non è così facile.

Per favore, non prendere il testo di cui sopra mentre faccio supposizioni sulla tua "abilità", spesso accidentalmente cambio tra parlare delle mie esperienze e parlare "con te". È principalmente inteso come cosa ho incontrato e cosa ho fatto . Come altri hanno già detto, questa può essere un'esperienza molto positiva ed è praticamente lo standard nel lavoro per leggere il codice che non è il tuo e che non sai molto in anticipo. Ma può essere davvero soddisfacente capire finalmente cosa sta succedendo lì e riconoscerti migliorando questa particolare 'abilità'. Prendi questo come un'opportunità per imparare un lotto in brevissimo tempo, buona fortuna! :)

Probabilmente non lo farai cambiare stile.

Quello che puoi fare è fare molte domande e scrivere le risposte.

Ho ereditato un'enorme base di codice nel mio ultimo lavoro, poca documentazione e pochi commenti. Quindi proverei per mezz'ora sullo stesso problema, quindi se ancora non riuscivo a capirlo, andrei a chiedere a qualcuno che l'ha scritto, o sapevo come usarlo. Quindi vorrei documentare tutte le cose che mi ha detto. Molti sono andati nella nostra documentazione, alcuni sono entrati nel codice come commenti. Dopo un anno in cui avevo praticamente scritto una gran parte della nostra documentazione e sapevo molto sulla base del codice.

Buona fortuna!

Stavo avendo lo stesso problema. Sono uno studente di phyzist e ho una buona esperienza di programmazione. Stavo programmando in molte lingue ma nulla per l'aplication premium.

Ho fatto domanda per un posto di lavoro per sviluppatore web e mi hanno immediatamente messo in coda alla programmazione web. Quando il capo mi ha mostrato l'API di base per l'applicazione REST nodo ho pensato che avrei buttato fuori. Non ho mai visto funzioni con callback e sintassi così strana. E chiedo al mio capo di avere un problema Se non capisco nulla nel codice. Lui triste no, è triste che ho 1 mese per capirlo e nel frattempo farò un CMS per testarmi con un altro frontender.

Bene e ho fatto 1 riga di codice al momento e google ogni cosa che non conosco. Così è passata una settimana e conoscevo il codice abbastanza da poter fare un po 'di collaborazione con front ender. Il mio codice all'inizio è stato pessimo, ma mi ci sono voluti 3 mesi dopo! Sto codificando meglio e più velocemente del nostro software architect!

Mi dispiace che tu non abbia mai smesso di imparare! La mia moto - > Continua ad imparare e mantieni la calma :) Non dipendere dal fatto che il capo sia indipendente e chiedigli direttamente ma solo i problemi più difficili. Perché sarai felice dopo averlo scoperto dal tuo stesso resarch. E ricorda quando smetti di apprendere qualcosa di sbagliato, impara il giorno dell'ebraio come diventare un buon programmatore.

Se imparerai dal capo non andrai mai meglio di lui, stabilisci il tuo standard, impara la scrittura cieca, il plugin VIM o VIM per il tuo IDE, Linux wmii, quindi un giorno andrai oltre il capo e sarai migliore di lui!

Ecco i miei $ 0.02 sull'argomento. Non sto suggerendo una risposta esclusiva, molto di ciò che è stato detto qui è abbastanza rilevante.

Vorrei provare un po 'di ingegneria sociale per organizzare le cose in modo che il tuo capo trovi più facile / meno dispendioso in termini di tempo per commentare alcuni dei suoi codici piuttosto che non farlo.

Ora, questo può essere piuttosto facile se tu fossi disposto a correre un grosso rischio e infastidirlo, ma non vogliamo farlo. (nota a margine: potresti semplicemente non essere in grado di fare nulla senza scrivere o dettare commenti a te, lo insisti e lo tormenta all'infinito ecc.)

Qual è l'alternativa, allora? Alcune idee, a seconda delle circostanze.

Opzione 1

1. Prenditi il tempo per capire un pezzo del suo codice come fare X.
2. Ora pensa a un modo ragionevole Y per fraintenderlo .
3. Dì al capo (via email o dì prima o dopo colazione) cosa stai cercando di capire.
4. Aggiungi un commento che dice che non è chiaro cosa significa il codice, ma lo capisci come Y; prova a rendere questo commento visibile a lui - ma non sforzarti troppo!
5. Agisci assumendo Y - e rendi sicuro che il tuo capo avvisi la tua azione (quindi non perdi tempo a lavorare per un lungo periodo su una falsa ipotesi).
6. Boss dovrebbe prendere l'iniziativa per correggerti. A questo punto, digli qualcosa del tipo "Vorrei davvero che questo codice avesse un paio di commenti per impedirmi di fare l'ipotesi sbagliata, correggerò il commento che ho aggiunto per me stesso. Supponi che potresti aiutarmi con qualche descrizione generale di questo e quel pezzo di codice? Non ho esperienza sufficiente per capire l'intenzione esatta, e sono solo un paio di frasi che farebbero il trucco. " O qualcosa ..

Opzione 2

Ti stai allenando. Cerca di organizzare un incontro settimanale (aggiuntivo?) A frequenza fissa con lui. In questa riunione, vai su un po 'di codice, ma devi essere preparato abbastanza perché non debba spiegare ogni singola riga. Ad un certo punto - si spera - si renderà conto che può saltare la riunione se ha appena aggiunto i commenti.

Opzione 3

Fai in modo che un altro collega non riesca a capire lo stesso codice di te. Entrambe si avvicinano al capo in momenti diversi, ponendo le stesse domande. Questo è un modo infallibile per fargli capire che sta fallendo nel fare qualcosa ... ma non tutti hanno il lusso di utili collaboratori sullo stesso progetto.

So just something that will help my out until I get a grip on things, how can I ask my boss to put comments into his code that he gives me, but politely?

Se non riesci a capire il codice, perché pensi che i commenti siano la tua soluzione?

Non conosco il suo stile di programmazione, ma ammetto che se il nome di funzioni e variabili è fuorviante, rende molto difficile la comprensione di un codice. Ma se i nomi e le funzioni o persino l'organizzazione del programma (classi, metodi, proprietà ...) sono tali da rendere comprensibile il codice, allora il codice in realtà ti parlerà da solo.

Faresti meglio a chiedergli l'architettura del programma e se vuoi chiedergli qualcosa, richiedi qualche nome più significativo per le funzioni; questo è più conveniente per lui.

Anche se c'è un modo per chiederlo in modo educato, ci sono due possibilità su ciò che il tuo capo penserà riguardo ai commenti nel suo codice:

1. O quel commento nel suo codice sarebbe una buona cosa da avere, o

2. I commenti nel suo codice non sarebbero una buona cosa da avere.

Se il tuo capo pensa che i commenti nel suo codice non sarebbero una buona cosa da avere, (e ci sono ottimi argomenti per questo, cioè il codice dovrebbe essere la documentazione , e < in nessun caso la documentazione stabilirà mai qualcosa di preciso e non ambiguo come il codice che effettivamente lo fa , quindi non accadrà nulla.

Ora, se per caso il tuo capo pensa che i commenti nel suo codice sarebbero una buona cosa da avere, allora c'è una considerevole probabilità che ti dirà di studiare il suo codice, capire come funziona, e procedere ad aggiungere commenti al suo codice te stesso . (Ci sono ottimi argomenti anche per questo, cioè devi imparare , e il suo tempo è per definizione molto più prezioso del tuo .)

Quindi, a meno che tu non sia disposto a farlo, potresti stare meglio senza dire nulla.

Come ingegnere informatico di 20 anni in piedi, che lavora principalmente su argomenti relativi alla sicurezza (SF-PD), dovrei dire che il tuo capo potrebbe non essere la persona che vuoi essere il tuo esempio. La mancanza di commenti è un segno di un programmatore amatoriale autodidatta che non ha mai imparato come fare correttamente il lavoro, o un ingegnere inesperto. O forse un ingegnere che semplicemente non ha il tempo - le scadenze e le convenienze possono fare cose orribili al tuo codice! ;) È sicuramente un anti-pattern per ogni ingegnere del software competente però.

Il tuo capo potrebbe essere un ottimo programmatore, ma sembra che non sia un bravo ingegnere del software. Un ingegnere usa l'esperienza collettiva di gruppo per evitare le insidie che altre persone sono già state scoperte. Un commento efficace fa parte dell'esperienza collettiva di gruppo per il software, nello stesso modo in cui l'analisi dello stress fa parte dell'esperienza collettiva di gruppo per l'ingegneria meccanica. Ciò che conta è che i commenti efficaci sono più fluidi, ed è sicuramente qualcosa che ottieni dall'esperienza.

La cosa più semplice è che i commenti non dovrebbero dire cosa fa una riga di codice. Ci sono momenti in cui i commenti per dire cosa sia una funzione sono superflui (specialmente in C #). I commenti eccessivi possono essere altrettanto inefficaci (e un puntatore alla mancanza di esperienza) perché non riesci a trovare le cose importanti nelle scorie. Come novizio, potresti ancora lavorare per capire il "cosa" del codice, e per questo hai solo bisogno di leggere e capire cosa ha fatto.

La cosa importante per i commenti è che dicono PERCHÉ una linea di codice o una funzione fa quello che fa, dove questo potrebbe non essere ovvio. Devi configurare il modulo X prima del modulo Y? È importante controllare un codice di ritorno per vedere se un file era già aperto o ignoriamo consapevolmente il codice di ritorno perché questo è stato controllato da qualche altra parte? Il "perché" del codice sarà rilevante per tutti, indipendentemente dall'esperienza - e sarà rilevante anche per lui tra 6 mesi, quando si dimenticherà della buona ragione per fare qualcosa in un modo particolare. Commentare non è solo per le altre persone, è per aiutarti anche in futuro.

Se vuoi evitare di annoiare il tuo capo, fai domande intelligenti. Concentrati sul chiedere il "perché" e cerca di capire il "cosa" (a meno che non sia veramente oscuro). A nessun buon capo verrà in mente di fare domande se non sono il tipo di cose che potresti aver trovato da R-ing TFM. E a nessun buon ingegnere verrà in mente di essere invitato a fare qualcosa che renderà la vita di un altro ingegnere molto più semplice, con un piccolo costo per loro. (Basta non chiedergli di recuperare i commenti sull'intera base di codice!;)

Sono passato nella stessa situazione, direi

1. Il tuo capo potrebbe desiderare che tu impari il modo sporco (camminando attraverso il codice di cui non hai idea) per un motivo. Questo è il modo in cui impariamo di più in un mese di lavoro rispetto a un anno al college, come menzionato in altre risposte.

2. Questa è "la norma" come menzionato in altre risposte. Dovresti essere più preoccupato di dove cominciare e come avvicinarti e su cosa concentrarti piuttosto che cercare di capire subito ogni linea di codice. Chiedi al tuo capo quali sono gli strumenti giusti e i modi per eseguire il debug / passaggio del codice. Questo tipo di domande ti comprerà alcuni punti.

3. Su base regolare, continua ad avvicinare il tuo capo per ricevere feedback su come stai facendo in modo da farti un'idea su dove ti trovi in termini percentuali presumendo che il tuo capo abbia visto un buon numero di persone nella stessa situazione e abbia un idea come hanno fatto.

4. Considera questa un'opportunità e man mano che migliora la comprensione del codice, continua ad aggiungere commenti che ti aspettavi originariamente chiedere al tuo capo.

Se vuoi davvero provare a chiedergli di inserire commenti nel suo codice (non lo consiglio) ti suggerisco di trovare il codice che devi modificare che potrebbe davvero usare alcuni commenti (la maggior parte è auto-esplicativo) e chiedere la domanda su come questo "stavo guardando questo codice qui e sto cercando di capire [il problema che stai avendo] e non sono riuscito a trovare alcun commento per aiutarti a spiegarlo". Praticamente cerca di dimostrare che hai fatto sforzi per comprenderlo e spiegare perché entrambi potrebbero trarre beneficio dai commenti che ci sono.

Probabilmente il 90% del codice ben scritto non ha bisogno di commenti. Vuoi veramente solo documentare le parti di codice che sono state ottimizzate e sono diventate piuttosto tese. Una volta ho lavorato in una società che richiedeva la documentazione di ogni pezzo di codice che hai modificato, in pratica i commenti finivano per essere dannosi per la leggibilità del codice perché spesso si riferivano a codice che era stato rimosso o modificato oltre il riconoscimento. Attenti ai commenti scadenti Ho passato una settimana a eseguire il debug di una funzione e alla fine ho scoperto che il commento che continuavo a leggere sull'impostazione di una tale bandiera su "false" era in realtà l'intero problema impostando la bandiera su "true" e tutto funzionava come doveva.

Se vuoi che i commenti nel codice comprendano perché è stato scritto qualcosa allora molto probabilmente (considerando che sei nuovo) non comprendi ancora le esigenze del business. Sono sicuro che conosci tutta la sintassi e puoi leggere il codice ma a meno che tu non conosca lo scopo di qualche codice, ti sentirai un po 'perso.

Una cosa che mi viene in mente è la programmazione a coppie. Dici che il tuo capo è impressionato dai tuoi progressi in modo da poter suggerire di lavorare al suo fianco. Questo aiuterà entrambi a lungo termine. Il tuo capo si troverà a dover spiegare le cose che dà per scontate e imparerai di più sul business.

Come altri hanno già detto, questo è abbastanza comune, ma questo non significa che devi solo succhiarlo e cavarsela. Non hai bisogno di capire la maggior parte del codice in profondità quanto pensi di fare, e ci sono strategie concrete per rendere il "deep end" molto meno profondo:

• trova qualcosa nel codice relativo all'attività in corso. Di solito il modo più semplice per cercare è qualcosa visibile all'utente, come l'etichetta del pulsante sulla GUI. Annota dove l'hai trovato. Questo sarà il tuo punto di ancoraggio.
• Ora cerca il codice ad un passo e scrivilo. Chi crea il pulsante? Quale codice viene chiamato quando si fa clic sul pulsante?
• Il controllo del codice sorgente è spesso utile per trovare il codice ad un passo. Trova quando il codice che stai guardando è stato aggiunto o modificato e guarda cos'altro è stato archiviato allo stesso tempo e perché.
• Ripeti finché non capisci quanto basta per apportare le modifiche, più un livello più profondo per assicurarti di non perdere nulla.
• Se ti blocchi in qualsiasi momento, ora hai una domanda molto specifica da porre. Ad esempio, "Non riesco a capire da dove viene creato questo pulsante."