Premi questo: evitare il debito tecnologico che sminuisce il tempo su WordPress si basa su Jon Martin

Benvenuto in Press This, il podcast della community di WordPress di WMR. Qui l'host David Vogelpohl si siede con gli ospiti di tutta la comunità per parlare dei maggiori problemi che devono affrontare gli sviluppatori di WordPress. Quella che segue è una trascrizione della registrazione originale.

Realizzato da RedCircle

David Vogelpohl: Ciao a tutti e benvenuti su Press This, i podcast della community di WordPress su WMR. Questo è il tuo ospite, David Vogelpohl, supporto la community di WordPress attraverso il mio ruolo in WP Engine, e mi piace portare il meglio della community per farti sentire ogni settimana sulla stampa come promemoria, puoi trovarmi su Twitter @wpdavidv oppure puoi abbonarti per premere questo su iTunes, iHeartRadio, Spotify o scaricare gli ultimi episodi su wmr.fm. In questo episodio parleremo di uno dei miei argomenti preferiti, ovvero evitare di ammazzare il debito tecnologico sulle build di WordPress. E unirmi a noi per questa conversazione, vorrei dare il benvenuto a Jon Martin. Jon, benvenuto su Press This.

Jon Martin: Grazie mille, è bello essere qui.

DV: Lo so che mi alleno a pronunciare Hallum prima dello spettacolo, ma ovviamente ho sbagliato tutto all'inizio. John mi dispiace per quello. Fantastico quindi per coloro che ascoltano con John condividerà i suoi pensieri sull'impatto del debito tecnologico sui team di sviluppo di WordPress, come cosa significa avere un debito tecnologico e in che modo ti influenza? Come puoi pensare di ridurre il tuo debito tecnologico su ogni progetto. E poi perché hai la responsabilità di condividere le considerazioni sul debito tecnologico con i tuoi clienti

JM: se lavori come agenzia freelance. Quindi amo uccidere i debiti tecnologici. Amo eliminarlo è uno dei miei argomenti preferiti.

DV: Passiamo ai pensieri di John sull'argomento, ma prima di iniziare, John, ti farò la stessa domanda che ho fatto a tutti gli ospiti. Dimmi brevemente, parlami della tua storia di origine di WordPress. Quando è stata la prima volta che hai usato WordPress

JM: quindi sarei stato all'inizio degli anni 2010 non ero davvero sicuro dell'espressione corretta per quel periodo di tempo. Quindi in realtà ho iniziato io stesso e sono stato CEO di come abbiamo avviato un'agenzia nel 2008. E all'epoca, WordPress era ancora una piattaforma di blogging. Stavamo costruendo siti Web con molti contenuti ricchi. Quindi è una parolaccia, ma all'epoca usavamo Joomla. Ma allora piuttosto che

DV: Joomla è una parolaccia. Personalmente mi piacciono tutti i CMS open source.

JM: Sì, vorremmo dire che è un grande progetto. Penso che la cosa fondamentale per noi sia che nel tempo Joomla è stato davvero forte quando WordPress ha pubblicato il supporto personalizzato per i siti di post. È stato allora che le cose sono davvero cambiate in WordPress per me che l'ha elevato da questo da come era noto come piattaforma di blog ad essere un vero e proprio CMS a tutti gli effetti che puoi fare tutti i tipi di siti se è per te, davvero piccolo un'azienda o un libero professionista o altro, fino a siti Web complessi e di livello aziendale di grandi dimensioni. E penso che davvero, davvero per me, sia stata una decisione killer da parte loro perché è parte del motivo per cui WordPress è così popolare ora. Quindi sì, è stato allora che ha iniziato a usare qui. Sasha, la storia precedente sono davvero io e ora CEO di come eravamo in una band insieme. E abbiamo questa brillante idea di pensare, beh, sai una cosa, è fantastico avere più tempo uguale sulla strada ed è davvero difficile ottenere del tempo libero dai miei attuali lavori. Quindi abbiamo pensato, sai una cosa, avviamo un'agenzia e diventiamo sviluppatori web perché questo aiuterà davvero a recuperare tutto quel tempo, è stata un'ottima decisione. Sono davvero molto contento di questo, ma è anche sicuramente una decisione ingenua perché pensare che lavorare per te stesso ti dia più tempo è stato sicuramente un errore che penso riconosceremo un po' più tardi. E prima di quel punto, sai, sapevo un po' di SQL e da allora ho costruito computer molto bene, in realtà da quando la scheda grafica supportava molto i colori. Quindi, per chiunque altro sappia cos'è CGA, questo ti aiuterà a sapere quanti anni ho. Ma sì, davvero, è stato quando sono usciti i CPT. Quel grasso ha cambiato tutto per noi. E abbiamo iniziato a usare WordPress praticamente da un giorno all'altro, in realtà, quello è diventato il nostro CMS scelto e da allora non ci siamo più guardati indietro e, sai,

DV: Di tutte le persone a cui ti ho fatto questa domanda, pochissime hanno effettivamente capito come i tipi di post personalizzati materiali fossero relativi alla loro storia di origine di WordPress. Ed è divertente. Ho una storia simile. Ho fondato un'agenzia nel 2010. Quindi un po' dopo tutto, ma quando il post personalizzato è già entrato. Abbiamo iniziato a creare con Joomla e siamo passati a WordPress per motivi simili, ma erano questi tipi di post personalizzati e meta personalizzati campi su cui sono d'accordo e in realtà ho presentato in questo modo vari formati è che è stato questo tipo di momento in cui WordPress è diventato davvero un vero CMS. Un anno dopo la nascita di WooCommerce, è nato WP Engine, molti altri marchi di spazio WordPress, è un momento così trasformativo. È interessante sentire il tuo tipo di riferimento che è la radice della tua storia di origine. Mi dicevano però, di come um, e sai, il momento della fondazione lì, se vuoi, ma potresti dirmi brevemente un po' come um, e cosa fai?

JM : Sì, certo. Quindi, in realtà, quell'agenzia abbiamo scoperto che non era come è stato il modo in cui in seguito abbiamo guidato. Ok ok. Bene, il motivo principale è in realtà perché, sai, in quei vecchi tempi, c'era una differenza molto netta tra, sai, costruiamo siti Web e facciamo SEO e tutto questo genere di cose. E non c'erano molti in tutto il mondo che si avvicinavano e pensavano effettivamente a cose come l'esperienza dell'utente, e come funziona con SEO e sviluppo, tutto quel genere di cose. Quindi, ecco perché in realtà abbiamo finito per fonderci in seguito, con Allen Milan in circolazione da circa 20 anni e il nostro fondatore si è fondato praticamente all'inizio, quando la SEO ha iniziato a diventare una cosa. Quindi sì, quindi abbiamo unito le due agenzie. Sei, sette anni fa, forse un po' di più. La mia memoria per i dati non è eccezionale, devo ammetterlo. E poi E poi davvero, sì, questo è diventato il nostro approccio, questo approccio completamente integrato sul mescolare tutte queste diverse discipline tutte insieme per aiutare le persone a vedere la linea? Quindi ora ci occupiamo di PPC, SEO, PR digitali, ovviamente, web design e ci sono estensioni del marchio, strategia digitale e tutto questo genere di cose, tutte queste discipline di cui hai davvero bisogno per avere una buona presenza digitale forte in questi giorni. Qual è il tuo ruolo lì, l'azienda? Quindi il mio titolo di lavoro era direttore tecnico. Quindi sarò onesto, in realtà non copre tutto ciò che faccio. Dirigo il team di sviluppo per un lungo periodo di tempo. Quindi tutto ciò che WordPress sarà era sotto la mia direzione. Sono lieto di dire che abbiamo sviluppatori di gran lunga migliori nel team rispetto a quando Julio e io abbiamo mai lavorato quando abbiamo iniziato, motivo per cui stiamo andando molto meglio in questi giorni. E capiamo le cose un po' di più. Quindi, più recentemente, guido il team di sviluppo per un lungo periodo di tempo anche per il costo del team di dati. Quindi questo significa che posso giocare con l'apprendimento automatico, Python e Bartek e altri stanno giocando anche se devo immaginare tutto questo gioco.

DV: Fare fantastici clienti separati si tradurrà in alcuni debiti tecnologici lungo la strada. E quindi sono curioso di sapere come pensi, quali sono i tipi comuni di debito tecnologico e forse specifici di WordPress. Quelli per un minuto, ma tipo, come ci pensi mentre pensi, sai, come e come gestisci tutti i tuoi debiti tecnologici, come se lo avessi bloccato in tipi con WordPress costruito?

JM: Sì, lo facciamo. Voglio dire, no. Non necessariamente. Stiamo facendo un tipo di linguaggio che non necessariamente classifichiamo le cose o seguiamo un processo distrettuale per classificare, ma in realtà rientrano in tre diversi secchi. Uno di questi è quando costruisci codice errato su codici esistenti, e ciò potrebbe essere dovuto al fatto che potresti aver commesso degli errori in passato che potrebbero essere un problema dei siti Web Heritage e qualcun altro qualunque sia il motivo, quindi questo è il sorta di primo secchio. Il secondo è il codice di costruzione che non è necessario, e forse non è necessario in questo momento. Sai, sono sicuro che siamo stati tutti alla fine delle richieste di funzionalità da parte di clienti e marchi con cui lavoriamo per i quali erano davvero desiderosi di una cosa particolare, ma in realtà potrebbe non essere la cosa giusta, in termini di valore effettivo per i clienti. E poi il terzo, che è il più grande che vediamo in realtà, è la creazione di funzionalità che dovrebbero effettivamente trovarsi su una piattaforma diversa. Quindi, capire quel tipo di pezzo architettonico su ok, quali sono i diversi bit che stiamo collegando qui è un CRM qui è il sito Web, che fondamentalmente riguarda davvero il marketing del business. Ecco la tua piattaforma di evasione degli ordini, tutte diverse.

D V: Lascia che te lo chieda, lascia che ti ponga una domanda fondamentale qui come te, hai in qualche modo elencato i tre tipi di suoni come questi sono i tre tipi di debiti tecnologici di cui vuoi sbarazzarti scrivi codice errato su codice errato codice, non sono funzionalità necessarie che possono essere eseguite su un'altra piattaforma. Come se non ci fosse un quarto secchio come le funzionalità che desideri che siano preziose e quindi la tecnologia che forse è buona in quel caso? È giusto dirlo? Questo è un quarto secchio.

JM: Sì. 100% Voglio dire, non tutti i debiti tecnici sono negativi. Devi accettare che praticamente qualsiasi funzione che costruirai accumulerà un qualche tipo di debito tecnico e devi fare una chiamata per sapere se quel debito tecnico è buono o meno. Alcuni sono buoni, altri sono cattivi e dipendono davvero dalla parola chiave che ho detto prima riguarda il valore. Otterrai il valore di cui hai bisogno per quella cosa? Ancora più importante, il cliente, il cliente finale, non è il tuo cliente, ma sono i suoi clienti? Avranno il valore per questo? Di solito è una buona guida per decidere se accettare quel debito tecnico.

DV: Sì, voglio approfondire un po' di te, sai, come pensi a quella citazione, vale la pena formulare quando va bene accettare o meno ma è bene pensare a capire bene come pensi di i diversi tipi di debiti tecnologici, e in particolare quelli che potresti voler ottimizzare per rimuovere. Quello che mi piacerebbe fare dopo, però, è capire come, c'era qualcosa che ti ha spinto oltre il limite per concentrarti in quest'area, ma faremo la nostra prima pausa e faremo torno subito. È ora di inserirsi in un'interruzione pubblicitaria. Restate sintonizzati per più pressanti questo solo un momento. Ciao a tutti. Bentornato a premere questo i podcast della community di WordPress su W EMR Questo è il tuo host, David Vogel. Paolo. Sto intervistando John Martin sull'annullamento del tempo uccidendo i morti della tecnologia. John, proprio prima della pausa, stavi spiegando che il modo in cui pensi ai tre tipi di debiti tecnologici che potresti voler eliminare è costruire codice errato su codice errato creando codice che non è necessario per il successo del sito su cui stai lavorando. E poi magari costruire codice per funzionalità che possono essere meglio servite su un'altra piattaforma. Prima di entrare nella formula della citazione vale la pena, però. Mi chiedevo, c'è stato un particolare non conosco il tempo e il tuo viaggio è un particolare esempio di debito tecnologico che quel tipo di superficie che questo per te è un'area di interesse principale per come?

JM: Sì, assolutamente. C'è un vero e proprio progetto fondamentale che ha iniziato a farmi pensare a questo circa quattro o cinque anni fa. Ho visto molti altri casi. Le aziende accumulano tempo, tutto il tempo, non solo attraverso WordPress attraverso tutti i tipi di cose, in realtà le aziende lo accumulano anche attraverso i loro processi operativi. Se devi essere una cosa tecnica in cui crei quel mazzo. Uno, l'unica storia che mi colpisce davvero la mente più di qualsiasi altro cliente, lavoriamo con un'azienda relativamente piccola e abbiamo svolto molto lavoro sui media a pagamento per loro. Vendere essenzialmente roba in linea. Era un'attività di e-commerce. E avevano un tipo tradizionale di vendita per corrispondenza, ma molto del loro lavoro e stavano cercando di indirizzare più traffico online, quindi non dovevano passare attraverso l'ordine per corrispondenza sarà gestito tramite il sito Web e sono venuti da noi perché hanno fatto costruire un sito per loro è completamente su misura. E sono in circolazione da circa 10 anni a quel punto. Quindi stava diventando piuttosto vecchio iniziando a insinuarsi un po'. Sai, standard e vai avanti. La tecnologia è andata avanti, è tempo di ripensare un po'. Quindi il cliente si è seduto con noi, hanno iniziato a fare un debriefing su tutte le diverse cose che hanno fatto sul sito web. E mi è diventato subito molto chiaro che c'erano tutti i tipi di logica aziendale e cose operative aziendali che erano state integrate nel sito web. E questa era la logica che porta agli ordini ed è abbastanza specifica per il modo in cui lavorano i fornitori. Quindi non entrerò nei dettagli, ma ho un accordo piuttosto complesso tra i fornitori e come evadono gli ordini e se sono stati spediti nel loro negozio prima che spediscano tutto questo genere di cose. Quindi è tutto abbastanza complicato. Ora il proprietario dell'azienda e il precedente su come funzionano, alla fine hanno costruito un sistema che gestiva praticamente l'intera cosa era un sistema davvero, davvero buono all'epoca e aiutava sinceramente quell'azienda a crescere in modo massiccio. Ora, quello a cui non hanno davvero pensato è che tutti i siti Web alla fine hanno una durata di conservazione che diventerà vita ad un certo punto, proprio come qualsiasi software e nel mondo del marketing. Quella durata di conservazione è davvero relativamente breve rispetto a, sai, ad esempio, se investi in un CRM poiché un'azienda normalmente avrà quel calcio d'inizio per un po' di tempo ora sono circa 10 anni, se non più siti web. In generale, tra due e cinque anni, troviamo che la maggior parte dei grandi marchi tendono a ricostruire ogni tre anni circa. Quindi il problema è stato che hanno costruito tutta questa logica complicata nel sito Web esistente e hanno dovuto ricostruire l'intero sito Web. E all'improvviso devi ricostruire anche tutta questa logica aziendale. Ora, abbiamo costato il progetto e sostanzialmente è finito per essere circa la metà del fatturato annuo alla base solo per ricostruire ciò che già avevamo. E questo ha davvero iniziato a farmi pensare a questa cosa è che bene, ok, se inizialmente affrontano il problema in un modo diverso, ad esempio, pensiamo alle diverse cose che stiamo cercando di ottenere in un sito web. Sai, questo viene dal marketing era questo per la vendita di prodotti. Questo è per l'evasione degli ordini, questo è il migliore per gestire il mio processo aziendale con tutte quelle cose, e ho pensato in modo un po' più modulare a questo, quindi sarebbe stata una situazione molto diversa per questo cliente, che fosse lì . È stato un vero problema per loro perché avevano un sito Web da cui essenzialmente guadagnavano. Cigolava parecchio perché è piuttosto vecchio. Ma allo stesso tempo, ricostruire l'intero sito web sarebbe costato così tanto e avrebbe reso il progetto molto, molto complicato. Siamo riusciti a trovare un lavoro abbastanza intelligente ma anche non carino fino alla fine per provare a utilizzare ciò che già avevano e integrarlo ma non possiamo citare ma sai, alla fine è stato molto più doloroso, molto più lento e molto di più costoso di quanto doveva essere. Se quell'architettura fosse stata pensata in origine.

DV: Ho così tanti progetti che voglio dimenticare. Erano proprio così, e posso immaginarlo ora che mi sto riportando indietro nel tempo. Quindi, come per me, sembra abbastanza chiaro che è una lezione molto, penso, saliente pensare al tipo di costo per l'azienda rispetto al refactoring che stai pianificando. E a me sembrava che la risposta chiara fosse che avevi bisogno di architettarlo in modo diverso. E questo è forse un percorso più chiaro se vuoi che ti piaccia quello che dovresti fare. Ma penso che come molte squadre quando pensano al debito tecnologico, è come se pensassero, ok, beh, sarebbe bello fare questa cosa, ma ne vale la pena?

JM: Vale la pena che io mantenga questa cosa nel tempo? Quindi sono solo curioso di sapere come pensi di quella formula

D V: quando, tipo, Quando va bene introdurre il debito tecnologico? E quanto, come pensi di quella formula?

JM: Sì, hai toccato un punto davvero importante: sai, pensi alla natura degli sviluppatori, gli sviluppatori ci entrano perché amano fare cose interessanti. E questo è, sai, gran parte della nostra motivazione è imparare a fare cose nuove, nuove tecnologie, sai, nuovi framework JavaScript, qualunque cosa sia, e questo naturalmente ci dà la motivazione che diventa per costruire cose interessanti, ma non ci pensiamo necessariamente a lungo termine, sai, lo manterremo comunque. Sai, a mia moglie piacerebbe avere una vasca idromassaggio a casa mia, ma so che qualcuno la pulirà e sarò onesto, non credo che nessuno che la pulisca, sia quel tipo di pensiero comunque. Quindi è una domanda davvero, davvero, davvero interessante su cui riflettere, se ne vale davvero la pena in primo luogo e se lo analizziamo un po', ci sono alcune cose diverse a cui potresti pensare, prima di tutto, pensare a lungo termine, qual è il costo totale di proprietà e la costruzione di quella cosa di testarlo e mantenerlo, e poi soppesarlo rispetto al valore che otteniamo? Quindi, ad esempio, potrebbe esserci un modo davvero semplice per risolvere quel problema. utilizzando fogli di calcolo o utilizzando un'architettura leggermente diversa in cui forse qualcuno all'interno dell'azienda lo gestisce per un breve periodo di tempo. E sarebbe più economico farlo e più efficace farlo che costruire questa funzionalità davvero complicata. Ma quando si guarda al costo totale di proprietà, costerà più di quanto sarebbe per qualcuno che trascorre un paio d'ore alla settimana per fare una cosa particolare. Non fraintendermi. Sono un grande sostenitore dell'automazione. le tecnologie dovrebbero automatizzare il più possibile per evitare quel tipo di amministratore ma

DV: ti stai registrando e usi come questo manuale approcci per provare qualcosa prima di codificarlo per assicurarti che il valore sia lì. Voglio dire, mi è venuta l'idea di semplificare questo fattore, tipo, possiamo invece farlo manualmente? Sono solo curioso di sapere se l'hai mai affrontato da una prospettiva di test per apprezzare, vedere se ne vale la pena?

JM: Sì. 100%. Quindi sono un grande sostenitore della metodologia Agile. E fondamentalmente, uno dei grandi principi chiave di Agile è che si costruisce la cosa giusta al momento giusto. E ti concentri sull'acquisizione di valore il più rapidamente possibile. Quindi vuoi costruire il prodotto minimo praticabile. Ora, ciò significa che non hai necessariamente qualcosa che è completamente ricco di funzionalità a quel punto. Ma ti offre una piattaforma in cui puoi quindi iniziare a testarlo, sai, stai effettivamente ottenendo le cose che vuoi da quello? I tuoi utenti stanno rispondendo? Nel modo in cui ti aspetti che chiunque abbia lavorato all'interno di UX o web dev saprà che molto spesso riceverà richieste dai clienti perché pensano che siano i loro clienti, ma in realtà lo vogliono davvero? Quindi questa è un'altra buona domanda da porre è, una volta che hai pensato a quella visione a lungo termine, le persone che utilizzeranno il sito web sappiamo che qualcuno lo usa o dobbiamo testare per vedere se vogliono per usarlo? E poi, una volta che hai fatto quel test, possiamo capire cosa non avremmo dovuto chiederlo e se dovremmo fare marcia indietro e investire effettivamente altrove.

DV: Quindi sembra come ricapitolare questi pensieri e mi è piaciuta la tua idea di guardare al costo totale di proprietà a lungo termine, sai, penso che molte volte i team pensino che anche le persone che conosci, citino, ordinino servizi dal i team pensano a quante ore o settimane o spread o punti o qualunque cosa sia questa cosa che sta per costruire. Ma poi, sai, devi tenere conto del fatto che sai, quante ore o settimane o spread o punti ci vorranno per mantenere e quindi utilizzare quel saldo contro il valore che stai risparmiando mantenendo quell'attività. Ovviamente sei un buon consiglio. Ma poi stai anche pensando, beh, c'è qualcosa che posso fare per testare questo per vedere se le mie ipotesi sono corrette? Suona preciso?

JM: Sì. Assolutamente. Assolutamente. E l'unico aspetto che non abbiamo toccato è quello di cui abbiamo parlato un po' prima, che riguarda l'architettura, c'è un modo migliore in cui possiamo strutturarlo per renderlo migliore e quel tempo per programmare oggetti e cose del genere che probabilmente toccherò un po' più tardi.

DV: Sì, anche le considerazioni architettoniche, come se avessi scritto come eri, c'è un modo in cui possiamo cambiare le specifiche? È come nella mia formazione o nei miei colloqui con gli stakeholder che dico spesso che sai, le specifiche per alloggiare nel modo giusto? Chiedi ciò di cui hai veramente bisogno per alloggiare. E quindi chiedere a quelli mentiranno e saranno davvero necessari e che dire di questo? Sono state domande che ho trovato molto critiche. Quindi sembra che questa sia una parte fondamentale di come stai pensando a questo.

JM: Sì, perché ogni minuto in cui quel sito è in fase di sviluppo è un minuto in cui non ottiene valore di fronte ai clienti. E questo è il modo più semplice di pensarci. Vuoi essere lanciato il più velocemente possibile. E poi testare, monitorare, iterare, imparare, sai, vedere dove vai da lì, ma solo perché lo stai facendo sulla base di dati effettivi piuttosto che su ciò che pensi sia giusto. Perché molto spesso non sono la stessa cosa.

DV: Sì, mi piace quel punto. Ogni minuto. È in sviluppo, non è un minuto che non lo stai usando per capirlo e dirò collegamenti a una sorta di legami con un altro mantra che ho e gestione del progetto e gestione degli stakeholder, che sono le due parole migliori e ottenere un progetto sulla nostra faccia da scrivere. Come puoi parlare sì, lo adoro quando ho a che fare con gli stakeholder, o quando ho uno stakeholder, è una parte potente e potente. Va bene, d'accordo. Parliamo ora di cosa possono fare i team per ridurre il debito tecnologico. Ma prima di farlo, faremo la nostra ultima pausa. È ora di inserirsi in un'interruzione pubblicitaria. Resta sintonizzato per più pressanti questo in un momento. Tutti bentornati a premere questo podcast della community di WordPress su W EMR. Questo è il tuo ospite David mobile Paul, sto parlando di evitare di ammazzare il debito tecnologico con John Martin di come John appena prima della pausa, abbiamo parlato un po' della tua formula che vale la pena Mi sono davvero piaciute le tue nozioni sulla riduzione Specifiche. E pensando al TCO e, e in un certo senso, adottando un approccio di test iterativo. Ma analizziamo ora cosa possono effettivamente fare i team per ridurre il loro debito tecnologico e le build di WordPress. Quali sono alcune delle tue tecniche preferite per ridurre il debito tecnologico?

JM: Quindi ci sono tutti i tipi di tecniche tecniche che puoi usare e conosci alcune di esse con cui saresti familiare, quindi non lo farai, ma in realtà il punto di partenza per me è un approccio molto più morbido al parlare ai tuoi clienti. E devi ricordare che alla fine i tuoi clienti sono questi marchi che vengono da noi perché siamo gli esperti. Hanno bisogno dei nostri consigli ed è abbastanza facile cadere nella trappola che, sai, siamo lì solo per fare quello che vogliono, quello che siamo lì per fare quello che vogliono che facciamo, ma in realtà, siamo lì sfidare ciò che vogliono fare e cercare di migliorarlo. Quindi la prima cosa che puoi fare è parlarne con loro e spiegare bene, se lo facciamo questo sarà l'effetto a lungo termine. Sai, ci vorrà un giorno in più di test. Ogni volta che eseguiamo una versione, verranno aggiunte un paio di ore o due ogni volta che avremo bisogno di mantenere il sito Web e aggiornare tutti i plug-in o qualunque cosa sia. Ma aumentando questa consapevolezza, stiamo avendo quelle conversazioni con loro. Puoi convincere il cliente a far parte di quella discussione. E poi alla fine diventano parte del problem solving con va bene, dobbiamo educare i nostri clienti tutto il tempo, semplicemente perché non sanno alcune cose che facciamo. Se lo facessero, non diventerebbero strumenti in primo luogo. Quindi, in realtà, questo è il punto di partenza. Pensa di ricordarlo oltre a semplificare le cose. Ancora una volta, le persone non sono necessariamente tecniche come noi. Quindi usa le analogie per parlarne. Trovo sempre che le case siano una grande energia. Tutti vivono in casa. La maggior parte delle persone ha una certa esperienza nel fare qualche tipo di miglioramento della casa. Quindi è stato abbastanza facile usare quell'energia per sistemare le cose. Quindi questo è il tipo del primo punto in realtà è quello di ottenere un cliente o scorrere quelle conversazioni. La prossima cosa che abbiamo toccato in precedenza è stata quella di avere quella visione a lungo termine o il costo totale di proprietà. E porsi queste domande e mettere in discussione ogni richiesta di funzionalità. Ma essendo un po' più tecnico e come lo faresti sul lavoro. Cose semplici che usi gli standard di WordPress che conosci, ci sono standard che ci sono. Esistono per una ragione. Ora, ci aiuteranno lo sviluppatore e forse lavorerai su un progetto che metti giù per un anno o due e poi ci torni. Devi rinfrescare la tua memoria e tornare al punto in cui eri quando l'hai costruito per la prima volta usando gli standard ti aiuterà. Aiuteranno anche altre persone. Quindi, se non eri all'interno del team, significa che hai questo linguaggio comune da cui tutti possono operare, il che è davvero molto utile in termini di efficienza e aiuto con la documentazione e tutti questi tipi di cose. Quindi è una specie di modo più morbido per ridurre il tuo debito tecnico avendo standard che chiunque può lavorare. Ti aiuta anche a sapere che potrebbe arrivare il momento in cui altri sviluppatori WordPress stanno lavorando a quel progetto. E li aiuta a pensarlo come un modo per ripagare la comunità e rendere più facile per i tuoi colleghi sviluppatori. Quindi questo è un, sai, un buon punto intorno a un tipo di standard e renderlo facile per te stesso e per gli altri. Il prossimo è più di grande. Grande codice dell'industria, affettuosamente conosciuto come zio Bob, che ha scritto un libro meraviglioso intitolato The clean coder molti molti anni fa. Consiglio vivamente a tutti gli sviluppatori di leggere quel libro perché non l'hanno letto. In effetti, ho reso la lettura obbligatoria per un team di sviluppo, per chiunque si sia unito al team, principalmente perché ha un approccio così buono nei suoi confronti parla di unit test, tutto questo genere di cose, ma fondamentalmente, molto è come scrivere il codice in un modo che lo renda flessibile in modo da poter iterare e modificare molto rapidamente e aggiungere bit extra. Uno dei grandi punti di cui parla è il refactoring spesso, e questa è la cosa principale da prendere da esso è che scrivi un pezzo di codice che non significa necessariamente che quel pezzo di codice sia finito. Ci sono cose che puoi fare per ottimizzarlo per renderlo più portabile per renderlo più modulare o per migliorare un test, qualunque cosa sia necessario fare per dedicare tempo al refactoring del codice. Può essere davvero, davvero difficile da fare quando ci sei contro o sai, forse è un lasso di tempo per un budget. Ma alla fine, questo è il tipo di cosa che ti impedirà di accumulare debiti tecnici e in realtà, di solito è così che vedo che viene forzato, ma come scadenza del progetto in atto, devi rispettare quella scadenza. Assolutamente. Devi colpirlo, ma è meglio flettere l'ambito piuttosto che scrivere codice errato che poi farai,

DV: Immagino, istruisci anche quei clienti su questo, perché come se non avessi mai incontrato uno sviluppatore che non volesse refactoring. Codice. È sempre la linea temporale. È contro. Uhm, ok, quindi ecco l'ultimo piccolo che sono solo curioso di sapere se ti piacciamo, se pensi a cose come scaricare e utilizzare plug-in standard è un altro modo per evitare la tecnologia o un altro modo per evitare il debito tecnologico. È anche questo nella tua lista?

JM: Sì. 100% Quindi è un buon modo, ma in realtà è un buon modo per fare entrambe le cose, puoi evitare il debito tecnico. Ma puoi anche e questo è lo sai, WordPress è una forma di BMC. È così attivo, allo stesso modo, che può anche essere il suo peggior nemico. C'è un plugin che fa tutto. E ci sono anche molti plugin che sono stati creati per uno scopo molto specifico, ma non necessariamente corrispondono ai tuoi plugin. Quindi l'ho visto in particolare con alcuni degli sviluppatori a cui piace costruire siti utilizzando plug-in e un approccio più punta e clicca verso le cose piuttosto che codificarlo da zero. Le persone tendono a lanciare plug-in alle cose. Abbiamo lavorato con siti Web che hanno avuto oltre 100 plug-in e molti di essi non vengono più mantenuti. Ci sono problemi di sicurezza dappertutto. Prova a fare il tasso di rilascio. Trascorri letteralmente quattro giorni a testarlo quando avresti potuto farlo in un paio d'ore. Quindi i plugin So possono essere buoni o cattivi. La presa giusta al momento giusto è stata una cosa meravigliosa, meravigliosa. I maggiori punti di forza di WordPress, ma il plug-in sbagliato al momento sbagliato può anche essere gravemente dannoso. E in realtà può essere una di quelle maggiori fonti di capitale che

DV: Di sicuro ho avuto un progetto del genere. Bene, John, questo è stato incredibilmente perspicace. Grazie mille per esserti unito a noi oggi.

JM : Il mio piacere.

DV: Fantastico. Se vuoi saperne di più su cosa Jon puoi visitare hallam.co.uk. Grazie a tutti per aver ascoltato i podcast della community di WordPress su WMR. Ancora una volta, questo è stato il tuo ospite David Vogelpohl. Supporto la community di WordPress come parte del mio ruolo in WP Engine e amo portare il meglio della community qui su Press This.