Dezvoltatori WordPress: Începeți aici!

Publicat: 2017-10-14

Bun venit la ghidul nostru de pornire pentru dezvoltatorii WordPress! Indiferent dacă lucrați ca freelancer sau ca parte a unei agenții media. În acest articol, vom acoperi o varietate de subiecte legate de dezvoltarea WordPress, împreună cu unele dintre resursele și instrumentele disponibile.
Textul este organizat în jurul diferitelor etape care curg între generarea ideii și expediere. Vom vorbi despre brainstorming, prototipare, dezvoltare și, în final, despre implementare. Toate acestea, în contextul dezvoltării produsului. Credem că între primele bănuieli ale unei idei și execuția ei finală există multe zone subtile. Unele sunt lăsate nediscutate în cel mai bun caz, iar altele sunt complet neexplorate în cel mai rău caz, în literatura WordPress actuală.

Dacă sunteți client Pressidium, puteți începe imediat să utilizați instrumentele pe care le-am construit în jurul platformei noastre, astfel încât să vă puteți bucura de beneficiile unui nivel ridicat de integrare. Vom vorbi despre ce aceste instrumente, de asemenea. Vă rugăm să rețineți că acesta este un document live și ar trebui tratat ca atare.

În primul rând, scopul nostru este ca acest document să fie util pentru practica dvs. ca dezvoltator WordPress și, în al doilea rând, să vă arătăm câteva lucruri interesante pe care le-am creat doar pentru dvs.

De la idee la implementare

Indiferent dacă lucrați la un produs nou sau ați preluat ceva client, procesul de trecere de la idee la implementare constă în 4 etape. Deși aceste etape sunt discrete, ele se suprapun semnificativ și nu sunt liniare. Vom discuta acest lucru mai departe în text:

Brainstorming și elicitarea cerințelor.
Prototiparea.
Dezvoltare.
Implementare.

Procesul de brainstorming liber-asociativ este folosit atunci când doriți să începeți să construiți un produs sau un proiect și aveți nevoie de idei. Culegerea cerințelor, totuși, are loc atunci când sunteți însărcinat să construiți un proiect pentru un client sau să ajungeți la o idee după o sesiune de brainstorming. Puteți încă configura sesiuni de brainstorming ulterior pentru a rezolva anumite probleme, dar acele sesiuni vor fi mai restrânse.

Principiile fundamentale ale brainstormingului sunt două. Alegeți cantitatea și amânați judecata pentru mai târziu. Am scris în trecut despre cum puteți facilita o astfel de sesiune, despre cum să vă construiți mentalitatea adecvată și despre câteva instrumente funky care să vă ajute.

Evocarea cerințelor

Există mai multe metodologii care sunt folosite pentru a obține cerințe și, în mod tradițional, aceasta a fost întotdeauna munca unui analist de afaceri. Deși este responsabilitatea clientului să furnizeze informații despre cerințele proiectului, trebuie stabilită o înțelegere comună pentru toate părțile interesate. Elicitarea cerințelor este un proces diferit de colectarea cerințelor. Este mai mult despre scoaterea la iveală a informațiilor necesare prin participare activă. Și mai puțin este vorba de a aduna pasiv într-un document ceea ce vă spune clientul și de a le transmite echipei de dezvoltare.

În funcție de domeniul și natura proiectului, cazurile de utilizare sunt o modalitate excelentă de a capta funcționalitatea. Cazurile de utilizare sunt o tehnică care este utilizată în diagramele UML ca o modalitate de a descrie interacțiunile dintre părțile interesate ale unui sistem și sistemul însuși. Deoarece sunt o colecție de scenarii scrise în limba engleză simplă, dar structurată, nu numai că sunt mai puțin complicate, dar sunt o modalitate rapidă și eficientă de a începe să discutați și să schițați funcționalitatea sistemului.

Probabil că va trebui să stabiliți interviuri structurate cu toate părțile interesate dacă doriți să capturați cerințele pentru produse complexe. Pentru aceasta, User Stories este o modalitate perfectă de a merge. Ele fac parte din mentalitatea Agile și reprezintă o modalitate informală de a începe să vorbim despre cerințe, pentru a construi o înțelegere comună. Scurte descrieri ale funcționalităților sunt scrise pe cartonașe de hârtie, de obicei note post-it, și sunt amestecate într-o tablă albă pentru a crea narațiuni ale călătoriilor utilizatorului. Poveștile utilizatorilor sunt generate pe loc, prin participarea, discutarea și manipularea cardurilor pe tablă. Detaliile sunt completate încet și în cele din urmă adăugate ca caracteristici în stocul de produse. Jeff Patton a scris o carte excelentă despre User Story Mapping pe care o recomandăm cu căldură dacă doriți să aflați mai multe despre subiect și să începeți să o utilizați în proiectele dvs.

Poveștile utilizatorilor nu sunt un lucru static care odată creat este uitat pentru totdeauna. În schimb, sunt o hartă dinamică, la care echipa de dezvoltare și produs se poate întoarce din nou și din nou, pe măsură ce urmează etapa de prototipare, iar produsul începe să prindă contur.

Importanța unui prototip este de a răspunde la întrebări. Deși există mai multe metodologii de prototipare, considerăm că cea evolutivă este cea mai potrivită pentru scopurile noastre și cea care poate fi adaptată în pipelinele moderne de dezvoltare de software Agile. În metodologia prototipului evolutiv, procesul este ciclic, în care prototipul devine progresiv mai rafinat pe parcursul fiecărui ciclu.

Fiecare iterație a prototipului trece de la faza de proiectare la faza de dezvoltare și evaluare. Ea scoate la iveală probleme timpurii de design și oferă ceva tangibil spre care oamenii pot indica și vorbesc despre ceea ce poate fi îmbunătățit. Perspectiva adunată din faza de evaluare este folosită în următoarea iterație a prototipului și ciclul se repetă din nou. Astfel, prototipul evoluează încet la sistemul final până ajunge la maturitate ca produs finit.

Prototiparea are loc de obicei în ritmuri rapide de dezvoltare, iar utilizarea sistemelor standard precum Bedrock, Sage și Bootstrap poate reduce foarte mult timpii de dezvoltare. Sisteme precum cele menționate mai sus oferă un schelet complet al aplicației și lanțul de instrumente necesar, astfel încât să nu va trebui să începeți de la zero de fiecare dată. Prototipurile evolutive nu sunt același lucru cu prototipurile de aruncat. Acestea din urmă sunt prototipuri care sunt construite o singură dată ca dovadă de concept și apoi aruncate. Dacă petreceți o perioadă semnificativă de timp construind un prototip de comerț electronic, de ce să nu abstrageți funcționalitățile comune și să le folosiți din nou în viitor, în loc să aruncați totul și să începeți de la zero?

Aici este utilă clonarea Pressidium. Vă permite să clonați rapid un site web cu un singur clic și să începeți dezvoltarea. În acest fel, puteți pregăti mai multe site-uri web șabloane folosind boilerplate, le puteți preîncărca cu pluginurile, temele și configurația necesare și le puteți clona de fiecare dată când aveți nevoie de ele într-un proiect. De asemenea, le puteți clona într-un alt cont Pressidium, de exemplu, în cel al clientului dvs., în același mod. Nu vă faceți griji dacă prototipurile dvs. se află pe un alt furnizor de găzduire WordPress gestionat. Doar folosiți instrumentul nostru asistent de migrare și importați-le în contul dvs. Pressidium!

Indiferent dacă dezvoltați proiecte WordPress pe cont propriu sau colaborați cu alți dezvoltatori și designeri WordPress, cele mai importante două puncte care contribuie la sustenabilitatea meșteșugului dumneavoastră pe termen lung sunt următoarele:

Practicarea bunelor obiceiuri software.
Și știind ce este totul, unde este și de ce este acolo.

Cele mai bune practici variază de la urmarirea consecventă a unui ghid de stil software până la exersarea scrisului de cod curat în loc de inteligent și până la alegeri de nivel înalt pentru software și UI. Al doilea punct este pur și simplu documentația și multele forme pe care le poate lua în interiorul unui proiect.

Urmând un ghid de stil software, este simplu. Studiați resursele oficiale WordPress.org pe această temă și apoi decideți ce linii directoare au sens pentru dvs., astfel încât să le includeți în stilul dvs. de codare. Schimbarea obiceiurilor este un proces lent și ar trebui să începeți prin a face mici schimbări la început. În cele din urmă, a avea un set de linii directoare pe care trebuie să le respecte codul tău înseamnă să introduci recenzii de cod la un moment dat.

Evaluările codului reprezintă o modalitate sistematică de citire și examinare a codului care urmărește să elimine greșelile, să elucideze părți ale codului care sunt abstruse și să asigure că codul respectă standardele și convențiile. De asemenea, cel mai bine este să fie făcut de altcineva din echipa ta și nu de tine.

A prefera codul curat spre inteligent este o „perlă a înțelepciunii” de dezvoltare de software care, din păcate, poate fi apreciată doar după ce a căzut în capcanele codului inteligent. Concluzia este aceasta: deși, în unele cazuri, codul inteligent vă poate câștiga puncte de „hacker” și o palmă pe spate, și chiar și un câștig de performanță în unele cazuri, în cele din urmă veți pierde pe termen lung. Codul care este „hackish” și greu de citit va deveni de neînțeles în viitor. Și s-ar putea să te coste atunci când trebuie să depanezi o eroare deosebit de evazivă. Găsirea echilibrului între scrierea de cod optimizat și curat este ceva pe care va trebui să-l descoperi singur, dar este întotdeauna mai bine să greșești pe partea curată a lucrurilor.

De asemenea, deoarece performanța site-urilor WordPress depinde în mare măsură de utilizarea corectă a memoriei cache a browserului, este important să știți cum utilizează furnizorul dvs. de găzduire WordPress gestionat. Codul tău va funcționa apoi sinergic cu platforma ta de găzduire, pentru a avea cea mai bună performanță posibilă. Cu toate acestea, țineți cont de faptul că măsurarea vitezei site-ului dvs. într-un mod corect nu este atât de ușoară pe cât s-ar putea crede și conține mai multe probleme!

Deci, vorbind despre cele mai bune practici de nivel înalt, decizia care a condus la WordPress să-și decupleze funcționalitatea de bază și să furnizeze un API REST ar putea fi cu siguranță considerată un exemplu de astfel de practici. Această decizie a semnalat trecerea către o nouă eră, către sistemele programatice de gestionare a conținutului și dezvoltarea de aplicații WordPress „fără cap”.

Am scris o introducere succintă și un tutorial pentru API-ul REST WordPress și o modalitate simplă de a începe să-l manipulăm folosind pluginuri de browser, cum ar fi Postman.

Această decizie de proiectare a software-ului a fost înșelător de simplă, dar puternică. Un dezvoltator WordPress poate folosi acum WordPress pentru a implementa aplicații și funcționalități care le depășesc cu mult pe cele ale site-urilor web sau blogurilor. Un exemplu deosebit de potrivit este prototipul nostru Kanban.

Am folosit entități WordPress, cum ar fi categorii și postări, pentru a modela un panou Kanban cu sarcini, coloane și un flux de valoare. Am schițat un API Kanban Columns and Cards, care a legat totul.

Documentație

S-ar putea susține că cele mai bune practici de software sunt favorabile pentru scrierea unei documentații mai bune, de la simple comentarii la cod, la livrabile ale proiectului și culminând la copierea produsului.

Indiferent de cum o priviți, documentația este un atu.

Când vine vorba de documentația tehnică, limbajul folosit în scris este categoric diferit de cel pe care îl folosiți când comunicați zilnic sau de cel pe care îl folosiți la serviciu. Această formă de scriere se numește scriere tehnică și nu este utilizată numai în calculatoare sau inginerie software. De fapt, este folosit în toate profesiile care trebuie să comunice concepte tehnice unui public de specialitate, cum ar fi dreptul, medicina, aeronautica și așa mai departe. Este un subiect mare și există chiar și unele colegii care oferă certificări tehnice de scriere. Rațiunea sa de a fi este de a comunica informații tehnice folosind un limbaj clar și concis. Vocea activă este preferată pasivă, aceasta din urmă fiind folosită în cazurile în care este necesar un text descriptiv pentru a explica concepte.

Un scriitor tehnic trebuie să aibă în vedere faptul că cititorul este cineva care este adesea frustrat în timpul căutării unei anumite informații. Drept urmare, scrisul tău trebuie să nu stea în cale. Scopul său este de a face acest proces ușor, simplu și chiar plăcut!

Deși nu trebuie să ai o diplomă sau să fii un scriitor tehnic profesionist, să știi cum să comunici concepte într-o manieră concisă și simplă este foarte important pentru cariera ta de dezvoltator WordPress. Astfel, ori de câte ori trebuie să scrieți documentație pentru un plugin, o temă sau un API pe care l-ați construit (și de care sunteți mândri!), trebuie să aveți elementele de bază jos. Din acest motiv, am scris un ghid rapid pentru a vă documenta pluginurile și temele WordPress, care acoperă și cele 5 principii de bază ale scrierii tehnice.

Dar documentarea nu se oprește aici. În cazurile în care tema sau pluginul dvs. fac parte dintr-un proiect mai mare sau când acestea sunt suficient de complexe în sine, ar trebui să începeți să vă gândiți în termeni de documentație a produsului. Adăugând la adevărul că documentația este un atu, documentația de produs, la rândul ei, este un atu de marketing. Acest lucru este încapsulat în mod adecvat în următorul citat al lui Mike PuterBaugh, VP de marketing la MindTouch, într-un articol Mashable despre importanța documentației produsului:

Nu este o întreprindere sexy, dar îți va câștiga respectul colegilor tăi, un management mai eficient al companiei și o echipă mai colaborativă. Pentru că nu este vorba despre acest trimestru sau anul acesta, ci mai degrabă, este vorba despre afectarea avantajului competitiv și a creșterii pe termen lung.

Când vine vorba de produs, pe lângă cele mai uzuale forme de documentare scrisă, există mai multe, cum ar fi ajutor online, ghiduri de stil, microconținut și așa mai departe. Documentația produsului este de obicei scrisă în colaborare de multe persoane diferite, ceea ce adaugă un nivel suplimentar de complexitate. Am scris un ghid amplu care vă ajută să începeți să gândiți și să planificați și în acest fel.

În cele din urmă, pe măsură ce ne îndreptăm către ultima etapă a procesului, care este implementarea, plasăm ultima piesă a puzzle-ului de documentație: Diagramele de implementare. Acestea vă ajută să aveți o idee clară și sferică despre ceea ce este totul și unde ar trebui să fie.

Deși majoritatea oamenilor ar fugi țipând de groază când au auzit despre UML (și destul de înțeles, specificația completă a UML este abisală), în apărarea sa, UML conține un subset de instrumente de notație care pot adăuga valoare unui proiect. Diagramele de implementare sunt o notație surprinzător de simplă, constând doar din noduri și căi de comunicare care vă pot arăta dintr-o singură privire diferitele medii care există în proiectul dvs. și unde trebuie implementată fiecare componentă.

Vom aprofunda mai mult în UML în viitor, în special la o altă notație utilă numită Diagrame de secvență, precum și în exemple mai detaliate de diagrame de scenarii de caz de utilizare pentru a completa cerințele proiectului și a construi prototipuri.

Majoritatea, dacă nu toate, dezvoltarea și implementarea modernă utilizează o formă de control al versiunilor, cum ar fi git și SVN. Arhivele de cod sursă nu sunt esențiale doar pentru echipe, deoarece beneficiile lor sunt extinse chiar dacă sunteți un dezvoltator WordPress singur.

Dacă sunteți client Pressidium, vă puteți integra depozitul cu contul dvs. prin SFTP, folosind un serviciu extern, cum ar fi deploybot. Alternativ, puteți utiliza SFTP pentru a vă transfera fișierele în contul dvs., deoarece aceasta este cea mai ușoară și mai simplă metodă. De asemenea, puteți crea mai mulți utilizatori SFTP și îi puteți atribui unor site-uri web și medii specifice. Apropo de asta, având un mediu de pregătire pentru site-ul dvs. web, vă asigurăm că procesul dvs. de dezvoltare și implementare este mai eficient, iar site-ul dvs. de producție este protejat de modificări nedorite. De exemplu, după ce ați activat staging-ul pentru site-ul dvs. web, puteți extrage o copie din producție și apoi creați un cont SFTP pentru dezvoltatorul dvs., care are acces numai în mediul de staging.

Configurarea unei conducte de dezvoltare raționalizate care trece prin mai multe medii este una dintre schimbările pe care mișcarea DevOps le-a adus mediilor IT. Adoptarea unei discipline de livrare continuă și schimbarea software-ului care este împinsă progresiv și frecvent, are ca rezultat cicluri de implementare mai rapide și mai puține erori. Nu mai trebuie să mențineți arhive ZIP cu versiuni diferite ale aplicației dvs. În acest fel, puteți pierde cu ușurință urma și puteți implementa un set greșit de modificări care ar putea dăuna sistemelor dvs. de producție. Exista, de asemenea, pericolul de a avea probleme cu permisiunile fișierelor care devin alterate, ceea ce, în cel mai bun caz, ar putea face ca aplicația dvs. să nu funcționeze corect și, în cel mai rău caz, să introducă probleme de securitate.

Epilog

Știm că timpul tău liber ca dezvoltator WordPress este destul de limitat. De aceea, am consolidat totul într-un singur document, deoarece supraîncărcarea de informații este reală și pare să afecteze toți lucrătorii cunoașterii, și nu doar dezvoltatorii WordPress. Am menționat la început că scopul nostru este să oferim în primul rând informații utile și, în al doilea rând, să abordăm subiecte care considerăm că sunt subreprezentate în literatura WordPress actuală. A deveni un dezvoltator WordPress este una, a rămâne relevant și competitiv este altceva . Și pentru a face acest lucru, trebuie să aveți o viziune bine rotunjită asupra ingineriei software ca disciplină și să dobândiți obiceiuri bune, metodologii și tehnici care să vă servească cariera pe termen lung.