Accelera il tuo flusso di lavoro durante la creazione di temi WordPress

La velocità è fondamentale per praticamente qualsiasi progetto. Spesso, le scadenze sono piuttosto strette e un buon flusso di lavoro in un team è l'unico modo per rispettarlo in tempo e impedire a tutti di esaurirsi durante il processo.

Come sarebbe un simile flusso di lavoro? E come puoi implementare alcune best practice per il tuo lavoro quotidiano per accelerare le consegne? Bene, ci sono alcuni modi in cui possiamo esaminarlo. Il primo è:

Miglioramenti al flusso di lavoro tecnico

In questa parte, esamineremo gli strumenti utilizzati dagli sviluppatori per velocizzare il loro lavoro. Il modo più semplice per capire cosa funzionerebbe meglio è indicare i processi più lenti, ciò che richiede più tempo. Il prossimo sarebbe: ciò che richiede più energia mentale per fare. A volte un processo può essere molto veloce, ma ogni volta che lo fai, sembra un lavoro ingrato, che preferiresti respingere per dopo.

Suggerimento 1 - Prepara un tema iniziale

Un enorme miglioramento del nostro flusso di lavoro in DevriX è stato quello di fare tutte le cose standard che facciamo prima di iniziare ogni progetto, ospitarli in un repository e poi clonarlo ogni volta che arriva una nuova build.

Come aiuta?

1. Non è necessario eseguire ogni volta una configurazione Gulp. Tutti i pacchetti sono pronti all'uso, vengono eseguiti, la configurazione è stata testata su più di una macchina.
2. Viene fornito con una breve documentazione. Se ci sono nuovi membri del team, non devono fare domande sulle attività di configurazione di base poiché la maggior parte di ciò è già stata spiegata.
3. Non è necessario decidere ogni volta la struttura dei file per il front-end. Per lo più il nostro team di front-end lavora su un nuovo tema dal primo giorno, quindi se devono inventare una struttura di cartelle / file per i file Sass ogni volta, sprecheremmo ore per progetto.
4. Manteniamo tutto coerente: questa è un'altra enorme spinta. Di solito c'è più di un progetto attivo allo stesso tempo, quindi sapere dove trovare quello che stai cercando per la prima volta quando apri un progetto è un enorme risparmio di tempo. Con la stessa struttura su tutti i temi, stili, file JS e file PHP si trovano tutti nello stesso posto.

Ogni volta che troviamo un approccio migliore a un problema che forse migliora la configurazione della build, introduce linter, hook, aggiunge alcune azioni qua e là o funzioni di supporto che vengono spesso utilizzate, aggiorniamo il nostro tema di partenza. Se le modifiche alla configurazione della build sono importanti, aggiorniamo anche la base di codice dei progetti esistenti per seguirla.

Suggerimento 2: mantenere lo stesso stile di codifica e gli stessi approcci

Con questo, tutti gli sviluppatori avrebbero capito cosa hanno fatto le persone prima di loro. Tuttavia, c'è di più: quando vengono applicati gli stessi approcci all'implementazione dei layout, la base di codice sarà più coerente. Ciò è particolarmente necessario per gli sviluppatori front-end poiché inquinare gli stili è un importante problema di regressione.

Puoi vedere ad esempio la guida allo stile di codifica HTML / CSS di Google.

fonte

.list-<name> comuni per denominare "Voce" o "Commento" o modi per gestire "elenchi" come .list-<name> e simili sono alcuni degli approcci standard che .list-<name> durante la creazione dei layout.

Suggerimento 3 - Migliora la tua configurazione di lavoro locale

Un modo rapido per navigare tra i progetti è un grande risparmio di tempo da solo. Solo $cd'ing tra le directory può richiedere facilmente mezz'ora al giorno. È tutto tempo perso. Invece, puoi configurare TMUX sulla tua macchina, impostare una finestra separata per ogni progetto e un pannello separato per ogni attività / scopo come "Running Gulp" - pannello 1; "Esecuzione dei comandi nel tema" - pannello 2; "Esecuzione di comandi nei plugin" - pannello 3.

Inoltre, assicurati di poter aprire il tuo editor di codice direttamente dal terminale. È un modo più veloce per accedere alla codifica rispetto all'apertura da un'icona, quindi alla navigazione in "progetto aperto" e simili. VS Code è davvero facile da configurare.

Utilizza meglio i tuoi strumenti

• Il codice VS, il testo Sublime e molti altri strumenti hanno un popup "Comando" in cui puoi digitare quasi tutto ciò che l'editor può fare. Salvare tutti i documenti aperti? Solo pochi pulsanti. Chiuderli? Lo stesso.
• Naviga attraverso la palette dei comandi: anche la ricerca dei file nella barra laterale richiede troppo tempo. Vai avanti e scrivi il nome del file che ti serve. Aggiungi alcune estensioni per velocizzare le operazioni comuni come rinominare, spostare, duplicare ed eliminare i file.
• Imposta linters. Perdere tempo nella formattazione dei file è inutile quando ci sono strumenti che possono farlo per te. Ogni volta che indentate il codice, aggiungete spazio tra parentesi e così via potrebbe essere impiegato meglio per risolvere i problemi.
• Utilizza scorciatoie e frammenti: per gli sviluppatori front-end Emmet è un vero toccasana. Semplici nav>.site-nav>ul.list-items>li.list-item*5>a{title} come: nav>.site-nav>ul.list-items>li.list-item*5>a{title} espandono a oltre 15 righe di codice HTMl, tutte formattate e pronte per lo stile. La digitazione di quella riga richiede pochi secondi.

Esempio di tavolozza dei comandi VSCode. Puoi leggere molto di più nella loro pagina di panoramica.

Processo decisionale per migliorare il flusso di lavoro

Questo può essere un po 'più complicato e potrebbe richiedere un po' più di esperienza e comprensione delle esigenze aziendali del cliente. È anche uno degli approcci più gravosi di responsabilità, ma a volte è ciò che può salvare un progetto dal mancato rispetto di una scadenza.

Inizia dal più importante e dal più veloce da implementare. Se esiste una piccola possibilità che una pagina non venga avviata il primo giorno, non è necessario iniziare con essa. Se secondo le tue stime è possibile che qualcosa non sia pronto, assicurati di discuterne con il tuo cliente. Più chiaramente dichiari cosa hai fatto, cosa potrebbe essere ritardato e dove potrebbero verificarsi problemi, più è probabile che tu possa superare un potenziale problema.

Delegare il lavoro nella fase iniziale, ma mantenere basso il numero totale di persone coinvolte. Questo è qualcosa che tutti notano in una certa fase. Forse il primo è a scuola, quando 10 bambini iniziano a lavorare a un progetto, ma solo due o tre fanno la maggior parte del lavoro.

Ciò è particolarmente visibile nei progetti che iniziano con più lavoro di front-end. Raramente dal primo giorno puoi avere più di uno sviluppatore che lavora perché una delle prime cose che devono essere stabilite è l'architettura del progetto. Le decisioni fondamentali del team di progettazione dovrebbero essere la costruzione. Quali sono i componenti, come si estendono, la separazione dei file, la struttura e le regole delle media query, le convenzioni di denominazione. Tutto questo.

E quando c'è più di uno sviluppatore in una fase così fondamentale, entrambi potrebbero iniziare a implementare una parte fondamentale del codice di cui hanno bisogno per modellare il resto del sito. Quando spingono quel codice, emergeranno conflitti e uno degli sviluppatori potrebbe dover ripetere la maggior parte del lavoro.

Un buon momento per aggiungere più sviluppatori front-end sarebbe quando viene svolto più del lavoro fondamentale e il lavoro può essere delegato a componenti separati come "Schede dei contenuti" o "Pagina di destinazione X" o "Pagina 404" e simili. A quel punto, vengono applicati i caratteri, vengono impostate le impostazioni tipografiche generali, viene creata la maggior parte dei file e vengono create almeno 1-2 pagine.

E poi, è l'ideale se il numero totale di persone concentrate su un singolo progetto è mantenuto al minimo. In termini di gestione del tempo e concentrazione sull'attività, un suggerimento che gli sviluppatori che lavorano in un team potrebbero voler prendere in considerazione è cambiare il carico di lavoro su un determinato progetto.

Supponiamo di avere lo sviluppatore front-end John che ha lavorato a un nuovo sito per due settimane a tempo pieno. A quel punto, lo osserva da più di 80 ore al giorno. Molto probabilmente ha smesso di individuare i problemi sul sito! Ora sarebbe un buon momento per la sua amica Kate di intervenire e assumere la maggior parte del suo lavoro. Kate può iniziare a risolvere piccoli problemi, ricontrollando che segua il design, migliorando le prestazioni qua e là, finendo le poche pagine e componenti che John ha rimandato semplicemente perché non ha l'energia mentale per farlo.

È del tutto possibile che la maggior parte degli sviluppatori lo abbia sperimentato ed è così bello avere un compagno di squadra che può intervenire e affrontare le cose per un'altra settimana o due mentre ti schiarisci un po 'la mente con un nuovo progetto fresco o alcuni lavori di manutenzione su vecchi siti web .

In sintesi:

Ci sono più di pochi ovvi modi tecnici per migliorare la velocità di sviluppo di un sito. È un mix tra il lavoro di squadra: il modo in cui definisci le linee guida comuni nel tuo team e come imposti il ​​tuo ambiente di lavoro / automatizzi il tuo lavoro utilizzando tutti gli strumenti a tua disposizione. Come mantenere la mente fresca e acuta per periodi di tempo più lunghi al fine di mantenere l'alto tasso di produttività che avevate il primo giorno.

Per gestire tutto questo, un team forte ha bisogno di buoni sviluppatori senior che definiscano l'architettura, membri di sviluppo responsabili per seguire le linee guida e produrre lavoro di qualità e buoni project manager per cercare lo stato mentale di tutti.