Come pensa un programmatore? [chiuso]

Question

Questa potrebbe essere una domanda irrimediabilmente vaga. Ma sono interessato a sentire qualunque processo di pensiero logico attraversi la gente quando apprende un nuovo concetto o cerca di mettere il cervello attorno al codice che non avrebbe mai visto prima.

Fondamentalmente, quali passi generali si prendono per abbattere i problemi e cosa ci vuole per "ottenerlo"? Se dovessi tracciare un diagramma di flusso di come funziona il tuo processo mentale quando guardi il codice o provi a risolvere un problema, come potrebbe essere?

Quali riferimenti comuni, suggerimenti e ipotesi mentali trovi utili nella risoluzione dei problemi?

In che modo differisce tra domini diversi? Ad esempio, in che modo il processo di pensiero di un programmatore web è simile o diverso dal processo di uno sviluppatore di app desktop tradizionali?

Answer 1

Sono fermamente convinto che, indipendentemente dal tipo di applicazione che stai guardando per la prima volta, che si tratti di un'app Web, un'app desktop, un driver di dispositivo o qualsiasi altra cosa, ci sono tre passaggi uno lo sviluppatore di solito segue per capire come funziona:

Ingrandisci l'immagine:

• Che tipo di app è questa (web, desktop, ...)?
• Come è stratificato (standalone, client-server, n-tier, ...)?
• Qual è lo scopo dell'app? Cosa dovrebbe fare?
• Per chi è fatta l'app?

Guarda come funziona:

• Quali lingue sono (sono) utilizzate?
• Come è strutturato il codice?
• Come sono strutturati i dati?

Comprendi (o almeno prova a) il modo in cui l'app è stata pensata:

• È stato pensato fino in fondo?
• L'app è chiaramente ottimizzata? (Per spettacoli? Per leggibilità?)
• L'app è finita? O c'è spazio per le evoluzioni?
• Ci sono segni di più versioni?
• ecc ...

Il 1 ° e il 2 ° passaggio sono puramente tecnici, mentre il 3 ° DEVE essere il più non tecnico possibile ... riguarda più la psicologia e la comprensione di come l'app è stata costruita. Richiede ovviamente esperienza, ma fintanto che pensi abbastanza e non perdi tempo nel cervello con i dettagli tecnici, alla fine lo otterrai.

L'intero processo non dovrebbe richiedere l'uso di una tastiera. Dovresti solo leggere, pensare e prendere appunti su un foglio (non sto scherzando: carta e penna!).

Answer 2

Ciao, buona fortuna con questo. È un'ottima domanda e sono sicuro che otterrai tantissime risposte. Anche se devo dire che non posso dare una risposta soddisfacente a questo - l'ultima cosa che descriverei i miei processi di pensiero come un diagramma di flusso - non penso che ci sia una formula d'oro per questo.

L'unico consiglio nella risoluzione dei problemi che posso consigliare è discuterne con qualcun altro. In quei momenti in cui colpisci un muro di mattoni, attraversarlo con un collega è prezioso. Molto spesso, in realtà, non aggiungeranno nemmeno molto alla discussione: nel processo di divulgazione di tutti i pensieri, la soluzione può diventare chiara.

Answer 3

Le persone sono notoriamente cattive nell'esaminare i propri processi di pensiero, ma ci darò un vortice. Eseguo un test molto elevato per l'abilità visuo-spaziale nei test QI, medio-alto per le abilità verbali e moderato per le abilità matematiche (spiega il mio grado di matematica A-level, suppongo). e quando inizio a progettare software, penso in termini di forme e connessioni tra di loro. Quando si tratta di descrivere questi pensieri agli altri (o chiarirli per me stesso), utilizzo semplici diagrammi a blocchi o diagrammi di oggetti presi dal metodo Objectory di Jacobson - NON le cose troppo complesse suggerite da UML. A volte scrivo descrizioni testuali di cose complesse, principalmente come promemoria per me stesso, ma non uso mai numeri o matematica.

Certo che sono solo io - ho lavorato con i whizz di matematica che erano programmatori altrettanto bravi o persino migliori di me.

Answer 4

Non credo ... lo elaboro.

Questo è in realtà meno capovolgimento di quanto sembri. Divido sempre i compiti nei loro componenti e poi li scompongo ulteriormente, e questo non vale solo per la scrittura di software! Proprio come @Mark Pim U attraversa le cose in sequenza.

Mia moglie si arrabbia molto quando preparo la cena perché ci metto così tanto tempo per iniziare.

Answer 5

Divide & amp; Conquer

Comincio cercando di afferrare l'intero problema così com'è, quindi inizio a trovare schemi che posso riconoscere e faccio lo stesso per loro in una sorta di processo ricorsivo, fino a quando non ho una soluzione scomposta che posso implementare e seguire più facilmente.

Answer 6

Questa è una delle rare volte in cui risponderei con "funziona". Imparo le cose scorrendo a vapore attraverso di loro. Non ho espedienti o dispositivi per aiutarmi. Mi ci è voluto un po 'di tempo per imparare PHP, ma poi Javascript era molto più semplice. Una volta affrontato un aspetto, gli articoli successivi diventano cumulativamente più facili.

Answer 7

Personalmente, conduco un dialogo interno con me stesso "OK, quindi dobbiamo scorrere questo elenco di numeri interi". 'Ma possiamo rompere quando troviamo il valore che vogliamo.' "OK, l'elenco verrà sicuramente inizializzato quando inizieremo?"

Sarei interessato a vedere se erano state fatte ricerche psicologiche sulle tecniche di risoluzione dei problemi.

Answer 8

Simile a Jonathan Sampson - in un certo senso funziona.

Quando sto attaccando un problema reale, provo a pensare al modo più logico per affrontarlo. Quindi, quando tutto va storto (come al solito), devo fare centinaia di schivate per fare le cose. Continua a concentrarti su quell'obiettivo finale, in quel modo logico e ci arriverai.

Alla fine, però, decide di funzionare per me e finisco con un prodotto finito che di solito non è come quello che avevo pianificato. Finché i clienti sono felici, lo sono!

Answer 9

Personalmente, vedo il codice nella mia testa in modo pittorico piuttosto che testuale (come Neil Butterworth) - è un po 'difficile da descrivere poiché (citando STIV) "non esiste un quadro di riferimento comune."

Answer 10

La mia abilità principale è identificare somiglianze tra modelli o sistemi che già conosco e il compito da svolgere. Le connessioni tra alcuni di questi possono sembrare piuttosto astratte; la chiave è individuare i collegamenti. Ciò porta all'astrazione di schemi e approcci comuni che sono ampiamente applicabili. A questo proposito, la cosa più importante che ho imparato sugli algoritmi è che il problema non è mai "inventare un algoritmo intelligente per risolvere X". È "il problema del modello X in modo tale che possa essere risolto dall'algoritmo intelligente esistente Y".