Come vado per il mio lavoro

Durante la creazione di siti Web o componenti di un sito Web è presente un processo. Vorrei rendere questo processo un passaggio più consapevole e coerente del mio lavoro e così scriverò cosa succede nella mia mente quando creo i componenti che compongono questi siti Web. Vorrei anche condividere queste idee poiché credo che possano essere utili solo per i lettori.

Credo che questo processo possa essere sintetizzato con un’idea piuttosto semplice. Il lavoro di un sito Web è facilitare il lavoro di un’azienda.

Ho suddiviso questa idea in 3 categorie:
Il business : per cui il sito Web / componente è costruito.
Gli editor : coloro che riempiranno il sito Web utilizzando questi componenti.
Gli sviluppatori : sviluppatori presenti e futuri che lavoreranno anche sul progetto.

Il business

Questi sono gli obiettivi del sito Web, il suo pubblico e il modo in cui interagiranno con detto sito Web.

Al giorno d’oggi, con oltre il 50% del pubblico di un sito Web su mobile, essere reattivi è un dato di fatto. Non abbiamo nemmeno bisogno di pensarci. Ma penso che valga la pena ricordare perché costruiamo siti Web reattivi. Lo facciamo perché migliora l’esperienza dell’utente sui dispositivi mobili. Inoltre, una migliore esperienza utente migliora il successo del sito Web in base alle metriche su cui il business valuta il successo. Ci sono altri aspetti di un sito Web che migliorano l’esperienza dell’utente che mi piace tenere a mente mentre lavoro.

La prima cosa che un utente sperimenta quando accede a un sito Web è il tempo impiegato per caricarsi. Questa è anche la prima cosa di cui mi preoccupo all’inizio di un progetto. La bassa velocità di carico ha un grande impatto sulla frequenza di rimbalzo e sulla frustrazione generale. Ciò è particolarmente vero e importante se si considera la velocità del carico mobile in cui la velocità di download e la CPU è molto più lenta e il consumo di dati è anche una preoccupazione. C’è una pletora di risorse online che puoi dare un’occhiata per ottenere le specifiche, ma questo è un buon punto di partenza: perché le prestazioni sono importanti

Anche l’accessibilità è importante e non solo per i disabili. Pensa a quanto è difficile leggere il testo sul tuo telefono in una giornata di sole. Anche gli utenti esperti (io sono uno di loro) si divertono a usare la tastiera per la navigazione. E, naturalmente, le persone disabili potrebbero voler utilizzare il tuo sito Web. Pertanto, è importante per me garantire che tutte le aree del sito Web siano accessibili tramite la navigazione da tastiera in modo prevedibile e che il rapporto di contrasto sia sufficientemente elevato per i contenuti leggibili. Ancora una volta, la navigazione da tastiera, skip-nav, contrasto di colore e testo dello screen reader sono buoni punti di partenza.

E poi ci sono domande generiche sull’utente che mi pongo spesso; L’intero componente dovrebbe essere cliccabile o solo il CTA? Dovrei ajax nei dati o attivare una navigazione? Devo archiviare i dati nella memoria locale? E molti altri. Tutto sommato, mi piace solo passare un po ‘di tempo a riflettere su come voglio che i componenti si comportino e vengano usati prima di toccare la mia tastiera.

I redattori

È facile implementare le diverse parti del sito Web (principalmente per i siti Web di contenuti).

Questo non è il luogo in cui ho il maggior impatto come front-end, ma vale comunque la pena ricordare come gli editor interagiranno con il sito (all’interno del CMS). La mia linea guida qui è; quanto lavoro posso rimuovere dalle loro mani?

C’è un modo per automatizzare l’immissione dei dati tramite le API? In tal caso, suggerirei sempre di procedere in questo modo, soprattutto se si tratta di un’attività ridondante. Se alcune configurazioni non cambiano mai, potrebbe valere la pena nasconderle.

Gli sviluppatori

Ciò determinerà quanto sia facile apportare modifiche continue.

I progetti dei clienti non sono mai veramente finiti, vero? Le specifiche del modulo cambieranno, ne verranno costruite di nuove. Scrivere un codice chiaro e comprensibile è molto importante per me. La manutenibilità garantisce che in futuro tu o gli sviluppatori veniate dopo che sarete in grado di svolgere rapidamente il lavoro.

Spesso mi siedo lì, guardando il mio schermo, chiedendomi se c’è un modo migliore per scrivere quel pezzo di codice. Di solito richiede semplicemente di estrarre il bit di funzionalità e inserirlo all’interno di una funzione. Compiti più complessi possono richiedere cose come un pub-sub. Confronta questi due esempi:

  // Preferito 
const increment = x => x + 1;
const temp = [1, 2, 3, 4, 5] .map (incremento);
  // Non preferito 
const temp = [1, 2, 3, 4, 5];
  for (let i = 0; i <temp.length; i ++) { 
temp [i] + = 1;
}

O questi due:

  // Preferito 
const increment = x => x + 1;
const temp = [1, 2, 3, 4, 5] .map (incremento);
  // Non preferito 
const temp = [1, 2, 3, 4, 5] .map (x => x + 1);

Spero che possiamo essere tutti d’accordo sul fatto che in entrambi i casi la soluzione è più leggibile e la più mantenibile. La soluzione 1 ha anche l’ulteriore vantaggio di creare una funzione di increment riutilizzabile.

Le documentazioni sono anche di grande aiuto quando si tratta di apportare modifiche che non spezzeranno il comportamento attuale del modulo. Annotare le specifiche di quel modulo assicura che gli sviluppatori che vengono dopo di noi sappiano come comportarsi quel modulo.

Javascript the Good Parts e Javascript Design Patterns sono i miei consigli personali.

Conclusione

La programmazione è un mezzo per raggiungere un fine. Questo è qualcosa che mi è chiaro e quindi, quando scrivo il mio codice, la mia preoccupazione principale sono quelle sopra menzionate. Questo mi ha portato a cercare sempre un modo migliore per fare le cose e, a sua volta, è diventato un framework per l’apprendimento e l’espansione delle mie capacità di sviluppatore front-end.

Grazie per aver letto.