Come evitare di saltare a una soluzione sotto pressione? [chiuso]

Quando entro una scadenza di programmazione particolarmente rigida (come un'ora), se mi faccio prendere dal panico, la mia tendenza è quella di saltare al codice senza un vero piano e spero di capirlo mentre procedo. Dato abbastanza tempo, questo può funzionare, ma in un'intervista è stato abbastanza infruttuoso, se non addirittura controproducente. Non mi sento sempre a mio agio seduto lì a pensare mentre il tempo passa.

Esiste una lista di controllo o ci sono tecniche da riconoscere quando capisci il problema abbastanza bene da iniziare a scrivere codice? Quando è più produttivo pensare e progettare di più rispetto al codice di alcuni esperimenti e capire in seguito il progetto complessivo?

Ecco un elenco di tecniche per sostenere un test di matematica e un altro per sostenere un esame orale . Esiste un elenco simile di tecniche per gestire un problema di programmazione sotto pressione?

RISPOSTE: Penso che questa sia una risposta valida: come risolverlo . Ho trovato quel link come una risposta a Steps per risolvere o avvicinarsi a una soluzione . Ci sono stati anche dei buoni consigli a Pensare ad alta voce durante un'intervista è davvero la migliore strategia? . Un grande e conciso argomento per TDD è la prima risposta a TDD Writing code vs Capire la risposta a un problema? .

Ricordo di aver letto uno studio su come gli incendi formino un piano d'azione all'arrivo sulla scena di un incendio; lo studio li ha osservati (e li ha condannati) per aver avuto un'idea, quindi perseguire immediatamente quella prima idea. A causa della pressione del tempo, era praticamente "questo potrebbe funzionare" seguito da "ok, facciamolo". Lo studio ha osservato che erano disponibili opzioni migliori, più rapide e più sicure, ma non sono state seguite semplicemente perché i marshall non ci hanno pensato prima.

Se vuoi un approccio strutturato per affrontare i "fuochi", forse prendi un foglio dal loro (nuovo) libro che prescrive diverse fasi:

RRAPID

1. Reazione - Mobilitare le risorse per l'incidente
2. Ricognizione: raccogli dati sulla situazione
3. Apprezzamento - Scegli un corso d'azione basato sugli scenari migliori e peggiori
4. Piano: sviluppa un piano basato sul corso di azione
5. Emissione degli ordini: utilizzare il formato di briefing standard
6. Distribuzione: eseguire e monitorare

o in termini più generali:

1. Sveglia tutti e muovili
2. Scopri cosa sta succedendo
3. Soluzioni di brainstorming
4. Scegline uno e pianificalo
5. Dì a tutti qual è il loro lavoro
6. Eseguire e monitorare

Comincio sempre con la comprensione dei requisiti e la ricerca di lacune che richiedano risposte.

Quindi disegno (molto approssimativamente e su carta o una lavagna) due o tre possibili soluzioni. Quindi mi chiedo: "C'è qualcos'altro che devo sapere per implementare qualcuno di questi?"

Una volta che ho una mia domanda iniziale (ci sono domande al 100% delle volte, se non ne hai nessuna, non hai davvero esaminato il requisito in modo approfondito), torno dagli stakeholder per ottenere le mie risposte.

Mentre sto dilettando sulle loro risposte, prendo in considerazione le mie soluzioni e vedo se qualcuna è migliore delle altre o sarebbe meglio una volta che avrò le risposte alle domande. Ad esempio, se il momento in cui ne hai bisogno è subito una domanda, potrei scegliere quello con lo sviluppo più veloce ma lasciando aperto un modo per migliorare il design in seguito. Se mi dicono che le prestazioni sono fondamentali, allora guardo le soluzioni e stabilisco quale è più probabile che funzioni meglio (queste sono ipotesi a questo punto, ma generalmente informate). Se è coinvolta una GUI, potrei creare un prototipo cartaceo di diversi progetti diversi e indurre gli stakeholder a guardarli prima di codificare qualsiasi cosa (di solito vedranno che si sono dimenticati di parlarti di XYZ, che è qualcosa di centrale nel design!)

Una volta ottenute le risposte, scelgo un progetto approssimativo e quindi faccio un elenco di tutte le cose che dovrò fare per implementarlo. Quindi inizio a scrivere codice.

... la mia tendenza è quella di saltare al codice senza un vero piano e spero di capirlo mentre procedo.

L'ho fatto mentre ero all'università. È diventato un vero problema e in genere si tradurrebbe in riscrittura del codice. Ho iniziato a risolvere questo problema non scrivendo codice. Ho posto l'accento sul pensiero del problema. Con abbastanza pratica, istintivamente raggiungo i miei pensieri piuttosto che una tastiera.

... in un'intervista è stato abbastanza infruttuoso, se non addirittura controproducente. Non mi sento sempre a mio agio seduto lì a pensare mentre il tempo passa.

Nel corso di un'intervista, ci deve essere un'implementazione ragionata, ben ponderata di una soluzione e non sempre è facile. Quello che non vuoi fare è dare una risposta senza pensare. Se conosci la risposta, dagli presto. Se non lo fai, affidati ai tuoi pensieri per ragionare su una soluzione. Indica sempre quando non conosci e dimostra come procedere per trovare una soluzione.

Esiste una lista di controllo o ci sono tecniche da riconoscere quando capisci il problema abbastanza bene da iniziare a scrivere codice?

Scoraggerei questo perché puoi fare affidamento su di esso rigidamente. Piuttosto, chiediti se hai capito il problema abbastanza bene da iniziare a scrivere codice. Come lo sapresti? Perché quando ragionerai sul tuo approccio e poi lo esaminerai, data la tua attuale conoscenza della lingua, avrà senso. Avere sempre un piano e un approccio. Ricorda anche che il codice non è mai finito e il codice che non si evolve morirà, quindi aspettati di tornare spesso al tuo codice.

Quando è più produttivo pensare e progettare di più rispetto al codice di alcuni esperimenti e capire in seguito il progetto complessivo?

Avrai voglia di conoscere il design generale e pensarci. Quindi inizi a creare la struttura della classe e gli stub. Quindi rivederlo di nuovo. Ha senso? Gli esperimenti di codifica sono un ottimo modo per dimostrare che qualcosa funziona bene e dovrebbero essere usati ma non fare affidamento sulla moda o sulla forma del codice che scrivi.