Come posso migliorare nello spiegare il codice ad altri sviluppatori? [chiuso]

7

Anche se la domanda stessa potrebbe sembrare sciocca, la risposta è molto importante per me, poiché ritengo che il problema abbia un impatto negativo sulle mie prestazioni lavorative.

Un po 'di sottofondo qui: sono un esperto sviluppatore di software senior di medie dimensioni reparto software di società non software. Pur essendo al di sopra della media sul lato tecnico delle cose, Sono molto più povero nel comunicare e spiegare le cose. Anche quando spiega qualcosa ad altri sviluppatori.

Le maggiori difficoltà si verificano quando spiego come funziona un particolare piccolo pezzo di codice .

La cosa divertente è che spiegando e fornendo esempi su come qualcosa funzioni su un livello molto più alto, per esempio. le interazioni tra moduli separati e sottosistemi, per me è molto più facile.

Per renderlo più chiaro, ciò che chiamo "codice sorgente che spiega l'abilità" è un

a) capacità di spiegare chiaramente il flusso di esecuzione del codice - ad es. "questo thingy chiama quel thingy, che restituisce quell'oggetto, che in seguito chiama il metodo A, passando l'oggetto da B a ... "

a) capacità di spiegare chiaramente i problemi con un progetto corrente o, cosa più importante, implicazioni del codice sorgente come in "se, per le prestazioni ragioni, iniziamo a memorizzare l'oggetto nella cache come un campo della classe, dovremmo apportare modifiche in dieci posizioni diverse per garantire che la cache sia sempre in stato aggiornato "ecc.

Ho cercato di analizzare perché sono cattivo nello spiegare le cose e non ho trovato alcuna spiegazione tranne forse che spiego le cose in modo puntato, che alcuni potrebbero trovare troppo rigidi. Anche quando spiego le cose, forse mi concentro troppo su quello che dico io e mi manca le domande, ciò che le persone chiedono, ma ancora una volta mi sembra che queste domande siano spesso irrilevanti e semplicemente trascinano via la conversazione.

Cosa potresti raccomandare (tranne le ovvie "pratiche che lo rendono perfetto", che non comprerei davvero, come Penso che probabilmente eserciterei più volte gli stessi errori più volte) da parte mia, quindi potrei migliorare il codice sorgente spiegare le abilità.

    
posta Mitten 21.02.2013 - 16:14
fonte

3 risposte

4

Uno dei problemi è che piccoli pezzi di codice non sempre spiegano l'immagine più grande. Ad esempio, quando guardo un codice sorgente sconosciuto in un linguaggio di programmazione familiare di solito capisco la maggior parte delle singole affermazioni. Allo stesso tempo, potrei faticare a capire l'algoritmo non familiare a cui essi contribuiscono, il ruolo svolto dall'algoritmo nella soluzione completa e il motivo per cui tale algoritmo è stato scelto rispetto ad altre alternative. In un certo senso, anche se capisco queste affermazioni, non le capisco affatto.

Un esempio di questo è la classica funzione Root veloce inversa .

Alcune cose che trovo utili nel trattare questo:

  • Spiega il codice nella stessa lingua utilizzata dagli utenti.
  • Spiega il codice utilizzando i termini del programmatore standard, ad es. Termini come "buffer", "elenco", "singleton" sono familiari alla maggior parte di noi, come i termini matematici più comuni.
  • Spiega cosa stai facendo in termini di input e output.
  • Inventa parole per concetti per i quali non hai parole. A volte uso parole come "regolatore", "catena" o "wrangler" come una scorciatoia per alcuni concetti molto nodosi. Dopotutto, come sono stati inventati i termini ben noti in primo luogo.
  • Riconosci che, sebbene le poche righe di codice possano apparire semplici in sé, il loro ruolo in una base di codice più ampia potrebbe essere piuttosto complesso. Non è sempre possibile spiegarli senza fornire molte informazioni di base. In questo caso, forniscilo.
  • Fornisci esempi concreti.
  • Disegna diagrammi .
risposta data 21.02.2013 - 17:03
fonte
5

La ragione è semplice. Tu pensi come un programmatore.

Essere in grado di spiegare concetti ad alto livello è ciò che facciamo per tutta la vita quando vogliamo trasmettere idee. Tuttavia, quando programmiamo, ci mettiamo nella mentalità che dobbiamo capire come eseguire i compiti in termini di molti piccoli e dettagliati passaggi. Spiegare questo significa che devi convertire "passaggi piccoli e dettagliati" in qualcosa che chiunque può capire, che non è un piccolo ordine. Se queste cose fossero facili da comprendere, tutti potrebbero programmare. Questo è ciò che ci rende programmatori.

Tuttavia, come probabilmente hai indovinato, una cosa è capire come eseguire le attività in termini di molti piccoli passaggi dettagliati ed è tutt'altra cosa spiegarle bene.

Anch'io ho avuto qualche difficoltà in questa impresa, ma ho notato che alcuni trucchi mi hanno aiutato. Supponi di avere un metodo che hai scritto e devi spiegare come funziona:

  • Prima di iniziare con la prima riga, leggi il tuo metodo e ricorda quale sia lo scopo, quale scopo serve, quando viene chiamato, e perché è stato così che hai deciso di farlo. In breve, sai cosa fa. In questo modo, puoi rispondere alle domande in modo approfondito e in un modo che comprende il senso del metodo (cioè quando dicono "Non capisco il punto di questa linea", puoi rispondere, "Questo è ciò che crea un'istanza la connessione al database utilizzato in tutto il programma "piuttosto che" Che chiama il JDBC che usa la stringa di connessione per stabilire una connessione "che risponde alla domanda ma probabilmente non è ciò che lo rende chiaro).
  • Spiegare ogni riga del metodo in termini di ciò che ciascuna linea contribuisce allo scopo generale del metodo. Perché hai messo quella linea lì? Oh, giusto, questa linea chiama la classe responsabile della gestione degli input per verificare se ho bisogno di delegare delle azioni nel mio ciclo di rendering.
  • Ammetti quando il tuo codice è forse poco chiaro o potrebbe essere migliorato. Se trovi un codice che potrebbe non essere chiaro, riscrivilo per renderlo più chiaro. Non aiuta la comunicazione a frustrare il tuo collega programmatore nel pensare che dovrebbe capire quello che sta vedendo.

In generale, concentrati sul motivo per cui inserisci quel codice piuttosto che su quello che fa, e scoprirai che le tue spiegazioni fluiranno più facilmente e saranno più facili da capire.

    
risposta data 21.02.2013 - 16:43
fonte
1

Mi sono anche trovato in una posizione simile a volte alle prese con la spiegazione del flusso di esecuzione del codice a un livello basso. Ciò che mi ha aiutato è stato prendere in mano la guida del linguaggio di programmazione in questione (Bjarne Stroustrups Programming in C ++) per aggiornarmi sulla terminologia che inevitabilmente si era sbiadita nel corso degli anni. Inoltre, leggi articoli e blog pertinenti alla nuova lingua per tenerti aggiornato con le tecniche / i termini correnti.

Riguardo a problemi / implicazioni di progettazione complessi: È corretto dire "Non posso darti una risposta senza fare ulteriori analisi" senza dare una risposta immediata. Il software può diventare molto complesso e persino gli sviluppatori più intelligenti non possono mantenere tutte le interazioni in testa per tutto il tempo - in più siamo tutti umani e ci sbagliamo o ci perdiamo qualcosa.

Prendi tempo per andare via e analizzare il codice in modo da poter essere più sicuro della tua risposta. Sarebbe certamente meglio che dare una risposta immediata, forse disinformata e sbagliata. Da una posizione di senior developer sarebbe considerata saggezza e andrebbe a tuo favore invece di sembrare reattiva ma potenzialmente sciocca!

    
risposta data 21.02.2013 - 16:48
fonte

Leggi altre domande sui tag