Código y el arte del mantenimiento de motocicletas: errores típicos de los novatos

Dicen que programar es fácil, es como andar en bicicleta. Pero en realidad, programar es como una motocicleta, una motocicleta muy potente y rápida. Al programar, al igual que al andar en bicicleta, hay que ser responsable y consciente para mantenerse en el sillín y duplicar eso para ser un ganador. De hecho, los motociclistas y los programadores comparten los mismos errores de novatos: los neófitos suelen centrarse en herramientas rápidas y potentes y trucos innovadores, creyendo que eso por sí solo define a un verdadero maestro. Esta mentalidad se debe en parte al "efecto Dunning-Kruger", según el cual los novatos no logran comprender la complejidad y la importancia de su profesión. Afortunadamente, con la experiencia, incluso el principiante más ferviente se da cuenta de que el arte de programar implica mucho más que simplemente seleccionar el algoritmo óptimo. En este artículo, quiero compartir mis pensamientos sobre lo que realmente importa para un programador y lo que tanto los desarrolladores nuevos como los experimentados deben recordar al crear software y escribir código.

La legibilidad es más importante que el rendimiento, pero no siempre

¿Con qué empiezan los motociclistas novatos? Números y artilugios. Potencia, par motor, piezas de rendimiento para ganar milisegundos teóricos en un cuarto de milla... Como si estuvieran a punto de llegar a la parrilla de salida de MotoGP. Mientras tanto, su tarea principal es simplemente aprender a conducir de forma segura. De manera similar, los desarrolladores principiantes a menudo se obsesionan con el rendimiento del código cuando no es necesario. Los artículos que debaten si `dict()` o `{}` son más eficientes en Python, o los pros y contras de usar frameworks a pesar de su potencial para reducir el rendimiento, alimentan esta obsesión. Si bien comprender las complejidades de su lenguaje de programación es beneficioso y, a veces, crucial, como en el software para aviones, robots de negociación de acciones o dispositivos médicos, no siempre es fundamental para la mayoría de los programas que creamos a diario. Incluso si está trabajando en software crítico para el rendimiento, es esencial saber qué partes del código requieren un alto rendimiento y cuáles no.

Sin embargo, lo que siempre importa es la legibilidad del código. Numerosos estudios y encuestas confirman que los desarrolladores pasan más tiempo leyendo y entendiendo el código que escribiéndolo. Por ejemplo, el estudio "Sé lo que hicisteis el último verano: una investigación sobre cómo los desarrolladores emplean su tiempo" Descubrió que solo el 4% del tiempo que se pasa en un IDE se utiliza para editar código. Informe de tiempo de código global , basado en una encuesta a más de 250.000 desarrolladores, reveló que los encuestados dedican solo unos 52 minutos al día a escribir código de forma activa. El resto del tiempo se dedica a debatir y planificar el proyecto, y unos 41 minutos se dedican a leer el código en el IDE y la documentación del proyecto.

En la mayoría de los casos, nuestro objetivo es crear un producto que se pueda mantener y que no requiera un soporte complejo y que prospere en un entorno competitivo. Esto no significa que podamos ignorar por completo el rendimiento; debemos encontrar un equilibrio en el que la capacidad de mantenimiento y el rendimiento coexistan. Si se necesita un código de alto rendimiento, podemos optimizar las secciones lentas después del lanzamiento del proyecto.

También hay que tener en cuenta que los compiladores e intérpretes evolucionan, pero el código sigue siendo el mismo. Un fragmento de código mágico, superoptimizado y escrito para una versión del compilador puede resultar irrelevante para otra. Además, los desarrolladores futuros (o incluso usted) necesitarán trabajar con ese código. Entonces, ¿cuándo debemos sacrificar la legibilidad por el rendimiento?

Para identificar cuándo priorizar el rendimiento por sobre la legibilidad es necesario identificar los cuellos de botella en la aplicación:

• Creación de perfiles de la aplicación : si la creación de perfiles revela que secciones de código críticas específicas afectan significativamente el rendimiento, optimizar estos fragmentos podría justificar una legibilidad reducida.

• Pruebas de carga : simular cargas elevadas puede ayudar a identificar cuellos de botella en el rendimiento antes de que se conviertan en problemas del mundo real.

• Análisis de comentarios de los usuarios : recopilar comentarios de los usuarios puede resaltar áreas con bajo rendimiento.

• Registro y supervisión : el análisis de los registros y las métricas de ejecución puede identificar áreas problemáticas durante el funcionamiento real de la aplicación. Esta etapa puede revelar problemas inesperados, como un uso inadecuado de la API que provoque problemas de rendimiento.

• Herramientas de análisis de código estático : algunas herramientas pueden sugerir mejoras de rendimiento durante las revisiones de código. Ejecutar estas herramientas automáticamente durante las revisiones de tareas es una buena práctica.

  
  

Estos consejos pueden ayudar a identificar los puntos débiles de su aplicación, lo que le permitirá centrarse en las optimizaciones necesarias. Según mi experiencia personal, es menos probable que estas optimizaciones involucren construcciones de lenguajes exóticos y es más probable que involucren la optimización de interacciones con bases de datos o el uso de API externas.

Documentar ayuda a comprender el trabajo realizado

En la carretera, una de las habilidades de seguridad cruciales es ser predecible y, asimismo, leer las intenciones de los demás. En la codificación, al igual que en la conducción, no se puede leer directamente las mentes de otras personas. Sobre dos ruedas, hay que notar movimientos sutiles y predecir lo que harán los demás al segundo siguiente. Los programadores poseen (pero no siempre emplean) una herramienta poderosa para reemplazar la telepatía: el papeleo. La mayoría de los desarrolladores coinciden en que la documentación es crucial para un proyecto, como lo demuestran encuestas como la Encuesta para desarrolladores de Stack Overflow 2023 , donde el 90,36% de los encuestados utiliza documentación técnica con regularidad. Sin embargo, a menudo no pueden encontrar todas las respuestas allí, y recurren en su lugar a Stack Overflow (82,56%) y a varios blogs (76,69%). Otro estudio, Microsoft Research: La vida cotidiana de los desarrolladores de software , muestra que los desarrolladores dedican entre el 1 y el 2 % de su día a la documentación, y el 10,3 % de los encuestados pierde mucho tiempo debido a documentación deficiente o desactualizada.

La documentación puede adoptar muchas formas, desde descripciones detalladas de proyectos en sistemas como Confluence hasta comentarios de código y sitios web de descripción de proyectos generados de forma automática o semiautomática. Incluso puede ser tan simple como un archivo README en el directorio raíz del proyecto. Independientemente del formato, el proceso de creación de documentación va mucho más allá de simplemente transmitir información sobre cómo funciona el producto. Este proceso nos hace repensar lo que hemos hecho , lo que a menudo puede conducir a mejoras en la API y la arquitectura general. A menudo me he dado cuenta, mientras documentaba la funcionalidad que había creado, de que podría resultar difícil trabajar con ella, y he encontrado formas de solucionarlo.

Es importante recordar que mantener la documentación siempre requiere un esfuerzo significativo, especialmente si el proyecto se encuentra en una etapa en la que cambia con frecuencia. En tales casos, debe sopesar todos los riesgos y considerar cuidadosamente qué lógica documentar. Si su proyecto ha alcanzado una etapa madura, una buena documentación traerá más beneficios que desafíos: los nuevos desarrolladores pueden incorporarse y ganar impulso más rápido, mientras que los empleados con más tiempo pueden descubrir rápidamente cómo funcionan ciertas características. Además, la documentación con una buena función de búsqueda en un proyecto grande con muchos equipos puede evitar la duplicación de funciones.

No es ninguna vergüenza contarle a los demás lo que estás haciendo

El uso de las luces de giro es la forma más básica de ser un conductor predecible. De manera similar, comentar el código es probablemente la forma más fácil y directa de decirles a los demás lo que estás haciendo. Y, al igual que con el uso de las luces intermitentes, no te hace menos genial. Sé que existe la creencia común de que los comentarios son innecesarios porque el código debería explicarse por sí solo. Pero no, no estoy completamente de acuerdo con eso. El código de calidad a menudo se puede entender intuitivamente gracias a una buena denominación de variables y funciones, una estructura clara y el cumplimiento de los principios del código limpio. Sin embargo, incluso en esos casos, los comentarios bien pensados pueden proporcionar información invaluable.

Los comentarios desempeñan un papel crucial cuando se trata de algoritmos complejos o soluciones que requieren un contexto adicional para comprenderse. Pueden explicar el "por qué" de un enfoque, que no siempre es obvio a partir del código en sí. Esto es particularmente importante cuando el código está optimizado para el rendimiento, pero sus intenciones y lógica no son inmediatamente claras. Los comentarios también pueden ayudar a reconsiderar si el algoritmo elegido avanza en la dirección correcta.

Los comentarios son una gran ayuda en casos de lógica empresarial compleja o requisitos específicos de un proyecto que pueden no ser obvios para los nuevos miembros del equipo o en el caso de un soporte de proyecto a largo plazo. Ayudan a retener el conocimiento dentro del equipo y facilitan la transferencia de proyectos entre desarrolladores.

Por supuesto, es esencial evitar comentarios excesivos que digan cosas obvias o que resulten obsoletos y engañosos. Su propósito es garantizar la claridad y facilitar la comprensión del código, no atiborrarlo de información innecesaria.

Pruebas: una herramienta para la comprensión y verificación del código

Bien, ahora imaginemos que finalmente aprendimos a andar en bicicleta y ahora queremos probar suerte en una pista de carreras real. Bien, pronto descubriremos que las carreras reales no se tratan solo de poder "acelerar a fondo". Implican entrenamiento, pruebas y ajustes finos de la máquina para que se adapte a nuestros hábitos y condiciones de carrera. Lo mismo se aplica al código: debe probarse, probarse y corregirse a fondo si es necesario antes de que pueda lanzarse a dar una vuelta de verdad. Por lo tanto, es crucial abordar las pruebas de código con la máxima responsabilidad. Las pruebas a menudo se consideran simplemente una herramienta para detectar errores, pero su función es más amplia:

• Detección de errores y defectos : las pruebas identifican errores y comportamientos imprevistos antes de que el producto llegue al usuario, mejorando la calidad y reduciendo los problemas del usuario.
• Comprensión del código : la creación de escenarios de prueba requiere una comprensión profunda de la estructura y la funcionalidad del código, lo que promueve una mejor comprensión de la lógica y la interacción del programa.
• Suplemento de documentación : Las pruebas pueden servir como ejemplos de uso de funciones y métodos, ayudando a localizar información sobre la funcionalidad del proyecto y ayudando a los nuevos especialistas al proporcionar casos de uso reales.

La realización de pruebas eficaces es fundamental para producir código de alta calidad, fiable y comprensible. Sin embargo, al igual que la documentación, las pruebas pueden requerir muchos recursos, en particular en las primeras etapas del proyecto. Es esencial encontrar un equilibrio entre la necesidad de realizar pruebas y las limitaciones de tiempo y recursos.

También es obvio que la cobertura de pruebas absoluta para códigos complejos es simplemente inalcanzable. Por lo tanto, los desarrolladores deben priorizar las pruebas de funciones clave y secciones críticas del código, y saber cuándo detenerse para evitar un ciclo de pruebas interminable.

Ama tu código como amas a tu amigo y cuídalo.

Por último, ninguna motocicleta puede ser fiable sin un mantenimiento adecuado. Hay bastantes personas que descuidan este aspecto de la conducción, pero se inventan historias (que van desde lo divertido a lo aterrador o lo triste) de las que definitivamente no queremos ser parte. En el mundo de la programación, al igual que en el motociclismo, el mantenimiento del código no es solo una recomendación sino una necesidad, especialmente para proyectos a largo plazo. La falta de mantenimiento y actualizaciones conduce a la obsolescencia del producto y a vulnerabilidades de seguridad.

Cuando el código no se actualiza para que sea compatible con los últimos compiladores e intérpretes, actualizarlo puede volverse cada vez más difícil (y de hecho lo será). Si está desarrollando una aplicación de escritorio o móvil, su producto podría dejar de funcionar con las nuevas versiones del sistema operativo. En el caso de un sitio web, podría dejar de funcionar debido a herramientas y tecnologías obsoletas. El problema más simple podría ser un certificado de seguridad vencido o un software desactualizado para su renovación.

Las actualizaciones y refactorizaciones periódicas también son fundamentales para mantener la legibilidad del código. Esto permite que el proyecto sea manejable y simplifica los cambios y las incorporaciones de funciones futuras.

En resumen, ama tu código y dedícale tiempo, pero no en exceso, o acabarás como el protagonista de “El teorema cero”. ¡Buena suerte!