Pausa caffè #13: Ciò che ogni principiante della programmazione dovrebbe sapere; 4 modi per incorporare il Design Thinking nel tuo processo di sviluppo

Ciò che ogni principiante della programmazione dovrebbe sapere

Fonte: Stackoverflow Come sviluppatore, ascolterai molte teorie diverse su come dovrebbe apparire il codice. Alcune persone credono che meno righe di codice ha un'applicazione, più facile sarà leggerla. Ma questo è vero solo in parte. Preferisco valutare la qualità del codice utilizzando i seguenti criteri:

1. Il codice dovrebbe essere coerente, informativo e ben documentato.
2. Il codice dovrebbe utilizzare funzionalità stabili e moderne.
3. Il codice non deve essere inutilmente complesso o interrotto.

Se decidi di ridurre il numero di righe di codice a scapito di uno dei criteri sopra indicati, questo diventerà un problema. Non farlo.

Leggere il codice di qualcun altro è difficile

In effetti, il rapporto tra il tempo dedicato alla lettura e alla scrittura del codice è superiore a 10 a 1. Ma non puoi fare a meno di leggere il codice di altre persone. Dovrai leggere il codice di qualcun altro. E prima migliori le tue capacità, meglio è. Prova a studiare il codice di altre persone utilizzando i repository GitHub aperti. Puoi esercitarti in qualsiasi momento: basta trovare il progetto adatto a te e approfondire ogni riga. Un altro modo per migliorare la tua capacità di leggere il codice di altre persone è iniziare a copiare lo stile. Quando scrivi codice nello stile di qualcun altro, non solo migliori le tue capacità di lettura, ma ti rende anche il codice più familiare. Provaci.

Non scriverai mai un codice “perfetto”.

Sono stato uno sviluppatore solista per quattro anni prima di iniziare a lavorare in un team. Per la maggior parte del tempo, ho creduto che qualsiasi programmatore esperto scrivesse un codice perfetto. Secondo me, imparare a scrivere codice perfetto è solo questione di tempo e fatica. Ma quando mi sono unito al team, è diventato chiaro che nessuno scrive codice “perfetto”. È vero, il codice che alla fine veniva incluso nel sistema era quasi sempre “perfetto”. Perché è successo questo? È tutta una questione di analisi del codice. Lavoro con un team di ingegneri davvero brillanti. Questi sono alcuni dei programmatori più competenti e sicuri che il denaro possa assumere. Ma ognuno di loro (me compreso) avrebbe un vero e proprio attacco di panico se qualcuno suggerisse di includere codice non testato nell'applicazione. Anche se pensi di essere il prossimo Bill Gates, commetterai degli errori. Non parlo nemmeno di errori logici, parlo di errori di battitura, di caratteri mancanti. Cose che il tuo cervello a volte non riesce a cogliere. Cose che si possono notare solo con occhi nuovi. Sforzati di lavorare con persone attente ai dettagli e disposte a criticare il tuo lavoro. All'inizio sarà difficile accettare le critiche, ma è l'unico modo affidabile per migliorare la qualità del tuo codice. Fai del tuo meglio per non metterti sulla difensiva durante la revisione del codice e non prendere mai le critiche sul personale. Tu non sei il tuo codice.

Non dovresti scrivere codice 8 ore al giorno

Nessuno può dirti esattamente quanto tempo al giorno dedica alla scrittura del codice. Ma in realtà sono poche le persone che scrivono codice per più di 4 ore al giorno. Le persone che non sono d’accordo con questo o sono l’eccezione alla regola o lavorano per aziende che trattano male il proprio personale. La programmazione è un lavoro intenso e mentalmente faticoso. È completamente sbagliato pensare che qualcuno scriva codice 8 ore al giorno, 5 giorni alla settimana. Ci saranno rare occasioni in cui dovrai rispettare una scadenza, ma quando dico raramente intendo quasi mai. Non lasciare che il lavoro ti pesi e ti costringa a fare gli straordinari. Non sto suggerendo di lavorare solo quattro ore al giorno. Le restanti quattro ore sono solitamente meglio spese per cose come:

• apprendere nuovi strumenti, funzioni, applicazioni;
• discutere i processi lavorativi con i colleghi;
• aiutare i colleghi che hanno difficoltà sul lavoro;
• pianificazione dei compiti;
• analisi del codice;
• riunioni/riunioni di lavoro.

Consiglio vivamente anche di fare delle pause regolari durante la giornata e di fare esercizio (almeno un po'). Gli effetti positivi dell’esercizio fisico sono stati dimostrati da tempo.

4 modi per incorporare il Design Thinking nel tuo processo di sviluppo

Source Tech Beacon Per creare un prodotto che soddisfi le esigenze dei tuoi clienti, dovrai considerare ciò che desiderano. Se hai scritto un'app con una navigazione confusa o un'interfaccia di caricamento inutilmente lunga, preparati a futuri fallimenti. Come programmatore, potresti dover approfondire la progettazione del prodotto su cui sta lavorando il tuo team. Questo tipo di collaborazione è molto utile perché ognuno nota cose che l'altro potrebbe non notare. Ti offro 4 consigli su come uno sviluppatore e un designer possono lavorare insieme.

1. Partecipa fin dall'inizio

Non dare per scontato che il design venga sempre al primo posto e lo sviluppo al secondo posto. Questo può essere vero, ma non significa che gli sviluppatori non debbano essere coinvolti nel processo di progettazione. Il programmatore è in grado di fornire importanti informazioni tecniche su come realizzare il progetto, mentre i progettisti comprendono meglio i desideri degli utenti. È meglio scoprire il prima possibile quale funzione è tecnicamente impossibile o non soddisfa le esigenze dell'utente. Se progettisti e sviluppatori lavorano insieme, i problemi possono essere scoperti e risolti immediatamente anziché dopo l'approvazione del progetto. Molte aziende adottano un approccio collaborativo allo sviluppo del software. Ciò significa che i membri del team non sono solo responsabili della propria fase o parte di codice, ma si assumono la responsabilità collettiva di tutto, dalla progettazione al test.

2. Impara il processo UX

Coloro che non hanno familiarità con UX (esperienza utente) potrebbero non capire perché i team modificano i progetti più e più volte per dettagli apparentemente minori. Ogni fase del processo UX avviene per un motivo: fornire la migliore esperienza possibile all'utente. Pertanto, è importante prestare attenzione alla creazione di un processo UX fin dall'inizio. Può includere:

• ricercare lo scopo del progetto;
• creazione di un wireframe: un design semplice che consente di determinare le caratteristiche principali del prodotto;
• aggiungere dettagli più fini al design del progetto, come l'interfaccia utente;
• test utente dei progetti. Questa è forse la fase più importante dello sviluppo UX. Ciò fornisce informazioni preziose sul prodotto prima di dedicare tempo allo sviluppo;
• Iterazione: utilizzando l'analisi dei risultati dei test, iterare la progettazione per migliorare l'esperienza dell'utente.

I team ripetono le fasi di progettazione e test più volte finché non rimangono più modifiche o finché il tempo lo consente. Questo di solito significa che avrai più versioni del design.

3. Seguire lo sviluppo del progetto

È molto brutto quando i designer creano un progetto senza consultare gli sviluppatori. È controproducente. È importante che DevOps imposti regole in modo che gli sviluppatori abbiano accesso ai progetti di progettazione in formati facilmente accessibili come PNG o PDF. Una collaborazione efficace tra sviluppatori e progettisti è fondamentale per il successo dell'implementazione di un'applicazione. Evita di consegnare ciecamente un progetto finito a tutti i costi. È meglio correggere un errore all’inizio piuttosto che alla fine.

4. Concordare in quale fase ti verrà mostrato il progetto

Quando agli sviluppatori viene chiesto di creare una versione minima valida di un prodotto (MVP), devono conoscere fin dall'inizio i requisiti per la versione finale. Ciò è necessario per evitare problemi con aspettative ingiustificate. I progettisti devono mostrare allo sviluppatore entrambe le versioni del progetto: sia l'MVP che la versione finale. Ciò aiuterà a implementare l'MVP, tenendo conto di ciò che il cliente si aspetta di vedere nella versione finale. Quando designer e sviluppatori lavorano insieme, ottengono molti vantaggi. Ciascuno di loro possiede conoscenze che possono essere applicate all'esperienza dell'altro. Gli sviluppatori possono fornire informazioni preziose su quali funzionalità non possono essere implementate nel progetto. D'altra parte, la collaborazione con un programmatore solleverà il progettista dalla necessità di rifare il progetto, il che, di conseguenza, farà risparmiare tempo all'intero team.