Presione esto: evitar la deuda tecnológica que mata el tiempo en compilaciones de WordPress con Jon Martin

Bienvenido a Press This, el podcast de la comunidad de WordPress de WMR. Aquí, el anfitrión David Vogelpohl se sienta con invitados de toda la comunidad para hablar sobre los problemas más importantes que enfrentan los desarrolladores de WordPress. La siguiente es una transcripción de la grabación original.

Desarrollado por RedCircle

David Vogelpohl: Hola a todos y bienvenidos a Press This, los podcasts de la comunidad de WordPress en WMR. Este es su anfitrión, David Vogelpohl, apoyo a la comunidad de WordPress a través de mi función en WP Engine, y me encanta traer lo mejor de la comunidad para que escuche cada semana en prensa esto como un recordatorio, puede encontrarme en Twitter @wpdavidv , o puede suscribirse para presionar esto en iTunes, iHeartRadio, Spotify o descargar los últimos episodios en wmr.fm. En este episodio, hablaremos sobre uno de mis temas favoritos, y es evitar perder el tiempo con la deuda tecnológica en las compilaciones de WordPress. Y uniéndonos a esta conversación, me gustaría dar la bienvenida a Jon Martin. Jon, bienvenido a Press This.

Jon Martin: Muchas gracias, es bueno estar aquí.

DV: Sé que practico pronunciar Hallum antes del espectáculo, pero por supuesto lo arruiné desde el principio, John, lo siento. Impresionante, para aquellos que escuchen, John compartirá sus pensamientos sobre el impacto de la deuda tecnológica en los equipos de desarrollo de WordPress, como ¿qué significa tener una deuda tecnológica y cómo te afecta? Cómo puede pensar en reducir su deuda tecnológica en cada proyecto. Y luego, ¿por qué tiene la responsabilidad de compartir las consideraciones de la deuda tecnológica con sus clientes?

JM: si estás trabajando en una agencia independiente. Así que me encanta acabar con la deuda tecnológica. Me encanta eliminarlo es uno de mis temas favoritos.

DV: Vamos a abordar los pensamientos de John sobre el tema, pero antes de comenzar, John, te haré la misma pregunta que le hice a todos los invitados. Cuéntame brevemente sobre tu historia de origen de WordPress. ¿Cuándo fue la primera vez que usaste WordPress?

JM: Entonces, a principios de la década de 2010, no estaba realmente seguro de la expresión correcta para ese período de tiempo. Así que en realidad comencé yo mismo y he sido CEO de cómo comenzamos una agencia en 2008. Y en ese momento, WordPress todavía era en gran medida una plataforma de blogs. Estábamos construyendo sitios web que tenían mucho contenido enriquecido. Así que es una mala palabra, pero usábamos Joomla en ese momento. Pero entonces, en lugar de

DV: Joomla es una mala palabra. Personalmente, me gustan todos los CMS de código abierto.

JM: Sí, nos gustaría decir que es un gran proyecto. Creo que la clave para nosotros es que con el tiempo, donde Joomla fue realmente fuerte cuando WordPress ofreció soporte para sitios de publicaciones personalizadas. Fue entonces cuando las cosas realmente cambiaron en WordPress para mí, lo que lo elevó de lo que se conocía como una plataforma de blogs a ser un CMS completo y adecuado que puede hacer todo tipo de sitios, ya sea para usted, realmente pequeño. un negocio de una sola persona o autónomo o lo que sea, todo el camino hasta sitios web complejos de grado empresarial masivo. Y creo que realmente, realmente para mí, esa fue una gran decisión de su parte porque es parte de la razón por la que WordPress es tan popular ahora. Así que sí, entonces fue cuando empezó a consumir aquí. Sasha la historia anterior que realmente soy yo y ahora CEO de cómo estábamos juntos en una banda. Y tenemos esta brillante idea de pensar, bueno, ¿sabes qué? Es increíble pasar más tiempo en la carretera y es muy difícil sacar tiempo libre de mis trabajos actuales. Así que pensamos, sabes qué, comencemos una agencia y nos convirtamos en desarrolladores web porque eso realmente ayudará a recuperar todo ese tiempo en ese entonces, fue una gran decisión. Estoy realmente muy complacido con eso, pero también es ciertamente una decisión ingenua porque pensar que trabajar para ti mismo te da más tiempo fue definitivamente un error que creo que reconoceremos un poco más adelante. Y antes de ese punto, sabía un poco sobre SQL y he estado construyendo computadoras desde entonces, en realidad desde que la tarjeta gráfica es muy compatible con los colores. Entonces, para cualquier otra persona que sepa qué es CGA, eso lo ayudará a saber qué edad tengo. Pero sí, en serio, fue cuando salieron los CPT. Esa grasa lo cambió todo para nosotros. Y comenzamos a usar WordPress prácticamente de la noche a la mañana, en realidad, ese se convirtió en nuestro CMS elegido y no hemos mirado atrás desde entonces y, ya sabes,

DV: de todas las personas a las que les he hecho esta pregunta, muy pocas se han dado cuenta de cómo los tipos de publicaciones personalizadas materiales eran en relación con su historia de origen de WordPress. Y es divertido Tengo una historia similar. Fundé una agencia en 2010. Así que un poco después de todos ustedes, pero cuando la publicación personalizada ya entró. Comenzamos a construir con Joomla y cambiamos a WordPress por razones similares, pero eran estos tipos de publicaciones personalizadas y meta personalizado. Los campos en los que estoy de acuerdo y en realidad presenté de esta manera varios formatos es que fue en este tipo de momento cuando WordPress realmente se convirtió en un verdadero CMS. Un año después de la creación de WooCommerce, la creación de WP Engine, muchas otras marcas del espacio de WordPress, es un momento tan transformador. Es interesante escuchar tu tipo de referencia que es la raíz de tu historia de origen. Sin embargo, me estaban contando sobre cómo, y ya sabes, el momento de fundación allí, si quieres, pero ¿podrías contarme brevemente un poco sobre cómo, y cómo lo haces?

JM: Sí, seguro. Así que, en realidad, esa agencia que encontramos no era como era como lo hicimos después. Bien bien. Bueno, la razón principal de eso en realidad es porque, ya sabes, en esos días anteriores, había una diferencia muy clara entre, ya sabes, construimos sitios web versus hacemos SEO y todo este tipo de cosas. Y en realidad no era tanto el enfoque integrado de muchos en todo el mundo y realmente pensar en cosas como la experiencia del usuario, y cómo funciona eso con SEO y desarrollo, todo ese tipo de cosas. Entonces, esa fue la razón por la que terminamos fusionándonos con Allen Milan durante unos 20 años y nuestro fundador se estableció prácticamente desde el principio, cuando el SEO comenzó a convertirse en algo. Así que sí, fusionamos las dos agencias. Hace seis, siete años, tal vez un poco más. Mi memoria para los datos no es excelente, debo admitirlo. Y luego Y luego realmente, sí, ese es nuestro enfoque, ¿es este enfoque totalmente integrado sobre la combinación de todas estas disciplinas diferentes para ayudar a las personas a ver la línea? Así que ahora hacemos PPC, SEO, relaciones públicas digitales, obviamente, diseño web y hay estiramientos de marca, estrategia digital y todo este tipo de cosas, todas estas disciplinas que realmente necesitas para tener una buena presencia digital sólida en estos días. ¿Cuál es su papel allí, la empresa? Así que mi título de trabajo era director técnico. Entonces, seré honesto, en realidad no cubre todo lo que hago. Dirijo el equipo de desarrollo durante un largo período de tiempo. Así que todo lo que será WordPress estuvo bajo mi dirección. Me complace decir que tenemos mucho mejores desarrolladores en el equipo de lo que Julio y yo trabajábamos cuando comenzamos, razón por la cual lo estamos haciendo mucho mejor en estos días. Y entendemos las cosas un poco más. Así que dirijo el equipo de desarrollo durante un largo período de tiempo más recientemente también en un equipo de costo de datos. Eso significa que puedo jugar con el aprendizaje automático, Python, Bartek y otros están jugando, aunque tengo que imaginar todo esto jugando.

DV: Hacer clientes geniales separados resultará en una cierta deuda tecnológica en el camino. Entonces, tengo curiosidad sobre cómo piensas, cuáles son los tipos comunes de deuda tecnológica y quizás específicos de WordPress. Esos por un minuto, pero como, ¿cómo piensas en eso mientras piensas, ya sabes, cómo y cómo administran su deuda tecnológica, como si la hubieran encerrado en tipos con WordPress construido?

JM: Sí, lo hacemos. Quiero decir, no. No necesariamente. Estamos haciendo un tipo de lenguaje en el que no necesariamente categorizamos cosas ni pasamos por un proceso distrital para categorizar, pero en realidad, se dividen en tres grupos diferentes. Uno de ellos es cuando crea un código incorrecto sobre los códigos existentes, y eso podría deberse a que tal vez cometió algunos errores en el pasado que podrían ser un problema de los sitios web de Heritage y de otra persona, sea cual sea el motivo, ese es el una especie de primer cubo. El segundo es crear código que no es necesario, y tal vez simplemente no sea necesario en este momento. Sabes, estoy seguro de que todos hemos estado al final de las solicitudes de características de los clientes y las marcas con las que trabajamos donde realmente les interesa algo en particular, pero en realidad podría no ser lo correcto, en términos de obtener valor real. para los clientes Y luego el tercero, que es el más grande que vemos en realidad, está creando características que realmente deberían estar en una plataforma diferente. Entonces, entendiendo ese tipo de pieza arquitectónica sobre bien, cuáles son las diferentes partes que estamos conectando aquí es un CRM aquí está el sitio web, que fundamentalmente se trata de comercializar el negocio. Aquí está su plataforma de cumplimiento de pedidos, todos esos tipos de diferentes.

D V: Déjame preguntarte, déjame hacerte una pregunta fundamental aquí como tú, has enumerado los tres tipos de sonidos como si estos fueran los tres tipos de deuda tecnológica de los que quieres deshacerte. Escribe código incorrecto en código incorrecto. código, esas no son características necesarias que se pueden hacer en otra plataforma. ¿No hay un cuarto cubo como las características que desea que sean valiosas y, por lo tanto, la tecnología que tal vez sea buena en ese caso? ¿Es justo decir eso? Ese es un cuarto cubo.

JM: Sí. 100% Quiero decir, no toda la deuda técnica es mala. Hay que aceptar que prácticamente cualquier característica que vaya a construir acumulará algún tipo de deuda técnica y debe decidir si esa deuda técnica es buena o no. Algunos son buenos, otros son malos y realmente dependen de la palabra clave que dije antes sobre el valor. ¿Vas a obtener el valor que necesitas para esa cosa? Más importante aún, ¿el cliente, el cliente final, no es su cliente, sino que son sus clientes? ¿Van a obtener el valor por ello? Esa suele ser una buena guía para saber si aceptar esa deuda técnica.

DV: Sí, quiero profundizar en lo que piensas sobre esa cita, la fórmula que vale la pena para saber cuándo está bien aceptarla o no, pero es bueno pensar en ello y obtener una buena comprensión de cómo piensas en los diferentes cubos de tipos de deuda tecnológica, y particularmente aquellos que quizás desee optimizar para eliminar. Sin embargo, lo que me gustaría hacer a continuación es entender si hubo algo que te llevó al límite para enfocarte en esta área, pero vamos a tomar nuestro primer descanso y luego Vuelvo enseguida. Es hora de conectarse a una pausa comercial. Estén atentos para más prensa esto solo un momento. Hola a todos. Bienvenido de nuevo a presionar este podcast de la comunidad de WordPress en W EMR Este es su anfitrión, David Vogel. Pablo. Estoy entrevistando a John Martin sobre cómo anular el tiempo matando a la tecnología. John, justo antes de la pausa, estabas explicando que la forma en que piensas en los tres tipos de deuda tecnológica que podrías querer eliminar es construir código incorrecto sobre código incorrecto creando código que no es necesario para el éxito del sitio en el que estás trabajando. Y luego, tal vez, desarrollar código para características que se pueden servir mejor en otra plataforma. Sin embargo, antes de entrar en la fórmula de la cita que vale la pena. Me preguntaba, ¿hubo un momento particular, no sé, y su viaje es un ejemplo particular de deuda tecnológica que ese tipo de superficie para usted es un área de enfoque principal para cómo?

JM: Sí, absolutamente. Hay un proyecto histórico real que comenzó a hacerme pensar en esto hace unos cuatro o cinco años. He visto muchos otros casos. Las empresas acumulan tiempo, todo el tiempo, no solo a través de WordPress a través de todo tipo de cosas, en realidad las empresas también lo acumulan a través de sus procesos operativos. Si tienes que ser algo técnico donde creas ese mazo. Uno, la única historia que realmente se destaca en mi mente más que cualquier otro cliente, trabajamos con una empresa relativamente pequeña, hicimos mucho trabajo de medios pagados para ellos. Vender esencialmente vender cosas en línea. Era un negocio de comercio electrónico. Y tenían un tipo de pedido por correo tradicional, pero gran parte de su trabajo y estaban tratando de generar más tráfico en línea para que no tuvieran que pasar por el pedido por correo se administrará a través del sitio web y acudieron a nosotros porque han tenía un sitio construido para ellos es completamente a medida. Y han existido durante unos 10 años en ese momento. Así que se estaba volviendo bastante viejo y empezaba a arrastrarse un poco. Ya sabes, normas y seguir adelante. La tecnología ha avanzado, es hora de repensar un poco. Entonces, el cliente se sentó con nosotros, comenzaron a informar sobre todas las cosas diferentes que hicieron en el sitio web. Y me quedó muy claro muy rápidamente que había todo tipo de lógica comercial y cosas operativas comerciales que se habían integrado en el sitio web. Y esa era la lógica que lleva a los pedidos y es bastante específica a la forma en que trabajan los proveedores. Así que no entraré en detalles, pero tengo un acuerdo bastante complejo entre los proveedores y cómo cumplen con los pedidos y si se envió a su tienda antes de enviar todo este tipo de cosas. Así que todo es bastante complicado. Ahora, el propietario de la empresa y el anterior sobre cómo funcionan, finalmente construyeron un sistema que prácticamente administraba todo, era un sistema realmente bueno en ese momento y realmente ayudó a que la empresa creciera masivamente. Ahora, lo que realmente no han pensado es que todos los sitios web eventualmente tienen una vida útil en la que cobrarán vida en algún momento, al igual que cualquier software y en el mundo del marketing. Esa vida útil es realmente relativamente corta en comparación con, por ejemplo, si invierte en un CRM, ya que una empresa normalmente tendrá eso funcionando durante bastante tiempo, ahora son aproximadamente 10 años, si no más sitios web. En términos generales, entre dos y cinco años, encontramos que la mayoría de las grandes marcas tienden a reconstruirse cada tres años más o menos. Entonces, el problema fue que construyeron toda esta lógica complicada en el sitio web existente y tuvieron que reconstruir todo el sitio web. Y de repente también tienes que reconstruir toda esta lógica empresarial. Ahora, calculamos el costo del proyecto y básicamente terminó siendo aproximadamente la mitad de la facturación anual en la base solo para reconstruir lo que ya teníamos. Y lo que realmente me hizo pensar en esto es que bueno, está bien, si abordan el problema de una manera diferente originalmente, por ejemplo, pensemos en las diferentes cosas que estamos tratando de lograr en un sitio web. Ya sabes, esto es de marketing fue esto para vender productos. Esto es para el cumplimiento de pedidos, esto es lo mejor para administrar mi proceso comercial con suministros, todas esas cosas, y pensando en eso de una manera un poco más modular, entonces habría sido una situación muy diferente para este cliente, que ella estaba allí . Fue un verdadero problema para ellos porque tenían un sitio web que era esencialmente desde donde estaban ganando dinero. Crujía bastante porque es bastante viejo. Pero al mismo tiempo, iba a costar mucho reconstruir todo el sitio web y complicaba mucho el proyecto. Logramos encontrar un trabajo bastante inteligente pero no agradable hasta el final para tratar de usar lo que ya tenían e integrarlo, pero no podemos citarlo, pero ya sabes, finalmente terminó siendo mucho más doloroso, mucho más lento y mucho más. caro de lo que tenía que ser. Si esa arquitectura hubiera sido pensada originalmente.

DV: Tengo tantos proyectos que quiero olvidarme de eso. Eran así, y puedo, puedo imaginármelo ahora, estoy retrocediendo en el tiempo. Entonces, para mí, eso suena bastante claro, creo que es una lección muy importante para pensar en el tipo de costo para el negocio en relación con el refactor que está planeando. Y para mí, parecía que la respuesta clara era que necesitabas diseñarlo de manera diferente. Y ese es quizás un camino más claro si te gusta lo que debes hacer. Pero creo que muchos equipos cuando piensan en la deuda tecnológica, es como si pensaran, bueno, bueno, sería genial hacer esto, pero ¿vale la pena?

JM: ¿Me vale mantener esto en el tiempo? Así que tengo curiosidad por saber cómo piensas sobre esa fórmula.

D V: cuándo, como, ¿cuándo está bien introducir deuda tecnológica? ¿Y cuánto piensas de esa fórmula?

JM: Sí, tocaste un punto realmente importante, ya sabes, piensas en la naturaleza de los desarrolladores, los desarrolladores se involucran en esto porque les encanta hacer cosas geniales. Y eso es, ya sabes, una gran parte de nuestra motivación es aprender a hacer cosas nuevas, nueva tecnología, ya sabes, nuevos marcos de JavaScript, lo que sea, y eso naturalmente nos da la motivación que se vuelve para construir cosas geniales, pero no pensamos necesariamente a largo plazo sobre eso, ya sabes, todavía vamos a mantenerlo. Sabes, a mi esposa le encantaría tener un jacuzzi en mi casa, pero sé que alguien lo va a limpiar y seré honesto, no creo que nadie lo limpie, es ese tipo de pensamiento de todos modos. Entonces, es una muy, muy, muy buena pregunta para pensar, ¿realmente vale la pena en primer lugar? término, ¿cuál es el costo total de propiedad y construcción de probarlo y mantenerlo, y luego compararlo con el valor que obtenemos? Entonces, por ejemplo, puede haber una manera realmente simple de resolver ese problema. usando hojas de cálculo o usando cosas arquitectónicas ligeramente diferentes donde tal vez alguien internamente en la empresa lo maneje por un corto período de tiempo. Y sería más barato hacer eso y más efectivo que construir esta característica realmente complicada. Pero cuando realmente miras el costo total de propiedad, va a costar más de lo que le costaría a alguien dedicar un par de horas a la semana a hacer una cosa en particular. No me malinterpretes. Soy un gran creyente en la automatización. las tecnologías deberían automatizarse tanto como sea posible para evitar ese tipo de administración, pero

DV: se está registrando y utiliza enfoques como este manual para probar algo antes de codificarlo para asegurarse de que el valor estará allí. Quiero decir, tengo la idea de simplificar este factor, como, ¿podemos hacer esto manualmente en su lugar? Solo por curiosidad, si alguna vez lo ha abordado desde una perspectiva de prueba para ver si el rendimiento final vale la pena.

JM: Sí. 100%. Entonces, soy un gran creyente en la metodología Agile. Y fundamentalmente, uno de los grandes principios clave de Agile es que construyes lo correcto en el momento correcto. Y te enfocas en ganar valor lo más rápido posible. Así que quieres construir el producto mínimo viable. Ahora, eso significa que no necesariamente tiene algo que sea completamente rico en funciones en ese momento. Pero te brinda una plataforma donde puedes comenzar a probarlo, ya sabes, ¿realmente obtienes las cosas que quieres de eso? ¿Están respondiendo tus usuarios? De la forma en que espera que cualquiera que haya trabajado en UX o desarrollo web sabrá que muy a menudo recibirá solicitudes de los clientes porque piensan que son sus clientes, pero ¿realmente lo quieren? Entonces esa es otra muy buena pregunta para hacer: una vez que haya pensado en esa visión a largo plazo, ¿las personas que van a usar el sitio web sabemos que alguien lo usará o necesitamos probar para ver si quieren? para usarlo? Y luego, una vez que haya hecho esa prueba, podemos determinar qué no deberíamos haber pedido y si deberíamos retroceder y poner nuestra inversión en otra parte.

DV: Así que parece recapitular estos pensamientos y me gustó su idea de ver el costo total de propiedad a largo plazo, ya sabe, creo que muchas veces los equipos piensan que incluso las personas que conocen, cotizan, solicitan servicios del los equipos piensan cuántas horas o semanas o diferenciales o puntos o lo que sea que va a construir esta cosa. Pero luego, ya sabes, debes tener en cuenta que sabes, cuántas horas, semanas, diferenciales o puntos se necesitarán para mantener y luego usar ese saldo contra el valor que obtienes manteniendo. esa actividad Eres obviamente ese es un buen consejo. Pero luego también estás pensando, Bueno, ¿hay algo que pueda hacer para probar esto y ver si mis suposiciones son correctas? ¿Suena exacto?

JM: Sí. Absolutamente. Absolutamente. Y lo único que no mencionamos es lo que hablamos un poco antes, que es sobre arquitectura, ¿hay una mejor manera en que podamos estructurar esto para hacerlo mejor y ese tiempo para la programación de objetos y esas cosas? que probablemente tocaré un poco más tarde.

DV: Sí, las consideraciones arquitectónicas también, como que escribí cómo eras, ¿hay alguna manera de que podamos cambiar las especificaciones? ¿Es como en mi capacitación de partes interesadas o en mis charlas, a menudo digo, ya sabes, especificaciones para presentar, verdad? Pregunta por lo que realmente necesitas para alojarte. Y entonces, preguntarles a esos mentirá y será realmente necesario y ¿qué pasa con esto? Se me ha encontrado que las preguntas son muy críticas. Así que parece que es una parte clave de cómo estás pensando en esto.

JM: Sí, porque cada minuto que ese sitio está en desarrollo es un minuto que no obtiene valor frente a los clientes. Y esa es la manera fácil de pensar en ello. Desea lanzarse lo más rápido posible. Y luego pruebe, monitoree, itere, aprenda, ya sabe, vea a dónde va desde allí, pero solo porque lo está haciendo en base a datos reales en lugar de lo que cree que es correcto. Porque muy a menudo no son lo mismo.

DV: Sí, me encanta ese punto. Cada minuto. Está en desarrollo, ¿no es como un momento en el que no lo estás usando? Averigua y diré que se relaciona con otro tipo de vínculos con otro mantra que tengo y gestión de proyectos y gestión de partes interesadas, que son las dos mejores palabras y conseguir un proyecto en nuestra cara para escribir. ¿Cómo puedes hablar? Sí, me encanta cuando trato con las partes interesadas, o cuando tengo una parte interesada que es una parte poderosa, poderosa. Está bien, genial. Um, hablemos a continuación sobre cómo pueden hacer los equipos para reducir la deuda tecnológica. Pero antes de hacer eso, tomaremos nuestro último descanso. Es hora de conectarse a una pausa comercial. Estén atentos para más información sobre esto en un momento. Todos bienvenidos de nuevo a presionar este podcast de la comunidad de WordPress en W EMR. Este es su anfitrión David móvil Paul, estoy en el medio de hablar sobre evitar perder el tiempo deuda tecnológica con John Martin de cómo John justo antes del descanso, hablamos un poco sobre su fórmula de vale la pena Me gustaron mucho sus nociones sobre la reducción especificaciones. Y pensar en el TCO y adoptar un enfoque de prueba iterativo. Pero profundicemos ahora en lo que los equipos pueden hacer para reducir su deuda tecnológica y las compilaciones de WordPress. ¿Cuáles son algunas de sus técnicas favoritas para reducir la deuda tecnológica?

JM: Así que hay todo tipo de técnicas técnicas que puedes usar y conoces algunas de ellas con las que estarías familiarizado para que no lo hagas, pero en realidad el punto de partida para mí es un enfoque mucho más suave hacia la conversación. a tus clientes Y debe recordar que, en última instancia, sus clientes son estas marcas que acuden a nosotros porque somos los expertos. Necesitan nuestro consejo y es bastante fácil caer en la trampa de que, ya sabes, estamos ahí para hacer lo que ellos quieren, para lo que estamos ahí para hacer lo que ellos quieren que hagamos, pero en realidad, estamos ahí. desafiar lo que quieren hacer y tratar de mejorarlo. Entonces, lo primero que puede hacer es hablar con ellos al respecto y explicarles que está bien, si hacemos eso, este será el efecto a largo plazo. Sabes, nos llevará un día extra de prueba. Cada vez que hacemos un lanzamiento, agregará un par de horas o dos cada vez que necesitemos mantener el sitio web y actualizar todos los complementos o lo que sea. Pero al aumentar esa conciencia, estamos teniendo esas conversaciones con ellos. Puede hacer que el cliente sea parte de esa discusión. Y luego eventualmente se convierten en parte de la resolución de problemas. Bueno, tenemos que educar a nuestros clientes todo el tiempo, simplemente porque no saben algunas cosas que hacemos. Si lo hicieran, no se convertirían en herramientas en primer lugar. Así que en realidad, ese es el punto de partida. Piensa recordar eso además de simplificar las cosas. Nuevamente, las personas no son necesariamente tan técnicas como nosotros. Así que usa analogías para hablar de ello. Siempre encuentro que las casas son una gran energía. Todo el mundo vive en la casa. La mayoría de la gente tiene alguna experiencia en hacer algún tipo de mejora de la casa. Así que fue bastante fácil usar esa energía para arreglar las cosas. Así que ese es el tipo de primer punto que realmente es conseguir un cliente o ciclar esas conversaciones. Lo siguiente que mencionamos antes fue tener esa visión a largo plazo o el costo total de propiedad. Y hágase esas preguntas y cuestione cada solicitud de función. Pero siendo un poco más técnico y cómo harías esto en el trabajo. Cosas simples que usas los estándares de WordPress, ya sabes, hay estándares que están ahí. Existen por una razón. Ahora, nos ayudarán a nosotros, los desarrolladores, y tal vez trabajes en un proyecto que dejas de lado durante un año o dos y luego vuelves a él. Tienes que refrescar tu memoria y volver a donde estabas cuando lo construiste por primera vez usando estándares ayudará. También ayudarán a otras personas. Entonces, si no estabas dentro del equipo, significa que tienes este lenguaje común con el que todos pueden operar, lo cual es muy, muy útil en términos de eficiencia y ayuda con la documentación y todo este tipo de cosas. Entonces esa es una forma más suave de reducir su deuda técnica al tener estándares que cualquiera puede trabajar. También te ayuda a saber que puede llegar el momento en que otros desarrolladores de WordPress estén trabajando en ese proyecto. Y les ayuda a pensar en ello como una forma de retribuir a la comunidad y hacerlo más fácil para sus compañeros desarrolladores. Así que eso es, ya sabes, un buen punto sobre el tipo de estándares y hacerlo más fácil para ti y para los demás. El siguiente es más sobre genial. Gran código de la industria, conocido cariñosamente como el tío Bob, que escribió un libro maravilloso llamado The clean coder hace muchos, muchos años. Recomiendo encarecidamente a cualquier desarrollador que lea ese libro porque no lo han leído. De hecho, lo hice de lectura obligatoria para un equipo de desarrollo, para cualquiera que se uniera al equipo, principalmente porque tiene un buen enfoque al respecto, habla sobre pruebas unitarias, todo este tipo de cosas, pero fundamentalmente, mucho de eso. se trata de cómo se escribe el código de una manera que lo hace flexible que se puede iterar y cambiar muy rápidamente y agregarle bits adicionales. Uno de los puntos importantes de los que habla es sobre la refactorización a menudo, y esto es lo principal que se debe extraer de esto: escribes un fragmento de código que no necesariamente significa que ese fragmento de código está terminado. Hay cosas que puede hacer para optimizarlo para que sea más portátil para que sea más modular o para mejorar una prueba, lo que sea que necesite hacer para dedicar tiempo a refactorizar el código. Puede ser muy, muy difícil de hacer cuando te enfrentas a ello o, ya sabes, tal vez sea un marco de tiempo para un presupuesto. Pero en última instancia, ese es el tipo de cosas que evitarán que acumule deuda técnica y, de hecho, por lo general, esa es la forma en que lo veo forzado, pero como fecha límite del proyecto, debe cumplir con esa fecha límite. Absolutamente. Tienes que darle, pero es mejor flexionar el alcance que escribir un código incorrecto que luego vas a hacer,

DV: Supongo que educar a esos clientes sobre eso también, porque nunca he conocido a un desarrollador que no quisiera refactorizar. Código. Siempre es la línea de tiempo. Está en contra. Um, está bien, así que esto es lo último. Solo tengo curiosidad si te gustamos, si piensas en cosas como descargar y usar complementos listos para usar es otra forma de ayudar a evitar la tecnología u otras formas de evitar la deuda tecnológica. ¿Eso también está en tu lista?

JM: Sí. 100% Así que esa es una buena manera, pero es una buena manera de hacer ambas cosas en realidad, puede evitar la deuda técnica. Pero también puedes y esto es lo que sabes, WordPress es una forma de BMC. Es tan activo, igualmente, que también puede ser su peor enemigo. Hay un complemento que hace todo. Y también hay muchos complementos que se han creado para un propósito muy específico, pero no necesariamente coinciden con sus propios complementos. Así que he visto esto particularmente con algunos de los desarrolladores a los que les gusta construir sitios usando complementos y el enfoque de apuntar y hacer clic hacia las cosas en lugar de codificarlo desde el punto de vista de cero. La gente tiende a lanzar complementos a las cosas. Hemos trabajado con sitios web que tenían más de 100 complementos y muchos de ellos ya no se mantienen. Hay problemas de seguridad por todas partes. Intentas hacer la tasa de liberación. Pasas literalmente cuatro días probándolo cuando podrías haberlo hecho en un par de horas. Entonces, los complementos pueden ser buenos o malos. El enchufe correcto en el momento correcto fue algo maravilloso, maravilloso. Las mayores fortalezas de WordPress, pero el complemento incorrecto en el momento incorrecto también puede ser muy dañino. Y en realidad puede ser una de esas mayores fuentes de capital que

DV: He tenido un proyecto así seguro. Bueno, John, esto ha sido increíblemente perspicaz. Muchas gracias por acompañarnos hoy.

JM: Un placer.

DV: Impresionante. Si desea obtener más información sobre lo que es Jon, puede visitar hallam.co.uk. Gracias a todos por escuchar los podcasts de esta comunidad de WordPress en WMR. Nuevamente, este ha sido su anfitrión, David Vogelpohl. Apoyo a la comunidad de WordPress como parte de mi función en WP Engine y me encanta traer lo mejor de la comunidad aquí en Press This.