Cele mai grave cinci greșeli ale mele de dezvoltare WordPress

Sau, la toate serverele pe care le-am folosit înainte: o privire înapoi îngrozită la cele mai grave cinci greșeli WordPress pe care le-am făcut

În calitate de dezvoltatori, facem diferite tipuri de greșeli în diferite momente ale carierei noastre. În dezvoltarea WordPress, în special, facem diferite tipuri de greșeli pe măsură ce cunoașterea noastră cu baza de coduri WordPress crește.

Acum câțiva ani l-am auzit pe Matt Mullenweg declarând ceva în sensul că majoritatea oamenilor își repetă greșelile, oamenii mai inteligenți învață din greșelile lor, iar cei mai deștepți dintre noi învață din greșelile altora. Îmi place mai degrabă asta și aș adăuga un corolar: toată lumea greșește, oamenii umili împărtășesc acele greșeli în privat, iar cei mai îndrăzneți dintre noi le notează și le publică pe un blog!

Dar mai târziu este timp de gândire. Citiți acest articol pentru că doriți să aflați despre un accident de tren, iar eu sunt inginerul. Fără alt preambul, alăturați-vă cu mine într-o privire înapoi îngrozită la cele mai jenante cinci greșeli pe care le-am făcut ca dezvoltator WordPress.

Când am actualizat o versiune piratată a WordPress Core

Tocmai absolveam de la a face concerte de codare CraigsList extrem de obscure, până la a lucra într-o adevărată agenție live. sosisem! Eram nervos să lucrez din alt loc decât canapeaua mea, în altceva decât pijamaua mea. Dar chiar și atunci, în general, cunoșteam WordPress Right de la WordPress Doing It Wrong și mi s-a părut plăcut să mă laud cu cele mai bune practici WordPress, cum ar fi niciodată „hacking core”.

Prima mea sarcină de dezvoltare WordPress la această agenție a fost să reiau un proiect blocat — unul destul de complex pentru abilitățile mele de la acea vreme. A implicat o mulțime de personalizări ale fluxului de înregistrare și autentificare WordPress. Dezvoltatorul anterior era reputat că a realizat progrese semnificative prin simpla editare a fișierelor de bază wp-login .

Știam că acest lucru nu este sustenabil, așa că prima mea ordine de lucru a fost să instalez un plugin de backup/restaurare și să înlocuiesc nucleul WordPress cu o versiune proaspăt descărcată. Eram încrezător că încă nu sa realizat nimic teribil de impresionant în proiect și că voi putea imita setul de caracteristici existente prin filtre.

Oricare ar fi capacitatea de codare pe care aș fi putut sau nu să o aveam în acel moment a devenit rapid irelevantă, deoarece noul meu angajator era înnebunit. Ea nu înțelegea semnificația „hacking core” și nu eram suficient de matur pentru a-l explica într-un mod digerabil. Singurul lucru care i-a răcit temporar sprânceana a fost când am asigurat-o că pot reveni prin pluginul de backup/restaurare pe care l-am instalat.

Poți ghici unde se duce asta?

Acel plugin, așa cum a vrut soarta, a făcut doar copii de rezervă pentru folderul wp-content . Orice hack-uri WordPress erau în acele fișiere de bază au dispărut pentru totdeauna. Îmi amintesc încă e-mailul meu înapoi la ea (de mult mă alungase înapoi la biroul meu de acasă până acum):

Băieți, nu pot face backup.

Eram într-adevăr pregătit să-și completez setul de funcții dorit prin filtre și acțiuni, dar ea nu l-a auzit. M-a concediat pe loc, m-a amenințat că mă va da în judecată și nu m-a plătit niciodată pentru două săptămâni de muncă foarte grea. Am fost atât de umilită.

Sunt multe lucruri (acum evidente) pe care le-aș fi putut învăța din această experiență. Lecția generală, potrivit căreia o copie de rezervă nu este o copie de rezervă până când nu a fost repetată și confirmată, este una bună. Dar cea care mi-a rămas mai interesantă este o lecție specifică despre cum să procedez exact cu backup-urile în WordPress - în special cu WordPress core.

Am învățat să prețuiesc cu adevărat mediile gestionate precum WP-Engine, cu un sistem robust de backup/restaurare. Multe gazde de tip boutique au diverse instrumente de linie de comandă și alte caracteristici axate pe dezvoltatori pentru a efectua copii de rezervă, dar WP-Engine este preferatul meu. Este destul de rapid, cu excepția cazului în care aveți o rețea foarte mare. Interfața de utilizare este simplă. Are o interfață de utilizare, punct: oricine știe să folosească WordPress poate lucra cu asta. Adică, spre deosebire de o abordare CLI care este probabil mult mai rapidă, sau de un lucru obscur îngropat în Plesk, clienții mei pot folosi acest lucru, îl pot înțelege, îl pot monitoriza și verifica dacă îl folosesc. Sunt un mare fan.

Timpul în care am târât întreaga noastră platformă în directorul său de frați

Eram încă destul de nou la locul de muncă profesional și fusesem întotdeauna o persoană Windows. Cu toate acestea, noul meu loc de muncă a fost la un magazin Mac și am învățat să iubesc totul despre el foarte repede. Ei bine, aproape totul. Părea că am multe probleme cu „șoarecele magic”. Am avut tendința de a-mi pierde conexiunea Bluetooth, ceea ce duce la acțiuni accidentale și adesea înfricoșătoare de glisare și plasare odată ce s-a reconectat. Mai mult decât atât, eram doar neîndemânatic cu o nouă abilitate motrică fină.

În aceste zile, fluxul nostru de dezvoltare WordPress includea încă implementarea în producție prin FTP. Nu era neobișnuit să-mi petrec zile întregi de lucru scriind cod, discutând, răspunzând la e-mailuri, în general învârtindu-mă încoace și încolo cu noul meu mouse magic, cu Cyberduck deschis pentru producție pe desktop. Doamne, asta sună rău! Dar așa a fost.

Într-o zi toată platforma noastră tocmai dispăruse. Administratorul nostru de sistem a presupus rapid că era un fel de DDoS sau ceva în general la nivelul lui. În ceea ce privește noi, dezvoltatorii, am avut încredere în instinctele lui și am presupus că își va da seama destul de curând.

Au trecut orele. Ziua a venit și a plecat. Încă în jos.

În dimineața următoare, lucrurile s-au restabilit și CTO m-a rugat cu blândețe să mă alătur ei în sala de conferințe. Administratorul nostru de sistem a identificat problema. El a scos jurnalele FTP și a observat că utilizatorul meu mutase întreaga noastră platformă într-un director de frați. Adică, wp-content a devenit imbricat sub wp-includes .

Eram dezamăgit, dar CTO-ul nostru a fost grozav. Își dădea seama că, în general, eram un angajat util și responsabil, dar m-a provocat să trec dincolo de simpla contriție și să găsesc modalități de a preveni ca acest lucru să se întâmple din nou. Am găsit două lucruri cu adevărat utile.

Prima a fost localizarea unei comenzi CLI pentru a împiedica Cyberduck să permită mișcările fișierelor de la distanță la distanță. Aceasta a fost o măsură bună de siguranță și am adoptat-o ​​imediat ca politică a companiei.

Al doilea a fost că am fost foarte interesat de implementarea prin Git. În cele din urmă, am ajuns să scriu un plugin WordPress pentru a integra versiunea noastră Bitbucket în fluxul normal de actualizare wp-admin . De atunci, nu am avut aproape niciun motiv să avem acces FTP la producție. Acest plugin este una dintre realizările mele profesionale preferate. Desigur, o afinitate pentru Git este o condiție prealabilă pentru dezvoltatori de astăzi.

Momentul în care am eliminat tot conținutul front-end prin add_filter()

Chiar credeam că am devenit destul de inteligent cu practicile mele WordPress până în acest moment. Solicitarea a fost de a adăuga o „insignă” la postările dintr-o anumită categorie. Din anumite motive, am avut în vedere că numai noobs ar adăuga încă o condiție la un fișier șablon pentru așa ceva, așa că, cu mare mândrie, am implementat următorul filtru:

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

Vezi ceva în neregulă cu asta? L-am testat rapid în punere în scenă pentru a confirma că postările necesare au primit insignele aplicate. Apoi l-am desfășurat și am plecat de la muncă pentru ziua respectivă. După cum ați putea ghici, universul a explodat.

Mai exact, rezultatul a fost că postările fără insignă erau redate pe front-end fără niciun conținut! Poți vedea de ce? Problema a fost că, în loc să returnez $content în starea mea de gardă, returnam false . Dar într-adevăr există multe straturi de greșeli aici.

De ce m-am mulțumit să testez doar că postările au primit o insignă? De ce nu am testat și că alte postări au rămas nevătămate? De ce am fost implementat în producție atât de târziu în timpul zilei? De ce controlul nostru de calitate a constat în întregime în faptul că făceam un pic de clic și reîmprospăteam pagina?

Răspunsul la toate aceste întrebări poate fi rezumat ca maturitate . Pur și simplu durează ceva timp să ne săturam să facem astfel de greșeli, înainte să fim mutați să investim în lucruri precum testarea regresiei vizuale și testele unitare. Această greșeală specială a fost o picătură, printre sute, care în cele din urmă a rupt spatele cămilei și m-a determinat să devin foarte investit în phpUnit și xDebug. La rândul lor, acele instrumente m-au învățat despre scrierea codului testabil, ceea ce probabil a prevenit mai multe erori decât testele în sine.

Timpul pe care l-am împărțit la zero în interiorul unei bucle infinite

Solicitarea clientului a fost să reformateze articolul de pe blog WordPress astfel încât data să citească „Acum XYZ”, spre deosebire de „10 noiembrie 2011”. Nu eram exact sigur cum să realizez acest lucru, dar eram conștient că era un format de dată care părea să crească în popularitate și, într-adevăr, Dr. Google mi-a oferit un fragment foarte repede. A funcționat pe localul meu! Avea multă matematică, în special, multă diviziune . Nu eram exact sigur de ce a funcționat - au existat o mulțime de bucle imbricate, resturi, rotunjiri și altele. Dar era pe Google și părea că funcționează și am fost suficient de fericit să îl implementez în producție.

Aproximativ 30 de minute mai târziu, am primit un Skype neprietenos de la administratorul nostru de sistem. Producția a scăzut. Moartă în apă. M-a întrebat dacă am împărțit la zero în ultima vreme și nu aveam idee la ce s-ar putea referi. Iată ce sa întâmplat.

Credeți sau nu, fragmentul ilizibil „a lucrat pe localul meu” pe care l-am găsit, având în vedere o dimensiune suficient de mare a eșantionului, era capabil de un comportament aberant. Furnizate cu unele combinații nefericite de zile, ore și minute, buclele Rube Goldberg ar încerca ocazional să împartă un număr la zero. Amintiți-vă de la matematica din liceu:

În aritmetica obișnuită, expresia nu are sens, deoarece nu există un număr care, înmulțit cu 0, dă a (presupunând a ≠ 0), și astfel împărțirea la zero este nedefinită. - Wikipedia

Deci, ce înseamnă asta pentru computere? De obicei, doar un mesaj de eroare în jurnale, dar în cazul meu, a fost mai rău: eroarea de matematică a interferat cu logica buclei mele, făcând ca buclele mele imbricate să ruleze fără să se termine vreodată - o buclă infinită care ducea la un ecran alb al morții. Și devine mai rău! Deoarece fiecare iterație a buclei scria o eroare pentru împărțirea la zero, jurnalul de erori a crescut la proporții fantastice și a început să împiedice sistemul nostru de fișiere. Acest lucru a avut efectul unui atac DDoS, deși unul absurd de autoprovocat.

Lucrul rău la această greșeală a fost că a doborât un site cu trafic intens. Lucrul bun despre această greșeală este că mi-a schimbat dramatic abordarea față de muncă. Mai mult decât orice, mi-a fost rușine de disponibilitatea mea de a implementa fără să înțeleg. Mi-am jurat să nu mai lipesc niciodată un fragment fără a depune toate eforturile posibile pentru a înțelege fiecare rând, chiar și dacă este necesar, să urmăresc autorul fragmentului.

Mai mult decât atât, am jurat să nu mai livrez niciodată cod care să nu fie foarte ușor de citit pentru dezvoltatorii începători. Am devenit obsedat de standardele de codare WordPress, extensiile editorului de text, comentariile inline și blocurile de documente și chiar și tab-urile versus spații, acel rit clasic de trecere! În concluzie, am decis să-mi pese mai mult cât de ușor a fost să-mi citesc codul decât cât de ușor a fost să-l scriu . Această rebeliune împotriva lipirii fără înțelegere m-a determinat să am un interes profesional profund în gestionarea dependențelor de la terți, un subiect care a alimentat diverse oportunități de scris și vorbire pentru mine în deceniul următor.

Oh, și lucrul cu adevărat amuzant despre această greșeală? Miezul WordPress are o soluție cu o singură linie pentru acesta.

Momentul în care am lăsat un proiect să scape de sub control până când toată lumea s-a săturat de el

Am aterizat un proiect cu adevărat fascinant. Trebuia să fiu liderul tehnic și inginer de dezvoltare WordPress și aveam să-mi raporteze un dezvoltator Amazon AWS Lambda și un expert profund în JavaScript. A fost prima dată când am avut mai multe persoane care îmi raportau și a fost de departe cel mai complex proiect la care am lucrat vreodată. Chiar și să mă refer la el ca un proiect WordPress a subestimat foarte mult problema, dar WordPress a fost lipiciul care a ținut totul împreună, așa că a avut sens pentru mine să acționez ca lider tehnologic.

Deoarece rolul meu principal era de obicei să fiu strict tehnician și, de asemenea, pentru că am o afinitate pentru minimalism, nu mi-a trecut niciodată prin cap să implementez ceva ca Jira sau Basecamp sau orice platformă reală pentru managementul sarcinilor. Lucrurile au decurs destul de bine pentru prima iterație a proiectului. Am putut să lucrăm la propriile componente individuale, să ne referim la documentul cu specificațiile clientului ca foaia noastră de parcurs pentru produse și să ne dăm ping unul altuia prin Slack atunci când trebuia să cuplam lucrurile.

Problemele au început când am început să prezentăm clientului progresul și să punem în aplicare feedback-ul acestuia. Ceea ce a început ca o echipă de trei persoane a simțit instantaneu că a fost dus la un nou ordin de mărime: nu era clar cine este responsabil pentru ce parte de feedback, care este stadiul implementării acelui feedback sau chiar cine vorbea cu cine. . Am depășit de mai multe ori limita Gmail de 100 de răspunsuri pe fir!

Lucrurile au început să devină inconfortabile. Cred că clientul a simțit că și-a pierdut controlul asupra direcției proiectului și, la fel de important, a simțit că și-a pierdut vizibilitatea asupra stării proiectului. Dezvoltatorul meu Amazon a menționat într-o zi: „Mă întreb dacă ar trebui să folosim Trello”.

Huh , m-am gândit. O echipă de trei persoane are nevoie de o astfel de platformă? Din nou, tendința mea obișnuită este de a prefera mai puține instrumente, mai puține cheltuieli, mai puțină complexitate. Dar proiectul ne trăgea deja pe toți în murdărie, așa că care a fost răul în a-l încerca?

Am verificat toate e-mailurile noastre, toate documentele noastre de specificații, toate firele noastre de comentarii disparate și le-am mapat pe toate pe panourile Trello. Imediat, proiectul a reînviat din mormântul său digital, deoarece am putut comunica cu mult mai puține cheltuieli mentale. În loc să căutăm text în căsuța mea de e-mail sau un document cu specificații în general învechit, am avut panouri, liste și carduri minunate. A fost ușor să vezi starea oricărei funcții, să încorporezi feedback și să distribui noi sarcini. Aveam impresia că orbim treptat, atât de încet încât nu l-am observat și apoi brusc am putut vedea din nou.

Desigur, codul nu s-a scris singur, a fost încă un proiect foarte provocator și a trebuit să folosim fiecare gram din abilitățile noastre tehnice. Dar acesta este un fel de idee: pentru că în sfârșit aveam o infrastructură pentru înțelegerea proiectului, acum eram liberi să ne aplicăm abilitățile tehnice.

Sunt bucuros să spun că acel proiect a fost finalizat spre deplina satisfacție a clientului. În zilele noastre, consider că Trello sau Jira sunt o cerință de facto pentru echipele de două sau mai multe.

Du-te mai departe și învață din greșelile altora

Iată unul dintre cele mai deștepte lucruri pe care le-am auzit predate în timpul petrecut în armată: „Este în regulă ca locotenenții să greșească locotenenții și e bine ca căpitanii să facă greșeli de căpitan. Ceea ce nu este în regulă este ca căpitanii să facă greșeli pe locotenent sau ca locotenenții să facă greșeli private.”

Cu alte cuvinte, este în regulă să faci greșelile comune care sunt de la sine înțeles pentru nivelul tău actual de responsabilitate. Ceea ce este mai important este cum crești din ele.

Sper că noi, ca dezvoltatori, învățăm să fim compasivi cu ceilalți atunci când fac greșeli, așa cum sperăm că alții au fost cu noi. Sper să rămân curios și responsabil atunci când fac greșeli, astfel încât să continui să inovez peste ele. Sper să fiu mereu înconjurat de o comunitate inspirată de experți WordPress - oameni de la care pot învăța greșeli și să evit să fac eu. Și nu în ultimul rând, sper că alții pot învăța din experiența mea, cum ar fi greșelile WordPress pe care le-am împărtășit aici.