DESARROLLADOR

Elogie al desarrollador que eliminó el código

Estamos felices de agradecer a los desarrolladores de código abierto que contribuyen agregando nuevas líneas de código, pero ¿qué pasa con aquellos que realizan la misma o más importante tarea de eliminar el desorden?

istock 1147195672 1
Imagen: iStockphoto/Viktoriia Hnatiuk

Bienaventurados los encargados del código de los proyectos de código abierto. Pero las personas que eliminan son más felices porque son el reino del código limpio y eficiente.

Ningún conjunto de escrituras contiene esta sabiduría, pero eso no lo hace menos sabio. Como afirma el desarrollador Dj Walker-Morgan: «Para mí, las líneas eliminadas son la última quema de la tierra que ha construido la deuda técnica». Eliminar líneas de código requiere una familiaridad íntima con el código base, por lo que refleja el potencial del proyecto (no)ingeniería. Del mismo modo, como dice Charity Majors, «Los mejores ingenieros senior con los que he trabajado son los que trabajan más duro sin tener que escribir código nuevo».

¿Hay alguna forma de celebrar adecuadamente a los que borran o escriben menos para aportar más?

Mirar: Cómo construir una carrera de desarrollador exitosa (PDF gratuito) (República tecnológica)

Comprenda realmente la deuda técnica

Si bien la deuda técnica a menudo se describe como el resultado de «tomar decisiones simples pero subóptimas durante el desarrollo de software», me gusta el consejo de Dormain Drewitz de que «todo código es deuda técnica». ¿Por qué? Porque es fácil clasificar negativamente las decisiones de código y la basura resultante en retrospectiva, pero puede que no haya una mejor opción al escribir código. De hecho, era probablemente la mejor opción absoluta en ese momento.

LEER  Intranet ampliamente utilizada en los lugares de trabajo de TI

Pero eso no significa que deba quedarse.

Sin embargo, con la acumulación de «deudas» (dejando de lado por un momento si te gusta o no la palabra, y si la palabra está incompleta, como argumenta acertadamente Rachel Stephens de RedMonk), el consejo de Martin Fowler sobre cómo solucionarlo resuena:

[U]La mejor manera es pagar el principal gradualmente, de la forma en que solemos manejar la deuda financiera. En la primera función, pasaré unos días más eliminando algunos trastos. Eso puede ser suficiente para reducir las futuras tasas mejoradas a un día. Todavía lleva más tiempo, pero al eliminar este desorden puedo reducir el costo al cambiar este código más adelante. El mayor beneficio de las mejoras incrementales como esta es que naturalmente significa que dedicamos más tiempo a eliminar aquellas áreas de nuestro código base que modificamos con frecuencia, que son las áreas de nuestro código base que más necesitamos eliminar.

Realmente me gusta cómo Sarah Mei describe la deuda técnica como «desordenada» (como una casa desordenada). Para aquellos que piensan que esta confusión/deuda puede eliminarse migrando a una arquitectura de microservicios, este no es el caso. Realmente no. Mayo escribió: «[Y]Terminas con una pequeña casa abarrotada y una pila desordenada de unidades de almacenamiento, y aún no puedes encontrar nada. Siguiendo el consejo de Fowler, la solución ideal para las deudas/el desorden podría ser trabajar en aquellas áreas que más contribuyen.

Lo que nos lleva de nuevo a cómo confirmar correctamente esas eliminaciones.

Otra forma de contribuir

0986a6a3 29ab 4b4a 9f26 13884e97d510
Imagen: Matt Asay

Si observa las tablas de clasificación de Cloud Native Computing Foundation (CNCF) para Kubernetes u otros proyectos, es fácil ver quién contribuyó con el código: en ese menú desplegable, no se menciona «líneas de código eliminadas» o, después de las especialidades, «Ingenieros». que trabajan duro para no agregar líneas de código». En cambio, hacemos un seguimiento de aquellos que contribuyen, confirman código nuevo. Eso es valioso, pero me preocupa que no capture grandes áreas de valor para proyectos de código abierto.

También hace un mal trabajo al medir el código importante en comparación con solo la cantidad de código. Esta es una medida difícil en la práctica, pero también es importante. Pero volvamos al arte de eliminar código.

Como me dijo mi antiguo colega Henrik Ingo: «En los 3 años que he estado trabajando en MongoDB, he eliminado más filas de las que he agregado». Motive a sus compañeros de equipo para que agreguen miles». Es posible que los mejores ingenieros no estén en la parte superior de la lista de colaboradores porque sus contribuciones tienen que ver con la eliminación inteligente del desorden, no con la adición de código. (Hace años, el equipo de ingeniería de Yelp escribió sobre la herramienta que construyeron, Undebt, para «realizar refactorizaciones de código automatizadas masivas». No he visto una actualización, y no he visto ningún éxito con otros usuarios).

Me encantaría saber cómo usted o su organización encuentran y promueven los eliminados. ¿Hay alguna manera de que podamos hacer esto también para proyectos de código abierto? Sé que crear tablas de clasificación siempre es una ciencia imperfecta (o tal vez sin sentido), pero mientras las tengamos, me gustaría ver más enfoque en aquellas que ayudan a eliminar la deuda/desorden técnico en nuestro código colectivo sobre las personas.

LEER  Los enrutadores de código abierto hacen que todos los demás enrutadores miren atrás de los tiempos

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba