Apăsați pe aceasta: Evitați datoria tehnică care ucide timpul pe versiunile WordPress cu Jon Martin

Bun venit la Press This, podcastul comunității WordPress de la WMR. Aici gazda David Vogelpohl se așează cu invitații din întreaga comunitate pentru a vorbi despre cele mai mari probleme cu care se confruntă dezvoltatorii WordPress. Următoarea este o transcriere a înregistrării originale.

Produs de RedCircle

David Vogelpohl: Salutare tuturor și bine ați venit la Press This podcasturile comunității WordPress pe WMR. Acesta este gazda dvs., David Vogelpohl, susțin comunitatea WordPress prin rolul meu la WP Engine și îmi place să vă aduc tot ce este mai bun din comunitate să vă auziți în fiecare săptămână la presa aceasta ca un memento, mă puteți găsi pe Twitter @wpdavidv , sau vă puteți abona pentru a apăsa pe iTunes, iHeartRadio, Spotify sau puteți descărca cele mai recente episoade de pe wmr.fm. În acest episod vom vorbi despre unul dintre subiectele mele preferate, și anume evitarea ca timpul să distrugă datoria tehnologică pe versiunile WordPress. Și, alături de noi pentru această conversație, aș dori să-i urez bun venit lui Jon Martin. Jon, bine ai venit la Press This.

Jon Martin: Mulțumesc mult, e bine să fii aici.

DV: Știi că exersez pronunțarea Hallum înainte de spectacol, dar bineînțeles că am încurcat-o chiar de la început. John îmi pare rău pentru asta. Minunat, așa că pentru cei care ascultă cu John’s va împărtăși gândurile sale despre impactul datoriilor tehnologice echipelor de dezvoltare WordPress, cum ar fi ce înseamnă să ai datorii tehnologice și cum te afectează? Cum te poți gândi la reducerea datoriei tehnologice pentru fiecare proiect. Și atunci de ce aveți responsabilitatea de a împărtăși clienților considerentele legate de datoria tehnologică

JM: dacă lucrezi într-o calitate de agenție independentă. Așa că îmi place să ucid datoria tehnică. Îmi place să-l elimin este unul dintre subiectele mele preferate.

DV: Vom trece la gândurile lui John cu privire la acest subiect, dar înainte de a începe, John, o să-ți pun aceeași întrebare pe care am pus-o fiecărui oaspete. Spune-mi, spune-mi pe scurt despre povestea ta de origine WordPress. Când ați folosit prima dată WordPress

JM: Deci aș fi fost la începutul anilor 2010, nu eram cu adevărat sigur de expresia corectă pentru acea perioadă de timp. Așa că, de fapt, am început eu și am fost CEO al modului în care am înființat o agenție în 2008. Și la acea vreme, WordPress era încă o platformă de blogging. Am construit site-uri web care au o mulțime de conținut bogat. Deci este un cuvânt puțin murdar, dar am folosit Joomla la acea vreme. Dar atunci mai degrabă decât

DV: Joomla este un cuvânt murdar. Îmi plac personal toate CMS open source.

JM: Da, am dori să spunem că este un proiect grozav. Cred că principalul lucru pentru noi este că, de-a lungul timpului, Joomla a fost cu adevărat puternic când WordPress a oferit suport personalizat pentru postări. Atunci lucrurile s-au schimbat cu adevărat în WordPress pentru mine, ceea ce l-a ridicat de la așa cum era cunoscută ca o platformă de blogging la a fi un CMS cu drepturi depline, pe care îl poți face pe tot felul de site-uri, dacă știi, chiar dacă este foarte mic. o singură persoană de afaceri sau liber profesionist sau orice altceva, până la site-uri web complexe de nivel comercial masiv. Și cred că într-adevăr, într-adevăr pentru mine, aceasta a fost o decizie ucigașă din partea lor, deoarece face parte din motivul pentru care WordPress este atât de popular acum. Deci da, deci atunci a fost momentul în care a început să folosească aici. Sasha povestea de dinainte este cu adevărat eu însumi și acum CEO despre modul în care am fost într-o trupă împreună. Și avem această idee strălucitoare de a ne gândi: Ei bine, știi ce, este grozav mai mult timp egal pe drum și este foarte greu să obțin timp liber de la slujbele mele actuale. Așa că ne-am gândit, știi ce, haideți să înființăm o agenție și să devenim dezvoltatori web, pentru că asta ne va ajuta cu adevărat să obținem tot acest timp pe atunci, a fost o decizie grozavă. Sunt cu adevărat mulțumit de faptul că, dar el este cu siguranță o decizie naivă, pentru că a crede că a lucra pentru tine îți oferă mai mult timp a fost cu siguranță o greșeală pe care cred că o recunoaștem puțin mai târziu. Și înainte de acel moment, știi, știam puțin despre SQL și am construit computere de bine, de fapt, deoarece placa grafică suportă foarte mult culorile. Deci, pentru oricine altcineva care știe ce este CGA, asta te va ajuta să știi câți ani am. Dar da, deci într-adevăr, a fost când au apărut CPT-urile. Grăsimea aceea a schimbat totul pentru noi. Și am început să folosim WordPress aproape peste noapte, de fapt, acesta a devenit CMS-ul nostru ales și nu ne-am uitat înapoi de atunci și, știi,

DV: dintre toți oamenii pe care v-am adresat această întrebare, foarte puțini au dat de fapt indicii despre cum au fost tipurile materiale de postări personalizate în raport cu povestea lor de origine WordPress. Și e amuzant. Am o poveste asemanatoare. Am înființat o agenție în 2010. Așa că puțin după voi, dar când a apărut postarea personalizată, am început să construim cu Joomla și am trecut la WordPress din motive similare, dar au fost aceste tipuri de postări personalizate și meta personalizate. domenii cu care sunt de acord și de fapt le-am prezentat în acest fel diverse format este că a fost acest gen de moment când WordPress a devenit cu adevărat un adevărat CMS. La un an după ce a apărut WooCommerce, a apărut WP Engine, o mulțime de alte mărci de spațiu WordPress, este o perioadă atât de transformatoare. Este interesant să aud un fel de referință care este rădăcina poveștii tale de origine. Totuși, ei îmi spuneau despre cum, și știi, momentul fondării acolo, dacă vrei, dar poți să-mi spui pe scurt despre cum și ce faci?

J M: Da, sigur. Deci, de fapt, acea agenție am descoperit că nu era așa cum ne-am motorizat mai târziu. Bine bine. Ei bine, motivul principal pentru asta este că, știi, în acele vremuri mai vechi, era o diferență foarte clară între, știi, construim site-uri web și facem SEO și toate aceste lucruri. Și nu a fost chiar atât de mulți din întreaga lume abordare integrată și gândire de fapt la lucruri precum experiența utilizatorului și cum funcționează asta cu SEO și dezvoltare, tot felul de lucruri. Deci, de fapt, acesta a fost motivul pentru care mai târziu am fuzionat cu Allen Milan de aproximativ 20 de ani și fondatorul nostru s-a înființat cam la început, când SEO a început să devină un lucru. Deci da, așa că am fuzionat cele două agenții. Acum șase, șapte ani, poate puțin mai mult. Memoria mea pentru date nu este grozavă, trebuie să recunosc. Și apoi, într-adevăr, da, asta a devenit abordarea noastră este această abordare complet integrată despre amestecarea tuturor acestor discipline diferite pentru a ajuta oamenii să vadă linia? Așa că acum facem PPC, SEO, PR digital, evident, web design și există întinderi de brand, strategie digitală și tot acest gen de lucruri, toate aceste discipline de care aveți cu adevărat nevoie pentru a avea o prezență digitală puternică în zilele noastre. Care este rolul tău acolo, companie? Deci, postul meu era director tehnic. Așa că voi fi sincer, nu acoperă prea bine tot ceea ce fac. Conduc echipa de dezvoltare pentru o perioadă lungă de timp. Deci tot ce va fi WordPress era sub conducerea mea. Sunt încântat să spun că avem dezvoltatori mult mai buni în echipă decât atunci când eu și Julio am lucrat când am început, motiv pentru care ne descurcăm mult mai bine în aceste zile. Și înțelegem lucrurile puțin mai mult. Așa că conduc echipa de dezvoltare pentru o perioadă lungă de timp, mai recent, și pe o echipă de cost de date. Asta înseamnă că pot să mă joc cu învățarea automată, Python și Bartek și alții se joacă, deși trebuie să-mi imaginez toate acestea jucând.

DV: A face clienți separati cool va avea ca rezultat niște datorii tehnologice pe parcurs. Și așa că sunt curios cum vă gândiți, care sunt tipurile comune de datorii tehnologice și, poate, specifice WordPress. Acestea pentru un minut, dar cum vă gândiți la asta în timp ce vă gândiți, știți, cum și cum vă gestionați datoria tehnologică, ca și cum ați fi blocat-o în tipuri cu WordPress construit?

JM: Da, facem. Adică nu. Nu neaparat. Facem un fel de limbaj în care nu neapărat clasificam lucrurile sau trecem printr-un proces districtual de clasificare, dar într-adevăr, se încadrează în trei categorii diferite. Unul dintre ele este atunci când construiești cod prost peste codurile existente și asta s-ar putea datora faptului că poate ai făcut unele greșeli în trecut, care ar putea fi o problemă de pe site-urile web Heritage și altcineva, indiferent de motiv, așa că acesta este un fel de prima găleată. Al doilea este codul de construcție care nu este necesar și poate că nu este necesar acum. Știi, sunt sigur că am ajuns cu toții la sfârșitul solicitărilor de caracteristici de la clienți și mărci cu care lucrăm, în cazul în care aceștia sunt cu adevărat dornici de un anumit lucru, dar de fapt s-ar putea să nu fie lucrul potrivit, în ceea ce privește obținerea valorii reale pentru clienti. Și apoi a treia, care este cea mai mare pe care o vedem de fapt, este construirea de caracteristici care ar trebui să fie într-adevăr pe o altă platformă. Deci, înțelegând acest tip de piesă arhitecturală despre bine, care sunt diferitele elemente pe care le conectăm aici este un CRM, aici este site-ul web, care în esență este cu adevărat despre marketingul afacerii. Iată platforma dvs. de onorare a comenzilor, toate atât de diferite.

D V: Permiteți-mi să vă întreb, lăsați-mă să vă pun o întrebare fundamentală aici, ca și dvs., ați cam enumerat cele trei tipuri de sunete, cum ar fi cele trei tipuri de datorii tehnologice de care doriți să scăpați, scrieți cod prost pe cod prost cod, acestea nu sunt caracteristici necesare care pot fi realizate pe o altă platformă. Ca și cum nu există o a patra găleată, cum ar fi caracteristicile pe care le doriți, care sunt valoroase și, prin urmare, tehnologia care este poate bună în acest caz? Este corect de spus? Asta e a patra găleată.

JM: Da. 100% vreau să spun, nu toate datoriile tehnice sunt rele. Trebuie să acceptați că aproape orice caracteristică pe care o veți construi va acumula un anumit tip de datorie tehnică și trebuie să suniți dacă datoria tehnică este bună sau nu. Unele sunt bune, altele sunt rele și depinde într-adevăr de acel cuvânt cheie pe care l-am spus înainte este despre valoare. Veți obține valoarea de care aveți nevoie pentru acel lucru? Mai important, este clientul, clientul final, nu clientul tău, dar ei sunt clienții lor? Vor primi valoarea pentru asta? Aceasta este de obicei o lumină de ghidare destul de bună în ceea ce privește dacă să accepte acea datorie tehnică.

DV: Da, vreau să mă scufund într-un fel în profunzime, știi cum te gândești la acel citat, merită formula pentru când e bine să accepți sau nu, dar este bine să te gândești și să înțelegi bine cum te gândești la diferitele tipuri de datorii tehnologice și, în special, cele pe care ați dori să le optimizați pentru a le elimina. Totuși, ceea ce aș vrea să fac în continuare este să înțeleg cum ar fi, a existat ceva care te-a determinat să te concentrezi în acest domeniu, dar ne vom lua prima pauză și vom face Revin imediat. Este timpul să vă conectați la o pauză publicitară. Rămâneți pe fază pentru mai multe apăsări, doar un moment. Bună ziua tuturor. Bine ați revenit pentru a apăsa acest podcast-uri ale comunității WordPress pe W EMR Acesta este gazda dvs., David Vogel. Paul. Îl intervievez pe John Martin despre anularea timpului, uciderea morților din tehnologie. John, chiar înainte de pauză, explicați că modul în care vă gândiți la cele trei tipuri de datorii tehnologice pe care ați dori să le eliminați este să construiți cod prost pe cod prost, creând cod care nu este necesar pentru succesul site-ului la care lucrați. Și apoi poate construi cod pentru funcții care pot fi servite mai bine pe o altă platformă. Înainte să intrăm într-un fel în formula citatul merită, totuși. Mă întrebam dacă a existat un anumit timp pe care nu îl cunosc, iar călătoria ta este un exemplu special de datorie tehnologică, că acest tip de suprafață pentru tine este un domeniu de interes principal pentru cum?

JM: Da, absolut. Există un adevărat proiect de reper care a început să mă facă să mă gândesc la asta cu vreo patru sau cinci ani în urmă acum. Am văzut multe alte cazuri. Pentru companiile acumulează timp, tot timpul, nu doar prin WordPress prin tot felul de lucruri, de fapt, companiile îl acumulează și prin procesele lor operaționale. Dacă trebuie să fii un lucru tehnic în care creezi acel pachet. One, One poveste care iese în evidență în mintea mea mai mult decât oricare este clientul, lucrăm cu o companie relativ mică, am făcut multă muncă media plătită pentru ei. Vânzarea, în esență, vânzarea de lucruri online. Era o afacere de comerț electronic. Și au avut un tip tradițional de comandă prin poștă, dar o mare parte din munca lor și au încercat să genereze mai mult trafic online, astfel încât să nu fie nevoiți să treacă prin comenzi prin poștă, vor fi gestionate prin intermediul site-ului web și au venit la noi pentru că au a avut un site construit pentru ei este complet personalizat. Și există de aproximativ 10 ani în acel moment. Așa că devenise destul de vechi și începea să se strecoare puțin. Știi, standarde și mergi mai departe. Tehnologia a trecut mai departe, este timpul să ne regândim puțin. Așa că clientul s-a așezat cu noi, a început să debriefing toate lucrurile diferite pe care le-au făcut pe site. Și mi-a devenit foarte clar foarte repede că există tot felul de logici de afaceri și chestii operaționale de afaceri care au fost încorporate în site-ul web. Și asta a fost logica care duce la comenzi și este destul de specifică modului în care lucrează furnizorii. Așa că nu voi intra în detalii, dar am o înțelegere destul de complexă între furnizori și cum îndeplinesc comenzile și dacă a fost expediat în magazinul lor înainte de a trimite toate aceste lucruri. Deci totul este destul de complicat. Acum, proprietarul afacerii și cei anteriori despre modul în care funcționează, au construit în cele din urmă un sistem care gestionează aproape întregul lucru, era un sistem cu adevărat, foarte bun la acea vreme și a ajutat cu adevărat acea afacere să crească masiv. Acum, la ceea ce nu s-au gândit cu adevărat este că toate site-urile web au în cele din urmă o perioadă de valabilitate pe care o vor deveni la un moment dat, la fel ca orice software și în lumea marketingului. Perioada de valabilitate este într-adevăr relativ scurtă în comparație cu, știți, de exemplu, dacă investiți într-un CRM, deoarece o afacere va avea în mod normal acest lucru de ceva timp acum, este de aproximativ 10 ani, dacă nu mai multe site-uri web. În general, între doi și cinci ani, observăm că majoritatea mărcilor mari tind să se reconstruiască la fiecare trei ani și ceva. Deci, problema a fost că au integrat toată această logică complicată în site-ul web existent și au trebuit să reconstruiască întregul site. Și dintr-o dată trebuie să reconstruiești și toată această logică de afaceri. Acum, am costat proiectul și practic a ajuns să fie aproximativ jumătate din cifra de afaceri anuală la bază doar pentru a reconstrui ceea ce aveam deja. Și asta a început să mă facă să mă gândesc la acest lucru este că bine, bine, dacă ei abordează problema într-un mod diferit inițial, de exemplu, să ne gândim la diferitele lucruri pe care încercăm să le realizăm pe un site web. Știi, asta provine din marketing, asta pentru vânzarea produselor. Acest lucru este pentru onorarea comenzilor, acesta este cel mai bun pentru gestionarea procesului meu de afaceri cu consumabile toate acele lucruri și m-am gândit într-un mod puțin mai modular la asta, atunci ar fi fost o situație mult diferită pentru acest client, că ea era acolo . A fost o problemă reală pentru ei, deoarece aveau un site web care era în esență de unde câștigau bani. Scartaia destul de mult pentru ca e destul de veche. Dar, în același timp, avea să coste atât de mult să reconstruiești întregul site web și să complice proiectul. Am reușit să găsim o muncă destul de inteligentă, dar și deloc plăcută până la sfârșit, pentru a încerca să folosim ceea ce aveau deja și să-l integrăm, dar nu putem cita, dar știi, în cele din urmă a ajuns să fie mult mai dureros, mult mai lent și mult mai mult. scump decât trebuia să fie. Dacă acea arhitectură ar fi fost gândită inițial.

DV: Am atât de multe proiecte încât vreau să uit de asta. Erau exact așa, și pot, mă pot imagina acum, mă duc înapoi în timp. Așadar, mie mi se pare destul de clar, cred că este o lecție importantă să te gândești la tipul de cost pentru afacere în raport cu refactorul pe care îl plănuiești. Și mie mi s-a părut că răspunsul clar a fost că ai nevoie pentru a-l arhitectura altfel. Și asta este, poate, o cale mai clară, dacă vrei să-ți placă ceea ce ar trebui să faci. Dar cred că la fel ca multe echipe când se gândesc la datoria tehnologică, parcă gândesc: Bine, ei bine, ar fi tare să facă chestia asta, dar merită?

JM: Merită să mențin chestia asta în timp? Așa că sunt doar curios cum crezi tu despre această formulă

D V: când, cum ar fi, Când este bine să introduceți datoria tehnologică? Și cât de mult cum credeți despre această formulă?

JM: Da, ai atins un punct cu adevărat important, că, știi, te gândești la natura dezvoltatorilor, dezvoltatorii intră în asta pentru că le place să facă lucruri interesante. Și asta este, știi, o mare parte a motivației noastre este să învățăm cum să facem lucruri noi, noi tehnologii, știi, noi cadre JavaScript, oricare ar fi lucrul, și asta ne oferă în mod natural motivația care devine să construim lucruri interesante, dar nu ne gândim neapărat pe termen lung la asta, știi, încă o vom menține. Știi, soției mele i-ar plăcea să ia o cadă cu hidromasaj la mine acasă, dar știu că cineva o va curăța și voi fi sincer, nu cred că oricine o curăță, oricum e genul ăsta de gândire. Așa că este o întrebare foarte, foarte, foarte bună la care să te gândești, dacă merită în primul rând, și dacă o descompun puțin, există câteva lucruri diferite la care te-ai putea gândi, în primul rând, să te gândești mult Pe termen lung, care este costul total de proprietate și construirea acelui lucru de testare și întreținere, și apoi cântăriți-l față de valoarea pe care o obținem? Deci, de exemplu, poate exista o modalitate foarte simplă de a rezolva această problemă. folosind foi de calcul sau folosind lucruri arhitecturale ușor diferite, în cazul în care poate cineva din interiorul companiei gestionează asta pentru o perioadă scurtă de timp. Și ar fi mai ieftin să faci asta și mai eficient să faci asta decât ar fi să construiești această caracteristică cu adevărat complicată. Dar când te uiți de fapt la costul total de proprietate, acesta va costa mai mult decât ar fi pentru cineva care petrece câteva ore pe săptămână pentru a face un anumit lucru. Nu mă înțelege greșit. Sunt un mare credincios în automatizare. tehnologiile ar trebui să se automatizeze cât mai mult posibil pentru a evita acest tip de admin dar

DV: te înscrii și folosești ca acest manual abordări pentru a încerca ceva înainte de a-l codifica pentru a te asigura că acea valoare va fi acolo. Adică, îmi vine ideea de a simplifica acest factor, cum ar fi, putem face asta manual în schimb? Ești curios dacă te-ai abordat vreodată dintr-o perspectivă de testare pentru a aprecia, să vezi dacă merită revenirea finală?

JM: Da. 100%. Deci sunt un mare credincios în metodologia Agile. Și, în esență, una dintre principiile cheie ale Agile este că construiești lucrul potrivit la momentul potrivit. Și te concentrezi pe câștigarea de valoare cât mai repede posibil. Deci vrei să construiești produsul minim viabil. Acum, asta înseamnă că nu aveți neapărat ceva care este complet bogat în funcții în acel moment. Dar vă oferă o platformă de unde puteți începe apoi să o testați, știți, obțineți de fapt lucrurile pe care le doriți de la asta? Utilizatorii tăi răspund la asta? În felul în care vă așteptați, oricine a lucrat în cadrul UX sau al dezvoltatorului web va ști că destul de des vor primi solicitări de la clienți pentru că ei cred că clienții lor, dar chiar își doresc asta? Deci, aceasta este o altă întrebare foarte bună de pus este, odată ce te-ai gândit la acea viziune pe termen lung, oamenii care vor folosi site-ul web știm că cineva îl folosește sau trebuie să testăm pentru a vedea dacă doresc sa-l foloseasca? Și apoi, odată ce ați făcut acel test, putem stabili ce nu ar fi trebuit să-l cerem și dacă ar trebui să ne retragem și să ne plasăm efectiv investiția în altă parte.

DV: Așa că sună ca să recapitulez aceste gânduri și mi-a plăcut ideea ta de a te uita la costul total de proprietate pe termen lung, știi, cred că de multe ori echipele cred că chiar și oamenii pe care îi cunoști, citează, comandă servicii de la echipele se gândesc câte ore sau săptămâni sau împrăștie sau puncte sau orice altceva va construi acest lucru. Dar apoi, știi, trebuie să ții cont de faptul că știi, câte ore sau săptămâni sau spread-uri sau puncte va fi nevoie pentru a menține și apoi să folosești acel echilibru față de valoarea pe care o obții din menținere. acea activitate. Ești evident că este un sfat sănătos. Dar apoi te gândești și cum ar fi, Ei bine, pot face ceva pentru a testa asta pentru a vedea dacă presupunerile mele sunt corecte? Sună corect?

JM: Da. Absolut. Absolut. Și singurul aspect la care nu ne-am atins este despre care am vorbit puțin mai devreme, care este despre arhitectură, există o modalitate mai bună de a putea structura asta pentru a o îmbunătăți și acea perioadă pentru programarea obiectelor și alte lucruri despre care probabil mă voi referi puțin mai târziu.

DV: Da, și considerentele arhitecturale, cum am scris cum erați, există vreo modalitate de a schimba specificațiile? Este la fel ca în formarea cu părțile interesate sau discuțiile pe care le spun adesea că știi, specificația de a depune, nu? Solicitați ceea ce aveți nevoie cu adevărat pentru a vă caza. Și așadar, întrebându-i pe aceștia, va minți și va fi cu adevărat nevoie și ce zici de asta? Întrebările au fost considerate a fi foarte critice. Deci se pare că aceasta este o parte cheie a modului în care te gândești la asta.

JM: Da, pentru că fiecare minut în care acel site este în dezvoltare este un minut în care nu primește valoare în fața clienților. Și acesta este modul ușor de a gândi. Vrei să fii lansat cât de repede poți. Și apoi testează, monitorizează, repetă, învață, știi, vezi unde mergi de acolo, dar numai pentru că faci asta pe baza datelor reale, mai degrabă decât a ceea ce crezi că este corect. Pentru că deseori nu sunt la fel.

DV: Da, îmi place acest punct. În fiecare minut. Este în dezvoltare, nu-i așa că într-un minut nu îl folosești să-ți dai seama și voi spune legături înapoi cu un fel de legături înapoi cu o altă mantră pe care o am și managementul de proiect și managementul părților interesate, care sunt cele mai bune două cuvinte și primirea unui proiect pe fața noastră să scriem. Cum poți vorbi, da, îmi place asta când am de-a face cu părțile interesate sau când am o parte interesată este o parte puternică, puternică. Bine in regula. Hai să vorbim în continuare despre ce pot face echipele pentru a reduce datoria tehnologică. Dar înainte de a face asta, ne vom lua ultima pauză. Este timpul să vă conectați la o pauză publicitară. Rămâneți pe fază pentru mai multe apăsări într-un moment. Toți sunt bineveniți să apăsați acest podcast comunitar WordPress pe W EMR. Acesta este gazda dvs., David mobil, Paul, sunt în mijlocul unei discuții despre evitarea timpului uciderea datoriei tehnologice cu John Martin despre modul în care John chiar înainte de pauză, am vorbit puțin despre formula dvs. merită. Mi-au plăcut foarte mult noțiunile dvs. despre reducerea specificații. Și să ne gândim la TCO și la o abordare de testare iterativă. Dar să cercetăm acum ce pot face echipele pentru a-și reduce datoria tehnologică și construirea WordPress. Care sunt unele dintre tehnicile tale preferate pentru reducerea datoriilor tehnologice?

JM: Deci există tot felul de tehnici tehnice pe care le poți folosi și știi că unele dintre ele le-ai fi familiarizat, astfel încât să nu le faci, dar de fapt punctul de plecare pentru mine este că este o abordare mult mai blândă a vorbirii clienților tăi. Și trebuie să vă amintiți că, în cele din urmă, clienții tăi sunt aceste mărci care vin la noi pentru că noi suntem experții. Au nevoie de sfatul nostru și este destul de ușor să cădem în capcana că, știi, suntem acolo doar pentru a face ceea ce vor ei, ceea ce suntem acolo pentru a face ceea ce vor ei, dar, de fapt, suntem acolo. să provoace ceea ce vor să facă și să încerce să-l îmbunătățească. Deci, primul lucru pe care îl puteți face este să discutați cu ei despre asta și să le explicați. Bine, dacă facem asta, acesta va fi efectul pe termen lung. Știi, ne va lua o zi în plus de testare. De fiecare dată când facem o lansare, aceasta va adăuga câteva ore sau două de fiecare dată când trebuie să întreținem site-ul web și să actualizăm toate pluginurile sau orice ar fi acesta. Dar prin creșterea gradului de conștientizare, purtăm acele conversații cu ei. Puteți determina clientul să facă parte din această discuție. Și apoi, în cele din urmă, ei devin parte din rezolvarea problemelor cu este bine, trebuie să ne educăm clienții tot timpul, pur și simplu pentru că ei nu știu unele lucruri pe care le facem. Dacă ar face-o, nu ar deveni instrumente în primul rând. Deci, de fapt, acesta este punctul de plecare. El crede că ține minte asta și simplifică lucrurile. Din nou, oamenii nu sunt neapărat la fel de tehnici ca noi. Așa că folosește analogii pentru a vorbi despre asta. Întotdeauna constat că casele sunt o energie grozavă. Toată lumea locuiește în casă. Majoritatea oamenilor au o oarecare experiență în a face un fel de îmbunătățire a casei. Așa că a fost destul de ușor să folosești acea energie pentru a repara lucrurile. Deci, acesta este genul de primul punct cu adevărat este să obțineți un client sau să ciclați acele conversații. Următorul lucru pe care l-am atins înainte, care a fost să avem acea viziune pe termen lung sau costul total de proprietate. Și puneți-vă acele întrebări și întrebați fiecare solicitare de funcție. Dar fiind puțin mai tehnic și cum ai face asta la locul de muncă. Lucruri simple pe care le folosești standardele WordPress, știi, există standarde care există. Ele există cu un motiv. Acum, ei ne vor ajuta pe noi dezvoltatorul și poate lucrați la un proiect pe care îl lăsați timp de un an sau doi și apoi reveniți la el. Trebuie să vă reîmprospătați memoria și să vă întoarceți unde erați când ați construit-o pentru prima dată folosind standarde. Vor ajuta și alți oameni. Deci, dacă nu ai fost în echipă, înseamnă că ai acest limbaj comun pe care îl poate opera toată lumea, care este cu adevărat, foarte util în ceea ce privește eficiența și, și ajuta la documentare și toate aceste tipuri de lucruri. Așa că acesta este un fel de o modalitate mai blândă de a vă reduce datoria tehnică, având standarde pe care oricine le poate lucra. De asemenea, vă ajută să știți că poate veni momentul în care alți dezvoltatori WordPress lucrează la acel proiect. Și îi ajută să se gândească la asta ca la o modalitate de a răsplăti comunitatea și de a le face mai ușor pentru colegii tăi dezvoltatori. Deci, acesta este un, știi, un punct bun în ceea ce privește un fel de standarde și să faci totul ușor pentru tine și ceilalți. Următorul este mai mult despre grozav. Un mare cod al industriei, cunoscut cu afecțiune ca unchiul Bob, care a scris o carte minunată numită Codificatorul curat cu mulți ani în urmă. Aș recomanda cu căldură oricărui dezvoltator să citească acea carte pentru că nu a citit-o. De fapt, am făcut o lectură obligatorie pentru o echipă de dezvoltare, pentru oricine care s-a alăturat echipei, mai ales pentru că are o abordare atât de bună față de ea vorbește despre testarea unitară, toate aceste lucruri, dar, în principiu, multe. se referă la modul în care scrieți codul într-un mod care îl face flexibil, pe care îl puteți repeta și modifica foarte rapid și adăuga biți suplimentari în el. Unul dintre punctele mari despre care vorbește este despre refactorizarea des, iar acesta este principalul lucru de luat din asta este că scrii o bucată de cod care nu înseamnă neapărat că acea bucată de cod este terminată. Există lucruri pe care le puteți face pentru a-l optimiza, pentru a-l face mai portabil, pentru a-l face mai modular sau pentru a face un test mai bun, oricare ar fi acel lucru pe care trebuie să-l faceți pentru a petrece timp refactorizarea codului. Poate fi foarte, foarte greu de făcut când te confrunți cu asta sau știi, poate că este un interval de timp pentru un buget. Dar, în cele din urmă, acesta este genul de lucru care vă va împiedica să acumulați datorii tehnice și, de fapt, de obicei, acesta este modul în care văd că devine forțat, dar ca termen limită pentru proiect în vigoare, trebuie să atingeți acel termen limită. Absolut. Trebuie să-l lovești, dar este mai bine să flexibilizezi domeniul de aplicare decât să scrii cod prost la care vei merge apoi,

DV: Cred că educați-i și pe acești clienți despre asta, pentru că nu am întâlnit niciodată un dezvoltator care să nu fi vrut să refactoreze. Cod. Este întotdeauna cronologia. Este împotriva ei. Um, bine, deci iată ultima parte. Sunt doar curios dacă vă place de noi, dacă vă gândiți la lucruri precum descărcarea și utilizarea pluginurilor de la raft este o altă modalitate de a ajuta la evitarea tehnologiei sau alte modalități de a evita datoria tehnică. Este și asta în lista ta?

JM: Da. 100% Deci, aceasta este o modalitate bună, dar este o modalitate bună de a face ambele, de fapt, puteți evita datoria tehnică. Dar poți, de asemenea, și asta știi, WordPress este o formă de BMC. Este atât de activ, în egală măsură, încât poate fi și cel mai mare dușman al său. Există un plugin care face totul. Și există, de asemenea, o mulțime de pluginuri care au fost construite pentru un scop foarte specific, dar nu se potrivesc neapărat cu propriile plugin-uri. Așa că am văzut asta în special cu unii dintre dezvoltatori cărora le place să construiască site-uri folosind plugin-uri și un fel de abordare mai mult punct și clic față de lucruri, mai degrabă decât codificarea din punct de vedere de la zero. Oamenii tind să arunce plugin-uri la lucruri. Am lucrat cu site-uri web care au avut peste 100 de plugin-uri și o grămadă dintre ele nu mai sunt întreținute. Există probleme de securitate peste tot. Încercați să faceți rata de lansare. Petreci literalmente patru zile testând-o când ai fi putut să faci asta în câteva ore. Deci, pluginurile So pot fi bune sau pot fi rele. Conectarea potrivită la momentul potrivit a fost un lucru minunat, minunat. Cele mai mari puncte forte ale WordPress, dar conectarea greșită la momentul nepotrivit poate fi, de asemenea, grav dăunătoare. Și, de fapt, poate fi una dintre cele mai mari surse de capital care

DV: Cu siguranță am avut un astfel de proiect. Ei bine, John, asta a fost incredibil de perspicace. Vă mulțumim foarte mult pentru că v-ați alăturat nouă astăzi.

J M: Plăcerea mea.

DV: Minunat. Dacă doriți să aflați mai multe despre ce Jon, puteți vizita hallam.co.uk. Mulțumesc, tuturor pentru că ați ascultat pentru a apăsa podcasturile comunității WordPress pe WMR. Din nou, acesta a fost gazda dumneavoastră David Vogelpohl. Sprijin comunitatea WordPress ca parte a rolului meu la WP Engine și îmi place să aduc tot ce este mai bun din comunitate aici pe Press This.