Pressione isto: Evitando dívidas tecnológicas que matam o tempo nas compilações do WordPress com Jon Martin

Bem-vindo ao Press This, o podcast da comunidade WordPress do WMR. Aqui, o anfitrião David Vogelpohl se senta com convidados de toda a comunidade para falar sobre os maiores problemas enfrentados pelos desenvolvedores do WordPress. Segue a transcrição da gravação original.

Desenvolvido por RedCircle

David Vogelpohl: Olá a todos e bem-vindos ao Press This, os podcasts da comunidade WordPress no WMR. Este é o seu anfitrião, David Vogelpohl, eu apoio a comunidade WordPress através da minha função no WP Engine, e adoro trazer o melhor da comunidade para você ouvir todas as semanas na imprensa como um lembrete, você pode me encontrar no Twitter @wpdavidv , ou você pode se inscrever para pressionar isso no iTunes, iHeartRadio, Spotify ou baixar os episódios mais recentes em wmr.fm. Neste episódio, falaremos sobre um dos meus tópicos favoritos, que é evitar perder tempo matando dívidas de tecnologia nas compilações do WordPress. E juntando-nos a esta conversa, gostaria de dar as boas-vindas a Jon Martin. Jon, bem-vindo ao Press This.

Jon Martin: Muito obrigado, é bom estar aqui.

DV: Eu, você sabe, eu pratico a pronúncia de Hallum antes do show, mas é claro que eu errei logo no começo, John, desculpe por isso. Impressionante, então, para aqueles que estão ouvindo John, compartilhará seus pensamentos sobre o impacto da dívida de tecnologia para as equipes de desenvolvimento do WordPress, como o que significa ter dívida de tecnologia e como isso afeta você? Como você pode pensar em reduzir sua dívida de tecnologia em cada projeto. E então por que você tem a responsabilidade de compartilhar as considerações de dívida de tecnologia com seus clientes

JM: se você estiver trabalhando em uma agência freelancer. Então eu amo matar a dívida de tecnologia. Adoro eliminá-lo é um dos meus temas favoritos.

DV: Vamos analisar os pensamentos de John sobre o assunto, mas antes de começarmos, John, vou fazer a mesma pergunta que fiz a todos os convidados. Conte-me brevemente sobre sua história de origem do WordPress. Quando foi a primeira vez que você usou o WordPress

JM: então eu teria sido no início de 2010 não tinha certeza da expressão correta para esse período de tempo. Então, na verdade, eu comecei e fui CEO de como começamos uma agência em 2008. E na época, o WordPress ainda era uma plataforma de blogs. Estávamos construindo sites com muito conteúdo rico. Então é um palavrão, mas nós usamos Joomla na época. Mas então em vez de

DV: Joomla é uma palavra suja. Eu gosto de todos os CMS de código aberto pessoalmente.

JM: Sim, gostaríamos de dizer que é um grande projeto. Eu acho que o principal para nós é que, com o tempo, o Joomla foi realmente muito forte quando o WordPress lançou o suporte ao site de postagem personalizado. Foi quando as coisas realmente mudaram no WordPress para mim, que o elevou de como era conhecido como uma plataforma de blogs para um CMS completo que você pode fazer todos os tipos de sites, seja para você sabe, muito pequeno uma empresa de uma pessoa ou freelancer ou qualquer outra coisa, até sites complexos e de nível empresarial massivo. E eu acho que realmente, realmente para mim, essa foi uma decisão matadora da parte deles, porque é parte da razão pela qual o WordPress é tão popular agora. Então sim, então foi aí que ela começou a usar aqui. Sasha a história antes disso realmente sou eu e agora CEO de como estávamos em uma banda juntos. E nós temos essa ideia brilhante de pensar, Bem, você sabe, é incrível mais tipo de tempo igual na estrada e é muito difícil conseguir tempo fora dos meus empregos atuais. Então pensamos, quer saber, vamos começar uma agência e nos tornarmos desenvolvedores da web, porque isso realmente ajudará a recuperar todo esse tempo naquela época. Foi uma ótima decisão. Estou realmente muito satisfeito com isso, mas ele também é certamente uma decisão ingênua, porque pensar que trabalhar para si mesmo lhe dá mais tempo foi definitivamente um erro que acho que reconhecemos um pouco mais tarde. E antes desse ponto, você sabe, eu sabia um pouco sobre SQL e venho construindo computadores desde bem, na verdade desde que placas gráficas dão suporte a cores. Então, para qualquer outra pessoa que saiba o que é CGA, isso ajudará você a saber quantos anos eu tenho. Mas sim, realmente, foi quando os CPTs foram lançados. Essa gordura mudou tudo para nós. E começamos a usar o WordPress praticamente da noite para o dia, na verdade, que se tornou nosso CMS escolhido e não olhamos para trás desde então e, você sabe,

DV: de todas as pessoas que eu fiz essa pergunta para você, muito poucas realmente perceberam como os tipos de postagens personalizadas eram em relação à história de origem do WordPress. E é engraçado. Eu tenho uma história parecida. Eu fundei uma agência em 2010. Então, um pouco depois de vocês, mas quando o post personalizado já entrou. Começamos a construir com o Joomla e mudamos para o WordPress por razões semelhantes, mas foram esses tipos de postagem personalizados e meta personalizado campos que eu concordo e na verdade apresentei desta forma vários formatos é que foi nesse momento que o WordPress realmente se tornou um verdadeiro CMS. Um ano depois que o WooCommerce surgiu, o WP Engine surgiu, muitas outras marcas do espaço WordPress, é um momento tão transformador. É interessante ouvir você tipo de referência que é a raiz da sua história de origem. Eles estavam me contando, no entanto, sobre como hum, e você sabe, o momento de fundação lá, se você quiser, mas você poderia me contar um pouco sobre como hum, e o que você faz?

JM : Sim, claro. Então, na verdade, descobrimos que aquela agência não era como era como mais tarde nos dirigimos. Está bem, está bem. Bem, a principal razão para isso é porque, você sabe, naqueles tempos antigos, havia uma diferença muito distinta entre, você sabe, nós construímos sites versus fazemos SEO e todo esse tipo de coisa. E não eram realmente muitos ao redor do mundo abordagem integrada e realmente pensando em coisas como experiência do usuário, e como isso funciona com SEO e desenvolvimento, todo esse tipo de coisa. Então, foi por isso que acabamos mais tarde nos fundindo, com Allen Milan há cerca de 20 anos e nosso fundador se estabeleceu praticamente no início, quando o SEO começou a se tornar uma coisa. Então, sim, fundimos as duas agências. Seis, sete anos atrás, talvez um pouco mais. Minha memória para dados não é boa, devo admitir. E então E então realmente, sim, essa se tornou nossa abordagem é essa abordagem totalmente integrada sobre misturar todas essas diferentes disciplinas para ajudar as pessoas a ver a linha? Então agora fazemos PPC, SEO, relações públicas digitais, obviamente, web design e há extensões de marca, estratégia digital e todo esse tipo de coisa, todas essas disciplinas que você realmente precisa para ter uma boa presença digital forte nos dias de hoje. Qual é o seu papel lá, a empresa? Então, meu, meu cargo era diretor técnico. Então, eu vou ser honesto, realmente não cobriu tudo o que eu faço. Eu dirijo a equipe de desenvolvimento por um longo período de tempo. Então tudo o que o WordPress será estava sob minha direção. Tenho o prazer de dizer que temos desenvolvedores muito melhores na equipe do que Julio e eu já trabalhamos quando começamos, e é por isso que estamos nos saindo muito melhor hoje em dia. E nós entendemos as coisas um pouco mais. Então eu administro a equipe de desenvolvimento por um longo período de tempo mais recentemente em uma equipe de custo de dados também. Então isso significa que eu posso brincar com aprendizado de máquina, Python e Bartek e outros estão jogando, embora eu tenha que imaginar tudo isso jogando.

DV: Fazer clientes separados legais vai resultar em alguma dívida de tecnologia ao longo do caminho. E estou curioso para saber como você pensa, quais são os tipos comuns de dívida de tecnologia e talvez específicos do WordPress. Isso por um minuto, mas tipo, como você pensa sobre isso enquanto pensa, você sabe, como e como vocês gerenciam sua dívida de tecnologia, como se você a tivesse bloqueado em tipos com o WordPress construído?

JM: Sim, temos. Quero dizer, não. Não necessariamente. Estamos fazendo um tipo de linguagem que não necessariamente categorizamos as coisas ou passamos por um processo distrital para categorizar, mas, na verdade, elas se enquadram em três categorias diferentes. Um deles é quando você cria um código ruim em cima de códigos existentes, e isso pode ser porque você comete alguns erros no passado que podem ser um problema de sites do Heritage e de outra pessoa, seja qual for o motivo, então esse é o espécie de primeiro balde. A segunda é a construção de código que não é necessário, e talvez não seja necessário agora. Você sabe, tenho certeza de que todos nós já recebemos solicitações de recursos de clientes e marcas com as quais trabalhamos, onde eles realmente desejam uma coisa específica, mas na verdade pode não ser a coisa certa, em termos de obter valor real para os clientes. E então o terceiro, que é o maior que vemos, na verdade, está construindo recursos que realmente deveriam estar em uma plataforma diferente. Então, entendendo esse tipo de peça arquitetônica sobre tudo bem, quais são as diferentes partes que estamos conectando aqui é um CRM aqui é o site, que fundamentalmente é sobre o marketing do negócio. Aqui está a sua plataforma de atendimento de pedidos, tudo isso diferente.

D V: Deixe-me perguntar a você, deixe-me fazer uma pergunta fundamental aqui, como você meio que listou os três tipos de sons, como esses são os três tipos de dívida tecnológica que você deseja se livrar de escrever código ruim em código ruim código, não são necessários recursos que podem ser feitos em outra plataforma. Tipo, não existe um quarto balde como recursos que você deseja que sejam valiosos e, portanto, a tecnologia que talvez seja boa nesse caso? É justo dizer isso? Isso é um quarto balde.

JM: Sim. 100% quer dizer, nem toda dívida técnica é ruim. Você tem que aceitar que praticamente qualquer recurso que você vai construir irá acumular algum tipo de dívida técnica e você tem que fazer uma ligação sobre se essa dívida técnica é boa ou não. Alguns são bons, outros são ruins e realmente dependem dessa palavra-chave que eu disse antes sobre valor. Você vai conseguir o valor que você precisa para essa coisa? Mais importante, é o cliente, o cliente final, não seu cliente, mas eles são seus clientes? Eles vão receber o valor por isso? Isso geralmente é uma boa luz de orientação para aceitar essa dívida técnica.

DV: Sim, eu quero mergulhar fundo em você sabe, como você pensa sobre essa citação, vale a pena a fórmula para quando está tudo bem aceitar ou não, mas é bom pensar em ter uma boa compreensão de como você pensa os diferentes grupos de tipos de dívida de tecnologia e, particularmente, aqueles que você pode querer otimizar para remover. O que eu gostaria de fazer a seguir, porém, é entender como se havia algo que o levou ao limite para se concentrar nesta área, mas vamos fazer nossa primeira pausa e vamos volto logo. Hora de se conectar a um intervalo comercial. Fique atento para mais urgente isso apenas um momento. Olá pessoal. Bem-vindo de volta para pressionar este podcasts da comunidade WordPress no W EMR Este é o seu anfitrião, David Vogel. Paulo. Estou entrevistando John Martin sobre perder tempo matando mortos de tecnologia. John, logo antes do intervalo, você estava explicando que a maneira como você pensa nos três tipos de dívida de tecnologia que você pode querer eliminar é construir código ruim em código ruim, criando código que não é necessário para o sucesso do site em que você está trabalhando. E então talvez construir código para recursos que podem ser melhor servidos em outra plataforma. Antes de entrarmos na fórmula da cotação vale a pena, no entanto. Eu estava me perguntando, havia um tempo específico que eu não sei e sua jornada é uma instância específica de dívida de tecnologia que esse tipo de superfície para você é uma área de foco principal de como?

JM: Sim, absolutamente. Há um projeto de referência real que começou a me fazer pensar sobre isso cerca de quatro ou cinco anos atrás. Já vi muitos outros casos. Para as empresas acumulam tempo, o tempo todo, não apenas através do WordPress através de todos os tipos de coisas, na verdade, as empresas também acumulam através de seus processos operacionais. Se você tem que ser uma coisa técnica onde você cria aquele deck. Uma, a história que realmente se destaca na minha mente mais do que qualquer um é o cliente, trabalhamos com uma empresa relativamente pequena, fizemos muito trabalho de mídia paga para eles. Vendendo essencialmente vendendo coisas online. Era um negócio de comércio eletrônico. E eles tinham o tipo tradicional de pedidos por correspondência, mas muito do trabalho deles e estavam tentando direcionar mais tráfego on-line para que não precisassem passar por pedidos por correspondência. ter um site construído para eles é totalmente sob medida. E eles já existem há cerca de 10 anos nesse ponto. Então estava ficando muito velho começando a rastejar um pouco. Você sabe, padrões e seguir em frente. A tecnologia mudou, é hora de repensar um pouco. Então o cliente sentou-se conosco, eles começaram a debriefing todas as coisas diferentes que eles fizeram no site. E ficou muito claro muito rapidamente para mim que havia todos os tipos de lógica de negócios e coisas operacionais de negócios que foram incorporadas ao site. E essa foi a lógica que leva aos pedidos e é bastante específica para a forma como trabalham os fornecedores. Portanto, não entrarei em detalhes, mas tenho um acordo bastante complexo entre os fornecedores e como eles atendem aos pedidos e se foi enviado para a loja antes de enviar todo esse tipo de coisa. Então é tudo bem complicado. Agora, o proprietário da empresa e o anterior sobre como eles funcionam, eventualmente, construíram um sistema que praticamente gerenciava tudo isso era um sistema muito, muito bom na época e genuinamente ajudou esse negócio a crescer massivamente. Agora, o que eles realmente não pensaram é que todos os sites eventualmente têm um prazo de validade que eles se tornarão em algum momento, assim como qualquer software e no mundo do marketing. Essa vida útil é realmente relativamente curta em comparação com, você sabe, por exemplo, se você investir em um CRM como uma empresa normalmente terá isso por algum tempo, agora são cerca de 10 anos, se não mais sites. De um modo geral, entre dois a cinco anos, descobrimos que a maioria, pelo menos, as grandes marcas tendem a se reconstruir a cada três anos ou mais. Então, o problema era que eles construíram toda essa lógica complicada no site existente e tiveram que reconstruir o site inteiro. E de repente você tem que reconstruir toda essa lógica de negócios também. Agora, nós custeamos o projeto e basicamente acabou sendo cerca de metade do faturamento anual na base apenas para reconstruir o que já tínhamos. E isso realmente começou a me fazer pensar sobre isso, bem, ok, se eles abordam o problema de uma maneira diferente originalmente, por exemplo, vamos pensar nas diferentes coisas que estamos tentando alcançar em um site. Você sabe, isso é do marketing era isso para vender produtos. Isso é para atendimento de pedidos, isso é melhor para gerenciar meu processo de negócios com suprimentos todas essas coisas, e pensei um pouco mais de maneira modular sobre isso, então teria sido uma situação muito diferente para essa cliente, que ela estava lá . Foi um problema real para eles porque eles tinham um site que era essencialmente de onde eles estavam ganhando dinheiro. Estava rangendo bastante porque é bem antigo. Mas, ao mesmo tempo, custaria muito reconstruir todo o site e tornaria o projeto muito, muito complicado. Conseguimos encontrar um trabalho bastante inteligente, mas também não muito bom, para tentar usar o que eles já tinham e integrá-lo, mas não podemos citar, mas você sabe, acabou sendo muito mais doloroso, muito mais lento e muito mais caro do que precisava ser. Se essa arquitetura foi pensada originalmente.

DV: Tenho tantos projetos que quero esquecer isso. Eram assim, e eu posso imaginar agora estou me levando de volta no tempo. Então, para mim, isso soa bem claro, é uma lição muito importante, eu acho, para pensar sobre o tipo de custo para o negócio em relação à refatoração que você está planejando. E para mim, parecia que a resposta clara era que você precisava arquitetá-lo de maneira diferente. E esse talvez seja um caminho mais claro se você quiser gostar do que deve fazer. Mas acho que muitas equipes quando pensam em dívida de tecnologia, é como se pensassem, Ok, bem, seria legal fazer isso, mas vale a pena?

JM: Vale a pena manter essa coisa ao longo do tempo? Então, estou curioso para saber como você pensa sobre essa fórmula

D V: quando, tipo, quando está certo introduzir dívida de tecnologia? E quanto exatamente como você pensa sobre essa fórmula?

JM: Sim, você tocou em um ponto muito importante, você sabe, você pensa sobre a natureza dos desenvolvedores, os desenvolvedores entram nisso porque adoram fazer coisas legais. E isso é, você sabe, uma grande parte da nossa motivação é aprender a fazer coisas novas, novas tecnologias, você sabe, novos frameworks JavaScript, seja lá o que for, e isso naturalmente nos dá a motivação para construir coisas legais, mas não necessariamente pensamos a longo prazo sobre isso, você sabe, ainda vamos mantê-lo. Você sabe, minha esposa adoraria ter uma banheira de hidromassagem em minha casa, mas eu sei que alguém vai limpar isso e eu vou ser honesto, eu não acredito que ninguém que limpa isso, é esse tipo de pensamento de qualquer maneira. Então, é uma pergunta muito, muito, muito boa para se pensar, se realmente vale a pena em primeiro lugar e se detalharmos um pouco, há algumas coisas diferentes em que você poderia estar pensando, primeiro de tudo, pensando muito prazo, qual é o custo total de propriedade e construir essa coisa de testá-lo e mantê-lo, e depois pesar isso em relação ao valor que obtemos? Por exemplo, pode haver uma maneira muito simples de resolver esse problema. usando planilhas ou usando coisas arquitetônicas um pouco diferentes, onde talvez alguém internamente na empresa gerencie isso por um curto período de tempo. E seria mais barato fazer isso e mais eficaz fazer isso do que construir esse recurso realmente complicado. Mas quando você realmente olha para o custo total de propriedade, vai custar mais do que custaria para alguém gastar algumas horas por semana para fazer uma coisa em particular. Não me entenda mal. Eu sou um grande crente na automação. tecnologias devem automatizar o máximo possível para evitar esse tipo de administrador, mas

DV: você está se inscrevendo e usa abordagens como este manual para tentar algo antes de codificá-lo para ter certeza de que o valor estará lá. Quero dizer, eu tenho a ideia de simplificar esse fator, como, podemos fazer isso manualmente? Apenas curioso se você já abordou isso de uma perspectiva de teste para gostar, ver se o retorno final vale a pena?

JM: Sim. 100%. Então, eu acredito muito na metodologia Agile. E fundamentalmente, um dos grandes princípios do Agile é que você constrói a coisa certa na hora certa. E você se concentra em ganhar valor o mais rápido possível. Então você quer construir o produto mínimo viável. Agora, isso significa que você não tem necessariamente algo que seja totalmente rico em recursos nesse ponto. Mas dá a você uma plataforma onde você pode começar a testá-lo, você sabe, você está realmente conseguindo as coisas que deseja com isso? Seus usuários estão respondendo a isso? Da maneira que você espera que qualquer pessoa que tenha trabalhado em UX ou web dev saiba que muitas vezes receberá solicitações de clientes porque eles pensam que seus clientes, mas na verdade eles realmente querem isso? Então, essa é outra pergunta muito boa a ser feita, uma vez que você tenha pensado sobre essa visão de longo prazo, as pessoas que vão usar o site, sabemos que alguém pode usá-lo ou precisamos testar para ver se eles querem para usá-lo? E então, uma vez que você tenha feito esse teste, podemos descobrir o que não deveríamos ter pedido e se deveríamos recuar e realmente colocar nosso investimento em outro lugar.

DV: Então parece recapitular esses pensamentos e eu gostei da sua ideia de olhar para o custo total de propriedade a longo prazo, eu acho que muitas vezes as equipes pensam que até mesmo as pessoas que você conhece, citam, solicitam serviços do as equipes pensam em quantas horas ou semanas ou spreads ou pontos ou o que quer que essa coisa esteja passando para construir. Mas então, você sabe, você precisa levar em conta que você sabe quantas horas ou semanas ou spreads ou pontos serão necessários para manter e então usar esse saldo contra o valor que você está obtendo ao manter aquela atividade. Você é obviamente um bom conselho. Mas então você também está pensando como, bem, há algo que eu possa fazer para testar isso para ver se minhas suposições estão corretas? Isso soa preciso?

JM: Sim. Absolutamente. Absolutamente. E a única parte que não tocamos é sobre a qual falamos um pouco antes, que é sobre arquitetura, existe uma maneira melhor de estruturar isso para torná-lo melhor e esse tempo para programação de objetos e outras coisas que eu provavelmente vou tocar um pouco mais tarde.

DV: Sim, as considerações arquitetônicas também, como eu meio que escrevi como você era, existe uma maneira de mudar as especificações? É como no meu treinamento de stakeholders ou palestras que costumo dizer que você sabe, especificações para apresentar certo? Peça o que você realmente precisa para alojar. E então perguntar isso vai mentir e ser realmente necessário e o que dizer disso? As perguntas foram consideradas muito críticas. Então parece que essa é uma parte fundamental de como você está pensando sobre isso.

JM: Sim, porque cada minuto que esse site está em desenvolvimento é um minuto que não está gerando valor para os clientes. E essa é a maneira fácil de pensar sobre isso. Você quer ser lançado o mais rápido possível. E então teste, monitore, itere, aprenda, você sabe, veja onde você vai a partir daí, mas apenas porque você está fazendo isso com base em dados reais e não no que você acha que é certo. Porque muitas vezes eles não são os mesmos.

DV: Sim, eu amo esse ponto. A cada minuto. Está em desenvolvimento, não é como um minuto que você não está usando, descubra e eu direi laços de volta para outro mantra que eu tenho e gerenciamento de projetos e gerenciamento de partes interessadas, que são as duas melhores palavras e recebendo um projeto em nosso rosto para escrever. Como você pode falar sim, eu amo isso quando estou lidando com partes interessadas, ou quando tenho uma parte interessada é uma parte poderosa e poderosa. OK fixe. Hum, vamos falar a seguir sobre como as equipes podem fazer para reduzir a dívida de tecnologia. Mas antes de fazermos isso, faremos nossa última pausa. Hora de se conectar a um intervalo comercial. Fique atento para mais informações sobre isso em apenas um momento. Sejam todos bem-vindos a pressionar este podcast da comunidade WordPress no W EMR. Este é o seu anfitrião David mobile Paul, estou falando sobre como evitar o tempo matando dívidas de tecnologia com John Martin de como John logo antes do intervalo, conversamos um pouco sobre sua fórmula de valor a pena Eu realmente gostei de suas noções sobre redução especificações. E pensando no TCO e meio que adotando uma abordagem de teste iterativa. Mas vamos nos aprofundar agora no que as equipes podem realmente fazer para reduzir sua dívida tecnológica e as compilações do WordPress. Quais são algumas das suas técnicas favoritas para reduzir a dívida de tecnologia?

JM: Então, há todos os tipos de técnicas técnicas que você pode usar e você conhece algumas delas com as quais você estaria familiarizado, mas na verdade o ponto de partida para mim é uma abordagem muito mais suave para falar aos seus clientes. E você deve se lembrar que, em última análise, seus clientes são essas marcas que vêm até nós porque somos os especialistas. Eles precisam de nosso conselho e é muito fácil cair na armadilha de que, você sabe, estamos lá apenas para fazer o que eles querem, o que estamos lá para fazer o que eles querem que façamos, mas, na verdade, estamos lá desafiar o que eles querem fazer e tentar melhorá-lo. Então, a primeira coisa que você pode fazer é conversar com eles sobre isso e explicar tudo bem, se fizermos isso, esse será o efeito a longo prazo. Você sabe, vai nos levar um dia extra de testes. Toda vez que fazemos um lançamento, ele adiciona algumas horas ou duas sempre que precisamos manter o site e atualizar todos os plugins ou o que for. Mas ao aumentar essa conscientização, estamos tendo essas conversas com eles. Você pode fazer com que o cliente faça parte dessa discussão. E então, eventualmente, eles se tornam parte da solução de problemas, bem, temos que educar nossos clientes o tempo todo, simplesmente porque eles não sabem algumas coisas que fazemos. Se o fizessem, eles não se tornariam ferramentas em primeiro lugar. Então, na verdade, esse é o ponto de partida. Ele pensa lembrar disso, além de simplificar as coisas. Novamente, as pessoas não são necessariamente tão técnicas quanto nós. Então use analogias para falar sobre isso. Eu sempre acho que as casas são uma grande energia. Todo mundo mora na casa. A maioria das pessoas tem alguma experiência em fazer algum tipo de melhoria da casa. Então foi muito fácil usar essa energia para consertar as coisas. Então esse é o tipo de primeiro ponto realmente é conseguir um cliente ou alternar essas conversas. A próxima coisa que abordamos antes era ter essa visão de longo prazo ou o custo total de propriedade. E faça a si mesmo essas perguntas e questione todas as solicitações de recursos. Mas sendo um pouco mais técnico e como você faria isso no trabalho. Coisas simples que você usa padrões do WordPress você conhece, existem padrões que existem. Eles existem por uma razão. Agora, eles nos ajudarão, o desenvolvedor, e talvez você trabalhe em um projeto que você colocou por um ano ou dois e depois volte a ele. Você precisa refrescar sua memória e voltar para onde estava quando o construiu usando padrões. Eles também ajudarão outras pessoas. Então, se você não estava na equipe, significa que você tem essa linguagem comum que todos podem operar, o que é muito, muito útil em termos de eficiência e ajuda com documentação e todos esses tipos de coisas. Então essa é uma maneira mais suave de reduzir sua dívida técnica por ter padrões que qualquer um pode trabalhar. Também ajuda você a saber que pode chegar o momento em que alguns outros desenvolvedores do WordPress estão trabalhando nesse projeto. E isso os ajuda a pensar nisso como uma forma de retribuir a comunidade e facilitar a vida de seus colegas desenvolvedores. Então, isso é, você sabe, um bom ponto em torno de padrões e tornar mais fácil para você e para os outros. O próximo é mais sobre grande. Grande código da indústria, carinhosamente conhecido como Tio Bob, que escreveu um livro maravilhoso chamado The clean coder muitos anos atrás. Eu recomendo que qualquer desenvolvedor leia esse livro porque eles não o leram. Na verdade, eu o tornei leitura obrigatória para uma equipe de desenvolvimento, para qualquer pessoa que se juntou à equipe, principalmente porque ele tem uma abordagem tão boa para falar sobre testes de unidade, todo esse tipo de coisa, mas fundamentalmente, muito disso é sobre como você escreve código de uma maneira que o torna flexível para que você possa iterar e alterar muito rapidamente e adicionar bits extras a ele. Um dos grandes pontos sobre os quais ele fala é sobre refatorar frequentemente, e isso é a principal coisa a se tirar disso é que você escreve um pedaço de código que não significa necessariamente que aquele pedaço de código está terminado. Há coisas que você pode fazer para otimizá-lo para torná-lo mais portátil para torná-lo mais modular ou ou melhorar um teste, qualquer que seja essa coisa específica que você precise fazer para gastar tempo refatorando código. Pode ser muito, muito difícil de fazer quando você está contra ou você sabe, talvez seja um prazo para um orçamento. Mas, no final das contas, esse é o tipo de coisa que impedirá você de acumular dívida técnica e, na verdade, geralmente é assim que vejo que isso é forçado, mas como um prazo de projeto em vigor, você precisa cumprir esse prazo. Absolutamente. Você tem que acertar, mas é melhor flexibilizar o escopo do que escrever código ruim para o qual você irá,

DV: Eu acho, eduque esses clientes sobre isso também, porque eu nunca conheci um desenvolvedor que não quisesse refatorar. Código. É sempre a linha do tempo. É contra isso. Hum, ok, então aqui está a última parte, estou curioso se você gosta de nós, se você pensa em coisas como descarregar e usar plugins prontos para uso é outra maneira de ajudar a evitar tecnologia ou outras maneiras de evitar dívidas tecnológicas. Isso também está na sua lista?

JM: Sim. 100% Então, essa é uma boa maneira, mas é uma boa maneira de fazer as duas coisas, na verdade, você pode evitar dívidas técnicas. Mas você também pode e isso é você sabe, WordPress é uma forma de BMC. É tão ativo, igualmente, que também pode ser seu pior inimigo. Existe um plugin que faz tudo. E também existem muitos plugins que foram criados para um propósito muito específico, mas eles não correspondem necessariamente aos seus próprios plugins. Então, eu vi isso particularmente com alguns dos desenvolvedores que gostam de construir sites usando plugins e meio que a abordagem mais apontar e clicar em relação às coisas, em vez de codificá-lo do ponto de vista do zero. As pessoas tendem a jogar plugin nas coisas. Trabalhamos com sites que tiveram mais de 100 plugins e muitos deles não são mais mantidos. Há problemas de segurança por toda parte. Você tenta e faz a taxa de liberação. Você passa literalmente quatro dias testando quando poderia ter feito isso em algumas horas. Então, os plugins podem ser bons ou podem ser ruins. O plug-in certo na hora certa era uma coisa maravilhosa, maravilhosa. Os maiores pontos fortes do WordPress, mas o plug-in errado na hora errada também pode ser gravemente prejudicial. E na verdade pode ser uma daquelas maiores fontes de capital que

DV: Eu tive um projeto assim com certeza. Bem, John, isso foi incrivelmente perspicaz. Muito obrigado por se juntar a nós hoje.

JM : Prazer.

DV: Incrível. Se você quiser saber mais sobre o que Jon pode visitar hallam.co.uk. Obrigado a todos por ouvirem os podcasts da comunidade WordPress no WMR. Mais uma vez, este foi o seu anfitrião David Vogelpohl. Eu apoio a comunidade WordPress como parte da minha função no WP Engine e adoro trazer o melhor da comunidade aqui no Press This.