Accelerați-vă fluxul de lucru atunci când creați teme WordPress

Publicat: 2020-12-17

Viteza este esențială pentru aproape orice proiect. Adesea, termenele limită sunt destul de strânse și un flux de lucru bun într-o echipă este singura modalitate de a le respecta la timp și de a împiedica pe toată lumea să se ardă pe tot parcursul procesului.

Cum ar arăta un astfel de flux de lucru? Și cum puteți implementa câteva bune practici pentru munca dvs. zilnică pentru a vă accelera livrările? Ei bine, există câteva moduri în care putem privi în el. Primul este:

Îmbunătățiri tehnice ale fluxului de lucru

În această parte, vom analiza instrumentele pe care dezvoltatorii le folosesc pentru a-și accelera munca. Cel mai simplu mod de a afla ce ar funcționa cel mai bine este să indicați cele mai lente procese - ceea ce necesită cel mai mult timp. Următorul ar fi - ceea ce necesită cea mai mare energie mentală. Uneori, un proces poate fi foarte rapid, dar de fiecare dată când îl faceți, vă simțiți ca o corvoadă, pe care ați prefera să o împingeți înapoi pentru mai târziu.

Sugestie 1 - Pregătiți o temă de început

O îmbunătățire imensă a fluxului nostru de lucru la DevriX a fost să facem toate lucrurile standard pe care le facem înainte de a începe fiecare proiect, să le găzduim într-un depozit și apoi să le clonăm de fiecare dată când vine o nouă versiune.

Pregătește o temă de început

Cum ajută?

  1. Nu este nevoie să faceți o configurare Gulp de fiecare dată. Toate pachetele sunt scoase din cutie, rulează, configurația a fost testată pe mai multe mașini.
  2. Vine cu o scurtă documentare. Dacă există membri noi ai echipei, aceștia nu trebuie să pună întrebări despre sarcinile de configurare de bază, deoarece cele mai multe dintre acestea sunt deja explicate.
  3. Nu este nevoie să decideți structura fișierelor pentru front-end de fiecare dată. În principal, echipa noastră front-end lucrează la o nouă temă din prima zi, așa că, dacă trebuie să vină de fiecare dată cu o structură de dosare / fișiere pentru fișierele Sass, am pierde ore pe proiect.
  4. Păstrăm totul consecvent - Acesta este un alt impuls uriaș. De obicei, există mai multe proiecte active în același timp, așa că știind unde să găsești ceea ce cauți pentru prima dată când deschizi un proiect este un economisitor de timp. Cu aceeași structură în toate temele, stilurile, fișierele JS, fișierele PHP sunt toate în același loc.

Ori de câte ori găsim o abordare mai bună a unei probleme care poate îmbunătățește configurarea compilării, introduce lintere, cârlige, adaugă câteva acțiuni ici și colo sau funcții de ajutor care sunt adesea utilizate, ne actualizăm tema de pornire. În cazul în care modificările aduse configurării sunt majore, actualizăm și baza de cod a proiectelor existente pentru a o urmări.

Sugestie 2 - Mențineți același stil de codare și abordări

Cu aceasta, toți dezvoltatorii ar înțelege ce au făcut oamenii dinaintea lor. Cu toate acestea, există mai multe - atunci când se aplică aceleași abordări pentru implementarea aspectelor, baza de coduri va fi mai consistentă. Acest lucru este necesar mai ales pentru dezvoltatorii front-end, deoarece poluarea stilurilor este o problemă majoră de regresie.

Puteți vedea, de exemplu, ghidul stilului de codare HTML / CSS de la Google.

Ghidul stilului de codare HTML CSS de la Google

Sursă

Modalități obișnuite de denumire „Intrare” sau „Comentariu” sau modalități de gestionare a „listelor” precum .list-<name> și aprecieri sunt câteva dintre abordările standard pe care le adoptăm atunci când construim machete.

Sugestie 3 - Îmbunătățiți configurarea locală de lucru

O modalitate rapidă de a naviga între proiecte este o economie de timp pe cont propriu. Doar $cd'ing între directoare poate dura cu ușurință o jumătate de oră pe zi. Acesta este tot timpul pierdut. În schimb, puteți configura TMUX pe mașină, puteți configura o fereastră separată pentru fiecare proiect și un panou separat pentru fiecare sarcină / scop, cum ar fi „Running Gulp” - panoul 1; „Executarea comenzilor în temă” - panoul 2; „Executarea comenzilor în pluginuri” - panoul 3.

În plus - asigurați-vă că puteți deschide editorul de cod direct de la terminal. Este o modalitate mai rapidă de a ajunge la codificare decât de a deschide de la o pictogramă, apoi de a naviga la „proiect deschis” și like-uri. Codul VS este foarte ușor de configurat.

Utilizați-vă instrumentele mai bine

  • Codul VS, textul Sublim și multe alte instrumente au o fereastră pop-up „Comandă” în care puteți tasta aproape orice poate face editorul. Salvați toate documentele deschise? Doar câteva butoane. Le închizi? Tot la fel.
  • Navigați prin paleta de comenzi - navigarea pentru fișiere în bara laterală necesită prea mult timp. Doar mergeți mai departe și scrieți numele fișierului de care aveți nevoie. Adăugați câteva extensii pentru a accelera operațiunile obișnuite, cum ar fi redenumirea, mutarea, duplicarea și ștergerea fișierelor.
  • Configurați lintere. Pierderea timpului în formatarea fișierelor este inutilă atunci când există instrumente care pot face asta pentru dvs. De fiecare dată când introduceți codul, adăugați spațiu între paranteze și așa mai departe ar putea fi mai bine cheltuit pentru rezolvarea problemelor.
  • Utilizați comenzi rapide și fragmente - pentru dezvoltatorii front-end Emmet este un salvator. nav>.site-nav>ul.list-items>li.list-item*5>a{title} simple, cum ar fi: nav>.site-nav>ul.list-items>li.list-item*5>a{title} extindeți la peste 15 linii de cod HTMl, toate formatate și gata de stil. Tastarea acelei linii durează câteva secunde.
Exemplu de cod VSC

Exemplu de paletă de comandă VSCode. Puteți citi mult mai multe în pagina lor de prezentare generală.

Luarea deciziilor pentru îmbunătățirea fluxului de lucru

Acesta poate fi puțin mai complicat și ar putea necesita mai multă experiență și înțelegere a nevoilor de afaceri ale clientului. Este, de asemenea, una dintre abordările cu o responsabilitate mai mare, dar uneori este ceea ce poate salva un proiect de lipsa unui termen limită.

Începeți de la cel mai important și cel mai rapid de implementat. Dacă există o mică șansă ca o pagină să nu se lanseze în ziua 1, atunci nu este nevoie să începeți cu ea. Dacă după estimările dvs. este posibil ca ceva să nu fie pregătit - asigurați-vă că discutați acest lucru cu clientul dvs. Cu cât declarați mai clar ce ați făcut, ce ar putea fi întârziat și unde ar putea apărea probleme, cu atât este mai probabil să depășiți o problemă potențială.

Delegați munca devreme, dar mențineți numărul total de persoane implicate scăzut. Acest lucru este observat de toată lumea într-un anumit stadiu. Poate cel mai devreme este la școală, când 10 copii ajung să lucreze la un proiect, dar doar doi sau trei fac cea mai mare parte a muncii.

Acest lucru este vizibil în special în proiectele care încep cu mai multe lucrări front-end. Rareori din prima zi puteți avea mai mulți dezvoltatori care lucrează, deoarece unul dintre primele lucruri care trebuie stabilite este arhitectura proiectului. Deciziile fundamentale ale echipei de proiectare ar trebui să fie construirea. Care sunt componentele, cum se extind, separarea fișierelor, structura și regulile interogării media, convențiile de denumire. Toate acestea.

îndeplinirea sarcinilor

Și când există mai mulți dezvoltatori într-o etapă atât de fundamentală, amândoi ar putea începe să implementeze o parte fundamentală a codului de care au nevoie pentru ca aceștia să poată stiliza restul site-ului. Când apasă codul respectiv, vor apărea conflicte și unul dintre dezvoltatori ar putea avea nevoie să refacă cea mai mare parte a muncii.

Un moment bun pentru a adăuga mai mulți dezvoltatori front-end ar fi atunci când se face mai multă muncă fundamentală și se poate delega componente separate, cum ar fi „Carduri de conținut” sau „Pagina de destinație X” sau „Pagina 404” și altele asemenea. Până atunci, fonturile sunt aplicate, setările generale de tipografie sunt setate, majoritatea fișierelor sunt create și există cel puțin 1-2 pagini create.

Și apoi, este ideal dacă numărul total de persoane concentrate pe un singur proiect este menținut la minimum. În ceea ce privește gestionarea timpului și concentrarea asupra sarcinii, un sfat pe care dezvoltatorii care lucrează într-o echipă ar putea dori să-l ia în considerare este de a schimba volumul de lucru pentru un anumit proiect.

Să presupunem că avem dezvoltatorul front-end John, care lucrează la un nou site de două săptămâni cu normă întreagă. În acel moment, el se uită la el de mai bine de 80 de ore pe zi. Foarte probabil, el a încetat să identifice probleme pe site! Acum ar fi un moment bun pentru ca prietena lui Kate să intervină și să preia cea mai mare parte a lucrării sale. Kate poate începe să remedieze problemele minore, verificând dublu dacă urmează proiectarea, îmbunătățind performanța ici și colo, terminând câteva pagini și componente pe care John le-a amânat pur și simplu pentru că nu are energia mentală să o facă.

Este foarte posibil ca majoritatea dezvoltatorilor să fi experimentat acest lucru și se simte atât de bine să ai un coechipier care poate să intervină și să preia lucrurile pentru încă o săptămână sau două, în timp ce îți curățești puțin mintea cu un proiect nou sau cu lucrări de întreținere pe site-uri web mai vechi .

În concluzie:

Există mai mult de câteva modalități tehnice evidente de a îmbunătăți viteza de dezvoltare a unui site. Este un amestec între munca în echipă - modul în care definiți orientări comune în echipa dvs. și modul în care vă configurați mediul de lucru / automatizați munca în timp ce utilizați toate instrumentele la dispoziția dvs. Cum vă mențineți mintea proaspătă și ascuțită pentru perioade mai lungi de timp, pentru a menține rata de productivitate ridicată pe care ați avut-o în prima zi.

Pentru a gestiona toate acestea, o echipă puternică are nevoie de dezvoltatori superiori buni pentru a stabili arhitectura, membri responsabili ai dezvoltatorilor care urmează orientările și produc lucrări de calitate și manageri de proiect buni pentru a căuta starea mentală a tuturor.