Quali sono le migliori pratiche quando si passa da un progetto all'altro o si torna di frequente ai progetti?

Passo spesso anche a diversi progetti (sia tecnici che non tecnici). Organizzazione o "facilità di recupero" è stata la chiave per me. Prima di lasciare un progetto, mi assicuro di mettere le cose in ordine in modo che sia facile per me riprendere il contesto nella mia testa. Per me, questo significa mettere tutte le cose rilevanti (segnalibri, file, documenti, email, ecc.) O link ad esse in una cartella in modo da non dover cercare fonti di informazioni.

Una cosa che ho iniziato a fare di recente è usare una macchina virtuale per ogni grande progetto. Quando ho bisogno di passare a un altro progetto, tengo tutte le app pertinenti aperte e quindi sospendo la macchina virtuale. Quindi, quando ho bisogno di tornare al progetto, posso avviare la VM e mi presenterà tutte le informazioni già sullo schermo.

Alcune cose che aiutano:

• Ottimizza al massimo il tuo codice per leggibilità e chiarezza.
• Lasciare puntatori e suggerimenti nel codice, sotto forma di commenti.
• Segui KISS e ASCIUGA.
• Sii coerente, all'interno di ciascun progetto e tra tutti i progetti.
• Sii religioso sul refactoring.
• Documenta tutto; considera il tuo sé futuro una persona diversa senza alcun modo di porre domande al tuo sé attuale.
• Evita il codice "intelligente" che rompe il tuo IDE / editor.
• Usa il controllo del codice sorgente, con i messaggi di commit che ti dicono esattamente dove hai lasciato le cose; modifica le versioni che ritieni possano essere spedite e mirare per brevi periodi tra le versioni disponibili.
• Se scegli il linguaggio di programmazione, scegline uno che ti aiuti a fare le cose bene.
• Questa è una questione di gusto personale, ma funziona bene per me, quindi lo raccomanderò comunque: mantieni un documento di testo semplice e conciso contenente le attività imminenti e aggiornalo ogni volta che finisci un'attività. Utilizzare questo documento anche per le note a livello di progettazione che non rientrano nei commenti di codice. Fondamentalmente, questo documento di testo dovrebbe contenere l'intero disegno, solo in forma condensata (sufficienti informazioni per dare un senso, ma abbastanza breve da riportarti in sella entro 10 minuti). Funziona anche un bug tracker, ma il documento di testo ha una serie di vantaggi: ti costringe a tagliare il fluff e concentrarti sui contenuti rilevanti, e può essere impegnato a controllare i sorgenti insieme al codice reale, il che significa che è naturalmente legato a Versioni SCM.

Faccio qualcosa di simile a ciò che fa RonE.

Avere un progetto di facile lettura, con un buon design aiuta, ma prima di lasciare un progetto, assicurati che tutto il contesto e le informazioni che hai in testa siano scritte o archiviate da qualche parte. Ad esempio, note sulle funzioni della libreria di terze parti che stavi usando se fosse una nuova che non hai mai usato prima. Scrivo sempre delle note sulle cose che imparo o penso, nelle mie stesse parole.

Inoltre, quello che trovo più importante scrivere in un file è se scrivi i commenti di TODO nel tuo codice, copia l'ultimo su cui stavi lavorando e lo incolli in un nuovo file di testo e chiamalo TODO. Scrivi in esso informazioni di contesto su dove si trova il tag TODO e scrivi ciò che avevi in mente o cosa pensi che vorresti sapere su quell'attività.

Due elementi sono stati fondamentali per me: coerenza e specifiche.

La coerenza è la chiave per il codice. Non ho bisogno di ricordare dove si trova tutto e come tutto interagisce se riesco a estrapolare ciò che avrei fatto. Se è un progetto con altri che diventa più problematico, ma gli standard di codice aiutano un bel po '. Sapere cosa è guardando e facendo alcune ipotesi sicure diminuisce un po 'il tempo di onboarding.

La specifica è più utile per il design. Almeno per me, trovo che io tendo a dimenticare alcune delle sfumature del design del prodotto dopo una pausa. O quando torno, è a causa di questa fantastica idea che si insinua prontamente nel progetto. Se il tuo progetto non ha buoni requisiti (in una specifica waterfall-y o in un backlog di prodotto) devi sostanzialmente reinventarli ogni volta che torni al progetto. Quasi tutte le migliori pratiche per lo sviluppo del software sono ancora le migliori pratiche quando si tratta di un progetto personale; non lesinare su di loro.

la chiave IMO è una API intelligente di ogni tuo progetto. Inoltre, il caricamento del codice in un repository come GIT o altri ti consente di "viaggiare nel tempo" tramite i tuoi commit al codice.

Poiché eseguo il supporto di sviluppo e produzione per diversi client, cambio i progetti più volte al giorno. Le due cose che mi aiutano di più non abbandonano mai un progetto finché non ho salvato tutto (e mi impegno in una filiale locale se non è nello stato che voglio riportare alla sezione principale del mio controllo sorgente) e io impostare un punto di interruzione nel punto in cui ho interrotto. Essere in grado di trovare rapidamente la linea esatta da cui ho interrotto mi aiuta a tornare più velocemente nello swing di un progetto. Tendo anche a creare un elenco di cose da fare per ogni grande progetto e controllare le cose come sono fatte, quindi una rapida revisione di ciò mi dice dove sono anch'io e mi ricorda il mio processo di pensiero sul progetto. In genere, inoltre, scrivo una breve nota a me stesso su cose a cui stavo pensando, ma che non avevo ancora fatto, se necessario (cose come: La XYZ continua a non funzionare, prova ad abcd dopo.)