Panel Discussion: Code Quality

Gracias por tenerme. Soy Anna, y aquí conmigo hay tres personas increíbles para discutir la calidad. Tenemos a John Papa, quien es un desarrollador web y móvil profesional y actualmente trabaja como defensor de desarrolladores para Microsoft. También es muy activo en la comunidad de código abierto y también participa en el podcast Real Talk JavaScript. También tenemos a Angie Jones con nosotros, quien es una defensora principal de desarrolladores en ApliTools y se especializa en estrategias y técnicas de automatización de pruebas. También es una inventora muy creativa y es voluntaria en Black Girls Code. Por último, pero no menos importante, tenemos a Jason Palmer aquí con nosotros, quien es un contribuyente principal de Jest y el creador y mantenedor de JestJUnit. También es ingeniero y gerente de producto técnico en Spotify, donde se enfoca en infraestructura, CI, CD y automatización de pruebas. Matthew ya dijo que vamos a hablar sobre calidad. La calidad es, de hecho, un tema que se discute mucho, y donde muchas personas tienen muchas diferentes opiniones. Pero me gustaría comenzar y hablar sobre lo que realmente es la calidad. ¿Cuáles son los aspectos de la calidad que deberíamos considerar? Y me gustaría hacer una ronda, y tal vez comencemos con Jason.

Jason, ¿qué piensas que es realmente la calidad cuando se trata de proyectos de JavaScript? Creo que hay muchas maneras diferentes de verlo. Pero al final del día, si las personas fuera de tu equipo pueden contribuir fácilmente a tu software, y tienes confianza en que no se va a romper, y si puedes desplegar continuamente a producción, así que haces un commit en la rama principal, y eso puede ir directamente a producción, y tienes confianza en eso, sabes que has hecho un buen trabajo. Así que eso es al menos cuando sabes que has desarrollado algo de alta calidad. Sí, si puedes salir de la oficina el viernes por la tarde, solo empujar a prod poco antes y luego salir para el fin de semana, definitivamente es una buena sensación poder hacer eso.

Angie, ¿qué piensas? Sí, definitivamente estoy de acuerdo con eso. Creo que la clave aquí es, uno, que funcione. Eso es muy obvio. Pero que funcione para tus usuarios, ¿verdad?, no solo para tu propia máquina local y solo los diversos caminos más felices. Pero, sabes, funciona para tus usuarios, y una parte clave de lo que dijo Jason es que los miembros del equipo pueden contribuir a eso. Así que eso significa que podemos leerlo, podemos refactorizar si es necesario. Nadie tiene miedo de tocar ciertos módulos, y eso es cuando sabes que estás en mala forma, cuando es como, oh, no quiero tocar eso. Así que esas son las características que siento que tiene el código de calidad. Sí, definitivamente.

John, ¿cuál es tu opinión sobre la calidad? Primero, creo que las características, esa es la palabra clave, creo que Angie acaba de mencionarlo. Este es uno de esos temas donde es difícil describir la calidad del código, pero lo sabes cuando lo ves, y lo sabes absolutamente cuando no está presente. Así que es fácil detectar ese tipo de cosas, pero todo se reduce a lo que Jason y Angie dijeron, que se trata más de, ¿funciona? ¿Cumple con las necesidades del negocio? Y veo la viabilidad a largo plazo de un proyecto como un gran signo de calidad del código. Si el proyecto vive el tiempo que se supone que debe vivir, por ejemplo, una vez que se pone en marcha, todos sabemos que hay problemas y mantenimiento y cosas en las que trabajar, que es donde llegamos a las contribuciones de las que todos hablamos aquí. Eso tiene que ser algo que mantenga el proyecto en movimiento. La señal para mí de una calidad de código realmente mala es cuando la gente comienza a hablar de, wow, acabamos de desplegar esto, tenemos una actualización. Es demasiado difícil actualizarlo. Vamos a rehacerlo desde cero. Y eso sucede con demasiada frecuencia en el mundo empresarial. Y quiero decir que es realmente evidente sin siquiera mirar el código cuando es de mala calidad. Y creo que todos podemos atestiguar situaciones en las que hemos utilizado algún producto como usuarios finales y simplemente sabes que lo que hay debajo no es de calidad. Puedes verlo incluso desde el exterior. Sí, definitivamente. Puedes detectar fácilmente un código malo, pero ¿hay también una manera de detectar o medir un código de buena calidad? Estás asintiendo. Siéntete libre de elaborar sobre eso. Sí, hay muchos, ya sabes, principios de codificación limpia y cosas así, que están ahí afuera que nos dan dirección sobre cómo deberíamos desarrollar un buen código de calidad, ¿sabes? En cuanto a que, ya sabes, las cosas no sean demasiado grandes, o demasiado largas, o demasiado abstractas. Sabes, hay ciertos principios que he seguido a lo largo de mi carrera y eso típicamente ha llevado a un código de buena calidad. Otras maneras que creo es, ¿qué tan testeable es tu código? ¿Verdad? Y siento que ese es uno que se pasa por alto bastante, pero da mucha información cuando piensas en tu codificación desde ese ángulo. Ya sea que practiques TDD, que es desarrollo guiado por pruebas, o si pruebas tu código después de haberlo escrito, eso también está bien. Eso es legal. Pero qué tan testeable es tu código, es un muy buen indicador que he encontrado de cuán bien está escrito. Sí. 100% He tenido esta experiencia también. Estoy 100% de acuerdo en la testabilidad. Y llamadas de spam. Así que, estoy 100% de acuerdo en la testabilidad allí. Una cosa que realmente me gusta sobre la señal de calidad del código es cuando las cosas se vuelven testeables, escucho a mucha gente decir que no puedo escribir código que sea testeable. Y hago muchas sesiones de coaching con ellos y muchas veces preguntamos, ¿por qué? Como, ¿por qué no es testeable? Lo que realmente se reduce a menudo es que el código es, como mencionaste Angie, demasiado largo. ¿Qué es demasiado largo? Creo que eso es subjetivo. Pero cuando tu código está haciendo múltiples cosas, cuando una función, por ejemplo, está haciendo siete cosas y tienes toneladas de comentarios explicando qué hacen todos los ifs y thens y switches y bucles for, esa es una gran señal de que tal vez estas cosas deberían ser separadas porque entonces puedo probar cada cosa individual por su cuenta en lugar de preguntarme dónde en este largo viaje algo salió mal.

La otra cosa que busco en la calidad del código y que recomiendo a la gente es que, porque me gusta Disney, se me ocurrió algo llamado los siete D's y ninguno de ellos representa a Disney. Pero Disney, hacemos estas cosas raras. Pero solía trabajar allí y los siete D's pienso en la calidad del código y estas siete áreas. Tienes que diseñar tu aplicación y debes manejar eso bien. Debes desarrollarla bien con calidad de código y estilo y tus pautas. Pero también debes tener una documentación de algún tipo en tu empresa para eso. También otro D que hay es Destruir. ¿Puedes destruirlo? ¿Puedes probarlo? Sabes, asegúrate de que tu código funcione bajo las malas condiciones, no solo el camino feliz.

También habrá una demostración. ¿Cuántos de nosotros escribimos algún tipo de arnés de prueba para asegurarnos de que la cosa funcione en una aplicación separada en algún lugar? ¿Por qué no incluir eso como parte de tu repositorio para que la gente pueda hacer una prueba de extremo a extremo en esa característica o integración también? Y luego también llegas a cosas como la implementación. ¿Puedes implementar tu código en producción? Así que el último es que no pude encontrar un buen D para revisión. Así que lo llamé Dereview porque soy italiano. Así que Dereview. Tienes que hacer Dereview porque tienes que asegurarte de que puedes aparecer en la revisión de otras personas. Si escribo código, Angie y Jason tienen que revisarlo, no yo, no la persona que lo escribe.

Es un gran punto, creo que la forma en que veo la calidad es cómo estás construyendo la automatización que entra en cada cambio de código. Así que dando un buen pensamiento sobre cuánto quiero probar antes de que el código se fusione en la rama principal, cuántas cosas estoy bien probando mientras está en producción. La forma de monitoreo para entender cómo mis usuarios están interactuando con el sistema, cómo está funcionando allá afuera en producción. Así que creo que básicamente tener como un pensamiento consciente sobre esto y planificar con anticipación lo que tendría más sentido para ti y tu equipo y qué tipo de velocidad quieres tener tiene mucho sentido. Así que esa es una señal de calidad en mi opinión.

Está bien, digamos que soy una persona que acaba de empezar a programar. ¿Cuál crees que es una buena manera de aprender sobre calidad y de entrar en todo este tema? ¿Dónde debería empezar? Creo que probablemente es bastante fácil aprender a escribir pruebas unitarias de inmediato. Eso es algo que, ya sabes, pronto después de que te familiarices con la escritura de código y logres que algo funcione. Sabes, no es demasiado difícil llevarlo un poco más allá y poder escribir esa primera prueba unitaria. Y creo que eso es una gran primera cosa que puedes hacer solo para tener una idea de cómo es la prueba y cuánto impacto puede tener en tu código a medida que lo desarrollas.

Sí, desafortunadamente, las pruebas son una de esas cosas que no se enseñan típicamente cuando estamos aprendiendo a programar, ya sea en un camino universitario tradicional, ya sea en un bootcamp autodidacta, lo que sea. Es una de esas notas al margen, si es que la obtienes. Así que sigue siendo algo que aprendes mucho en el trabajo. Recomiendo encarecidamente a las personas que revisen el código de otros, como mencionó John. Así que para las revisiones de código, no solo mires la característica, mira también las pruebas unitarias que se revisaron, y esto te da una idea de cómo otras personas están abordando sus pruebas.

Y desafíate a ti mismo también. ¿Se perdieron un caso? ¿Puedes pensar en algo más que, ya sabes, no esté tan alejado que no queramos molestarnos en incluirlo, pero, ya sabes, algo que sería de valor que se perdió en la prueba unitaria? Así que esto te introduce en el proceso de pensamiento. Te alejas del modo de construcción y piensas más en lo que, por falta de una mejor palabra, dijo John, destruir. Pero no, piensas en cómo ejercitar este código y cuáles son otros diversos escenarios que, ya sabes, son escenarios legales que tu código debería cubrir definitivamente. Y en eso comienzas a pensar más en este tipo de mentalidad de calidad y luego puedes saltar a lo que dijo Jason y comenzar, ya sabes, a contribuir con pruebas unitarias, tal vez para esa otra característica o algunas de las tuyas también.

Voy a dar un, estoy de acuerdo en que las pruebas son realmente, realmente importantes y no quiero disminuirlo por lo que estoy a punto de decir, pero quiero dar un pequeño argumento en contra de las pruebas. Creo que una de las razones por las que las pruebas son difíciles hoy en día y no en el pasado es porque tenemos grandes herramientas ahora, eh, durante un tiempo, eso fue un problema hace años y ahora tenemos grandes herramientas. Es cuando probamos, todos enseñamos cuando las personas enseñan o enseñan cómo probar, pero no siempre enseñamos qué probar y eso se convierte en un problema porque sí, puedo escribir una prueba que haga algo, pero ¿hay valor en esa prueba? y eso es lo realmente importante que este panel no tendrá casi suficiente tiempo para abordar, pero eso es mucho más importante que el cómo. Porque puedes tener una cobertura de prueba del cien por ciento. Y cada vez que alguien me dice eso, generalmente los miro y digo, ¿qué estás probando realmente? Porque eso es como, ¿hasta dónde llegaste?

Porque las cosas más importantes son probablemente, ya sabes, las características del negocio y demás. Así que tendré un aspecto diferente también, que es una guía de estilo. Y obviamente estoy sesgado porque me gusta crear estas cosas, pero no importa quién la escriba o lo que diga. Muy directamente. No importa lo que diga, siempre y cuando tu equipo la siga, una gran parte de la calidad del código es cuando tienes tres personas o tienes 3000 personas en tus equipos de desarrollo, tener una guía de estilo que puedas hacer cumplir a través de algún tipo de reglas de linting y demás, es críticamente importante por tantas razones y. El código consistente es mucho más fácil de mantener. Como hablamos al principio, digamos que Jason hace una solicitud de extracción y cambió una línea de código, pero tiene tres espacios en lugar de dos dentro de sus archivos de código, lo cual sería una locura, ¿verdad? Pero si hace algo así, de repente tengo 8,000 archivos y una solicitud de extracción que tengo que revisar y no lo estoy haciendo. Así que cosas como esta, estoy exagerando, pero realmente es importante tener una guía de estilo que tu equipo pueda seguir.

Y de nuevo, las reglas no son tan importantes como la consistencia. No, eso es realmente bueno. La parte de la guía de estilo, sí, los linters y todo eso, pero más específicamente la parte sobre qué estás probando. Encuentro que la gente realmente se pierde en esto. De nuevo, no los culpo mucho porque no es algo que enseñemos muy bien. Publicidad descarada. Tengo una universidad gratuita dedicada a las pruebas. Se llama Test Automation University. Es en línea, todos los cursos son gratuitos, así que puedes tomar cursos allí para aprender mejor estas cosas, pero no puedo decirte cuántas veces, y por eso enfatizo no solo revisar las características y las revisiones de código, sino también revisar la prueba. No puedo decirte cuántas veces he visto pruebas unitarias. Voy a dar un ejemplo, digamos que está probando alguna solicitud de API, y la afirmación es literalmente, asegúrate de que la respuesta no sea nula. Eso no es realmente probar lo que deberíamos estar probando. Tener solo algo que regrese no es lo mismo que tener lo correcto que regrese, por ejemplo. Realmente piensa en la cobertura que estás añadiendo porque estas pruebas, las pruebas están realmente ahí para salvarte. Hay múltiples beneficios al tener pruebas. Pero el más grande, en mi opinión, es la retroalimentación rápida y para salvarte de errores realmente feos, desagradables y costosos que podemos atrapar. Podemos atrapar esto antes de que llegue a producción, si probamos esto adecuadamente. Todos estos son puntos realmente importantes.

Creo que es importante entender y pensar en qué usuario estoy probando. Una prueba de nivel mucho más bajo, una prueba unitaria o prueba de integración, el usuario que probablemente tienes en mente en este caso sería otro equipo de desarrollo, así que puede que estés escribiendo una prueba contra una API, o contra una llamada de función, o una clase, o algo así, y teniendo en cuenta que el usuario en esta situación es otro equipo de desarrollo que podría estar interactuando con esta función, interactuando con esta clase, y lo que sea. Y luego, una prueba de extremo a extremo podría ser un usuario real allá afuera, interactuando con tu aplicación web, con tu servicio de back-end, lo que sea que estés desarrollando, pero creo que es importante tener en cuenta quién es tu usuario, quién es tu usuario para cada prueba que estás escribiendo, y creo que al hacer eso, vas a hacer un trabajo mucho mejor evitando probar la implementación, que es una especie de lo que llamamos una prueba de caja blanca, o una prueba de caja gris, y generalmente hablando, eso es algo que deberías intentar evitar.

Sí, definitivamente. Ya hemos hablado un poco sobre las revisiones, y tenemos en realidad una pregunta para eso. Borlock pregunta, ¿qué opinas sobre las revisiones de solicitudes de extracción? ¿Cuáles son tus pasos? ¿Cuánto tiempo dedicas? ¿Cuál es el flujo de trabajo? Creo que todos probablemente tenemos opiniones sobre cómo hacer revisiones, y no creo que haya muchas maneras incorrectas. Hay muchas maneras correctas de hacerlo, por supuesto. Una de las cosas que es una manera incorrecta es mirar el código en GitHub, no ejecutarlo, no bajarlo localmente, no asegurarte de que funcione, y simplemente decir, oh sí, confío en Jason. Jason hace un buen trabajo, y fusionar. Una gran cosa para las revisiones que me gusta hacer, tengo múltiples procesos, en algunos equipos, voy a GitHub, y abro el proceso de revisión justo allí.

Haré comentarios sobre el código, y si son cambios pequeños, agregaré el botón de sugerencia, que me encanta, justo en GitHub, y presionaré ese pequeño signo más, diré, oh, cometieron un error tipográfico, en lugar de hacer que la persona lo cambie, lo arreglo por ellos, y crea una sugerencia, y en realidad puedes comenzar una revisión, y soy conocido por crear en un archivo 30 o 40 sugerencias para pequeñas cosas, y de esa manera la persona puede aceptar cada una o rechazar cada una sin hacer de esto un gran proceso. El segundo paso que me gusta hacer es ejecutar las pruebas, si tiene CICD integrado, voy a ver los resultados allí, o simplemente puedes abrir un contenedor o algo localmente, bajar el código, y ejecutar todo y ejercitar los cambios que hicieron. Así que hay muchas cosas que hacer. Nunca debería ser solo un, oh, sí, Angie es genial, déjame presionar el botón.

Sí, eso es muy importante. Eso es realmente bueno, porque muchas personas se quedan atrapadas ahí, ¿verdad? Básicamente te estás convirtiendo en el linter humano, y estás revisando cosas que el linter ya ha revisado, y tú como, ah, se ve bien para mí, ya sabes, sugerencias muy menores. Pero no, como dijiste, ejecuta esas cosas. Le dije esto a un colega una vez, y su mente se quedó asombrada, como que literalmente nunca pensaron, oh, tal vez debería ejecutarlo, ¿verdad? Otra cosa que me encanta hacer es sacar el problema, ¿verdad? Sacar el problema y ver cuál era realmente el requisito, y determinar si esta implementación cumple con ese requisito. Porque podría estar implementado, ya sabes, genial, todo el código es hermoso, calidad del código, sí, pero no cumple con la necesidad del negocio que se solicitó.

Así que ahí es donde generalmente empiezo. Lo ejecuto. Nuevamente, miro las pruebas, asegúrate de que tengamos, ya sabes, una buena cobertura allí. Y también doy un paso atrás y pienso, está bien, si esta persona ganara la lotería esta noche, y tuviera que heredar esto, ¿qué significa eso para mí? Es decir, ¿es legible? Ya sabes, ¿podría tomar esto si tuviera que hacerlo? Y si no, déjame señalar los problemas que me impedirían hacerlo.

Ese es un muy buen punto. Creo que eso es realmente, realmente bueno. Estoy de acuerdo con todo lo que se ha dicho hasta ahora. Quiero decir, especialmente lo que dijiste, Angie, sobre, ya sabes, ¿cumple esto con los objetivos del negocio? Creo que estoy imaginando una situación ligeramente hipotética, ¿sabes? Así que, supongamos que tu código ya tiene una muy buena automatización de pruebas y linting, y tienes mucha confianza en que cualquiera pueda hacer contribuciones. En ese punto, ¿qué queda para que revises, verdad? Y así, creo que todo lo que se ha dicho aquí es perfecto. No realmente tengo mucho que agregar ahí. Algo que me gustaría mencionar sobre esto, porque yo, Angie, me hiciste pensar en ello mientras hablabas, fueron las solicitudes de extracción y los commits.

Creo que todos estamos haciendo algunas suposiciones aquí, porque vivimos en los mundos en los que vivimos. Y a veces veo solicitudes de extracción donde la gente hace, haré una analogía con el sistema político de muchos países. Un proyecto de ley, por ejemplo, en los Estados Unidos, sale para, vamos a pintar todas las calles de púrpura, solo eligiendo algo raro. Ese es el proyecto de ley. Y esa es la característica de la que Angie está hablando en este caso, eso es lo que se supone que debe hacer el código. Pero luego me cuelo, bueno, añadamos este botón. Y Jason se cuela, bueno, añadamos esta cosa. Y todas estas pequeñas cosas se cuelan en el proyecto de ley o el código en este caso. Hace que una solicitud de extracción sea realmente difícil de revisar, porque realmente no puedes separar todas estas características.

Y piensa en la persona que está mirando el código. Ahora están mirando la característica como dijo Angie, y dijeron, está bien, eso es lo que se supone que debe hacer, pero ¿por qué está sucediendo toda esta otra cosa? Y solo causa mucha fricción y confusión. Así que es mucho mejor crear solicitudes de extracción separadas y problemas separados. Y sé que es más proceso, pero es mucho más fácil para que alguien más lo mire.

Y tienes muchos menos errores. Sí, definitivamente. Tenemos otra pregunta. Kevin preguntó, hablaste sobre desplegar. ¿Crees que las pruebas de extremo a extremo son primordiales para tener confianza en tu despliegue? No. ¿Cuál era? ¿Qué se requiere? Primordial es la palabra que se utilizó. Creo que es útil. Las pruebas de extremo a extremo, me encantan.

Creo que es útil. Las pruebas de extremo a extremo, me encantan. Creo que son muy útiles, pero lo son, no tendría confianza si hiciera una prueba de extremo a extremo si funcionara, que aún se desplegaría en producción correctamente. Aún querría ver CI completo, CD y querría verlo en un servidor de staging con tanto parecido al entorno y staging como lo es en producción, incluyendo SSL y certificados y variables de entorno y todo lo demás también. Tan cerca como puedas llegar allí.

Incluso entonces, creo que todos nosotros hemos enviado algo a producción donde con todo eso algo no salió bien. Siempre, siempre, siempre ten un plan de respaldo, siempre ten uno. Hablando de como un plan de respaldo, y ya hablamos un poco de eso, detectar buen código, detectar mal código. Gene preguntó, ¿recomiendas herramientas como SonarQube para medir la calidad o para ayudar a detectar buen y mal código? Creo que, como dijeron algunos de los otros panelistas anteriormente, mientras seas consistente con lo que tu definición de buen código es y cuál es tu configuración de escritura y cosas así, creo que eso es lo que importa. En mi opinión, no hay una herramienta que sea absolutamente perfecta para definir la calidad del código, pero la consistencia es realmente crucial aquí. Sí. Y creo que más que nada, proporciona un marco para que el equipo tenga una discusión sobre, ya sabes, ¿qué significa buen código de calidad para nosotros? ¿Cuáles son las reglas aquí?

A las que todos acordamos. Y de esa manera, eliminas mucho de este ir y venir y comentarios subjetivos de las revisiones de código, ¿verdad? Sacas todo eso del camino para que podamos enfocarnos en lo que realmente importa. Estoy 100% de acuerdo y tienes razón, las herramientas realmente no importan y la consistencia sí. Una cosa que me gusta de SonarQube en general es que en la empresa en la que he trabajado, crea métricas, ¿verdad? Y las métricas realmente no significan nada. Es solo un número. Pero la regla que teníamos en esa empresa, como parte de la consistencia, era nunca hacer daño. Así que cada vez que pones nuevo código, sea cual sea esa métrica, ese número, nunca debería bajar.

Esa suena como una muy buena regla a tener. Hemos hablado mucho sobre cómo entrar en la calidad ahora. Pero digamos que cambio de empresas, tomé un nuevo trabajo y la empresa es un poco anti-calidad. No ve el valor de la calidad, o como Johan preguntó, los otros miembros del equipo no ven el valor añadido de tener código de calidad. ¿Cómo manejarías esta situación? ¿Cómo convencerías a tu equipo y a tu jefe de que la calidad es algo en lo que deberías invertir tiempo? Creo que, si pudiera empezar, quiero decir, comenzaría y trataría de liderar con el ejemplo, por supuesto. Quiero decir, sabes, eso siempre va a ser algo personal impactante que puedes hacer y con suerte otros verán los resultados en lo que haces.

Algo así como una respuesta más grande y a largo plazo a esto es algo en lo que he estado trabajando recientemente. Y creo que es importante que los equipos hagan su mejor esfuerzo para básicamente poder decirle a la dirección qué tipo de impacto van a tener al enfocarse tiempo en abordar la deuda técnica, en escribir pruebas, en escribir más automatización. Si puedes contar una historia más grande alrededor de eso, por ejemplo, poder decir, sabes, creo que podemos acelerar nuestro proceso de desarrollo en un 20% si invertimos en un pipeline de CICD, ¿verdad? Estas son conversaciones que puedes tener que tienen un impacto muy claro y el negocio responde al impacto. Así que esas son las dos cosas que realmente recomendaría intentar hacer. Eso es, eso es todo ahí.

Esa es la clave. El negocio o simplemente no están en el, nuestras empresas no están en el negocio de simplemente hacer cosas porque, oh, esto es lo correcto a hacer tanto como queremos que lo hagan. Simplemente, escucha, simplemente no funciona. Bien, así que tienes que, tienes que proporcionar como estos son los beneficios. Como, podremos movernos más rápido, sabes, esto aumentará o disminuirá X por Y, pero tienes que dar estos, estas métricas y estos incentivos para lograr cualquier cambio que he encontrado. Y desafortunadamente, esto es muy común donde, sabes, la gente dice, no tenemos tiempo para esto, nosotros, sabes, no sabemos cómo, es un millón de excusas diferentes. He estado haciendo esto el tiempo suficiente como para poder aconsejar a la gente sobre como veo venir el tren. Como, estoy como, bien, continúas por este camino. Esto es lo que va a pasar a continuación. Y, sabes, trato de dar muchas advertencias y a medida que comienzan a ver que esas cosas suceden, entonces la gente comienza, bien, tal vez ella sabe de lo que está hablando y trata de ajustarse. Pero desafortunadamente, muchas veces tuvo que ser algún tipo de catástrofe, como perder dinero o algo así. Eso hace que la gente se involucre. Así que, todos ahí afuera que están pensando en esto, estos son puntos fantásticos y podemos contarle a la gente estas historias. Somos narradores. Eso es lo que hacemos, presentaciones. Hemos tenido estas experiencias. Pero en algún lugar de tu vida, alguien te dijo algo y simplemente lo ignoraste por completo.

Todos hemos hecho esto. Cuando era un niño, mi abuela me dijo que no pusiera mi mano en la estufa caliente. Me enojé y dije, sí, lo que sea, no está tan caliente. ¿Qué pasa? Puse mi mano en la estufa caliente y tuve una bonita gran quemadura en mi mano cuando era un niño. No lo haces de nuevo después de eso. Mi punto es, puedes decirle a alguien algo 20 veces. Pero hasta que realmente lo experimentes, no lo entiendes realmente.

Esas son las experiencias reales que nos impulsan. Lo que hago con las empresas, muchas veces, la última empresa con la que trabajé en esto tenía cientos de aplicaciones en producción, y en lugar de intentar realmente integrarlo todo de inmediato, lo que hicimos fue elegir un pequeño proyecto crítico, que tenía un alcance más pequeño. Hicimos esto con plena calidad de código, todas las cosas de las que estamos hablando aquí. Luego se puso en marcha. Fue la primera aplicación que esa empresa había puesto en marcha en muchos años que no tenía errores después de que se puso en marcha.

No tuvieron mantenimiento de 24 horas durante semanas y semanas y semanas después. Y mostrar esa tarjeta de puntuación a los ejecutivos fue como, OK, tal vez implementaste algunas características menos porque hiciste más calidad, pero nada se rompió. Y la experiencia del cliente fue excelente. Esa experiencia, al tocar esa estufa caliente y conocer todas las otras experiencias pasadas, fue mucho más valiosa que yo estar ahí diciendo, te lo dije. Sí, experimentar el dolor es a menudo el mejor maestro. ¿Crees que hay situaciones donde la calidad no importa? Como, mi experiencia es que a menudo, especialmente en la escena de startups, la calidad se tira completamente por la ventana al principio para simplemente impulsar el producto y ganar dinero.

Dicho esto, hay un, ya sabes, apuntas a la mayor calidad que puedas obtener. Y luego comienzas a averiguar cuál es la realidad del tiempo, el presupuesto, los recursos y todo lo demás que tenemos. Podemos hacer cosas para mitigar esto. Como mencioné antes, nada de lo que podamos hacer es convertirnos en mejores comunicadores con nuestros interesados comerciales. Así que podemos, si realmente podemos hablar sobre el valor de la calidad, y por qué necesitamos que no ocurra el aumento del alcance y mantener el alcance donde está, para que no sea un objetivo en movimiento. Estas cosas ayudan. Pero al final, sí, hay cosas que siempre se escapan, porque este es un mundo empresarial. Solo tienes que sopesar con mucho cuidado. Si esto se escapa, estas son las cosas que podrías estar arriesgando.

Estoy de acuerdo con eso. Creo que la única otra situación que puedo pensar donde la calidad o las pruebas no son como la cosa más importante sería si estoy desarrollando un prototipo que tengo la intención de desechar. Aunque, ten cuidado con eso, porque personalmente he estado en tantas situaciones donde ese prototipo nunca fue desechado. Así que ten en cuenta que ese es un patrón bastante común. ¿Tienes algunos prototipos que están en vivo, Jason? Cientos. Tenemos una pregunta más de la audiencia. Niels dice, Me encanta la distinción entre calidad funcional y calidad estructural. Por supuesto, debe hacer lo que el usuario necesita, pero ¿es sostenible por dentro? ¿Alguna opinión sobre eso? Creo que es difícil de responder para mí, pero intentaré romper el hielo y hablar un poco. Creo que todos tienen una opinión diferente sobre cómo deberías estructurar tu software.

En mi opinión, y tal vez esté feliz de estar equivocado, y que la gente no esté de acuerdo conmigo, no he visto ninguna ventaja clara de un patrón a otro, en su mayor parte. Creo que lo importante es que seas consistente, como hemos hablado hasta ahora. Siempre que hayas identificado qué patrón tú y tu equipo prefieren usar, y cómo estás construyendo el software, tómate el tiempo extra para construir algo de automatización para que las personas fuera de tu equipo o los nuevos integrantes del equipo puedan entender cómo contribuir a ese patrón y que no necesites una revisión manual cada vez. En mi opinión, eso es lo más importante, aparte de cualquier otro patrón que exista. No me suscribo a nadie en particular. Creo que una clave importante es que un amigo mío, Brian Holt, tenía un buen dicho, y no voy a estropear su dicho exacto, pero es básicamente, si no puedes automatizarlo, no vale la pena.

Entonces, si se te ocurre una regla, y voy a inventar una tonta, como abrazar llaves. A un buen amigo mío hace años decía, ¿debería la llave estar en la misma línea que el if o en la siguiente línea? Y yo digo, no me importa. Solo elige y haz una regla y automatízala, y todos lo haremos, ¿sabes? Y esto fue hace unos 10 años cuando los linters realmente no eran tan buenos. Pero ese es el tipo de cosa donde si puedes automatizar tus reglas, es mucho mejor y mucho más fácil tener este tipo de pautas y consistencia y mantener tu integridad estructural.

Sí, definitivamente. Pedro preguntó, ¿deberíamos incorporar refactorizaciones en nuestras historias actuales o crear tareas técnicas para esos tipos de refactorizaciones más extensas? Quiero decir, ya hablamos un poco sobre las solicitudes de extracción convirtiéndose en solo un charco de todo tipo de cosas que se están haciendo. ¿Cuáles son tus pensamientos sobre esta pregunta? En mi experiencia, realmente no obtienes ciclos dedicados a refactorizar algo. Como tienes que encajarlo donde puedas. Eso no significa que obtengas algunas características confusas, como, ya sabes, con un montón de refactorización. Pero me gusta abordarlo según sea necesario.

Por ejemplo, si estoy modificando una característica existente y encuentro que para implementar esto, una refactorización de algunas cosas sería agradable, entonces intentaré incluir eso. Así que tal vez a veces, si es realmente grande, lo dividiré. Así que dividiré la refactorización. Y esa es una cosa que impulso y luego haré la característica real después de eso. Para asegurarme de que todos estén de acuerdo con la refactorización antes de que agrupe todo esto en uno. Pero sí, creo que intentar encontrar tiempo dedicado para hacer refactorización y obtener esa aprobación de la gerencia es realmente difícil. Así que necesitas hacerlo según sea necesario. Sí, estoy totalmente de acuerdo.

Creo que, para construir sobre eso, incluso cuando se te pida implementar nuevas características o lanzar cosas por parte del negocio, haz tu mejor esfuerzo para incorporar estas refactorizaciones en tus cambios a medida que avanzas. Así que idealmente, una refactorización iterativa es el camino a seguir. Bueno, solo nos quedan unos minutos. ¿Hay algún último consejo, alguna última palabra de sabiduría que quieras compartir con la audiencia? Quiero decir, oh, lo siento. No, adelante, Angie. Está bien. Solo quería decir que, amigos, realmente necesitan salir del hábito de pensar en la calidad del código como esta tarea separada. Y esto debería ser algo que estás llevando contigo a medida que desarrollas tus características. Me rompe el corazón cuando la gente dice cosas como, oh, no tenemos tiempo o el cliente no quiere pagar por pruebas y cosas así. Cuando vas y compras un coche, no preguntas nada sobre, está bien, ¿necesito pagar extra por la prueba para ver si funciona? Esperas que esto esté incluido, ¿verdad? Lo mismo ocurre con nuestro software. La gente no está buscando un ítem separado que diga asegúrate de que la cosa por la que te estoy pagando realmente funcione. Esto necesita estar en nuestras mentes y ejercitarse con todo lo que hacemos en el desarrollo.

Sí, diría que mi pensamiento final no solo es que es bueno crear una guía de estilo, sino crear tu proceso desde el principio. Antes de que comiences un proyecto con un equipo, esto no toma horas. Esta es una reunión muy corta, generalmente de, ¿cuál va a ser nuestro proceso cuando creemos características? ¿Cómo decidimos sobre las características? ¿Y vamos a tener pruebas y CI, CD y configurar esas cosas lleva un tiempo? Sí. Pero las decisiones de hacer eso al principio de un proyecto son realmente importantes. Así que todos estén en la misma página y realmente puedan evitar más tarde, alguien como yo diciendo, Jason, ¿por qué no hiciste X? Bueno, nunca discutimos eso, bla, bla, bla. Esa es la clase de cosas donde te comunicas con tus compañeros de equipo desde el principio y es mucho más fácil y realmente ayuda a la calidad.

Mi opinión será controvertida, pero lo que diría es duplica tus estimaciones y busca ritmo sostenible ágil para cuando hables con el liderazgo, porque esta es básicamente la práctica de moverse a un ritmo sostenible en lugar de moverse en sprints y ajustes como solemos hacer en el campo del desarrollo de software. Tómate el tiempo para escribir software de calidad del que estés orgulloso y que estés seguro de que funciona. Es importante y estas son algunas maneras en las que puedes intentar colar eso. Y luego puedes desplegar con seguridad un viernes por la tarde y salir el fin de semana. Muchas gracias Jason, Angie, John. Fue un placer hablar contigo sobre calidad. Y ese es el final de este panel. Está bien. Gracias. Adiós. Adiós.