¿Qué diferencia a un programador senior de un programador junior? Muchos dirán que es la capacidad de evaluar las consecuencias de un cambio de código. En realidad, es la pérdida de la despreocupación y un conjunto de miedos regresivos.
Los miedos de las personas mayores
“¿Puedes cambiar esta condición en el código? ¿Qué hace falta?”
Antes era mucho más rápido a la hora de cambiar un algoritmo, modificar un parámetro de una función, crear o destruir flujos, etc. El objetivo era, en primer lugar, hacer lo que pedía el cliente y, sólo en segundo lugar, garantizar que el código fuera mantenible o que la elección realizada fuera la mejor entre una serie de opciones más o menos consideradas.
Luego, fui creciendo y comencé a usar pruebas para entender si mi código seguía siendo bueno después de un cambio. Comencé a escribir documentación para entender por qué había razonado de cierta manera y comencé a hacer revisiones de código para mejorar la comprensión y el mantenimiento del código.
Este nuevo enfoque “complicado” hizo que mi trabajo fuera más complejo, o mejor dicho: alargó los procesos que, a partir de una solicitud, conducían a la solución final. Un cambio que antes hacía en 10 minutos ahora me lleva un día entero porque tengo que evaluar todos los impactos que puede tener ese cambio, ejecutar todas las pruebas automatizadas, realizar algunas pruebas manuales donde la automatización no era posible, escribir la documentación, fusionar con el código principal, esperar las pruebas de compilación e integración, verificar que todo funcione y, finalmente, declarar el problema resuelto, esperando no haberme olvidado de nada.
Pasan los años y es inevitable que el niño despreocupado que una vez envió código sin pruebas evolucione hasta convertirse en el desarrollador constante que corrige cuidadosamente los espacios al agregar código a la rama principal (no, ya no se usa «master»).
What was once a happy and enthusiastic "yes,"
grows into a "yes, but I also do this,"
slowly becomes a "maybe,"
until it becomes a "no"
or worse, a "it depends."Lenguaje del código: JavaScript ( javascript )
Los programadores senior no son malos
No es por malicia que todo esto sucede, sino por la conciencia de lo que gira en torno a una sola línea de código. Es la conciencia del error o de los impactos de un cambio y de una regresión extensa que ha socavado con demasiada frecuencia la certeza de que una sola condición se puede cambiar sin problemas. Esto no significa que no se deban realizar cambios ; solo significa que los impactos siempre deben evaluarse para no crear problemas mayores que los que se intentan resolver. A menudo, a medida que uno envejece, los impactos se multiplican en la mente del programador.
Pensemos en el ciclo de vida del software y en su diseño. Al principio, desarrollar un producto es relativamente fácil: vemos nuestro objetivo, tenemos una idea de cómo lograrlo, nos aseguramos de que los clientes y las partes interesadas estén satisfechos y, si tenemos suerte, logramos crear un equipo cohesionado tanto a nivel técnico como humano. Esto no siempre es así porque, a veces, un solo caso atípico puede desestabilizar a todo un grupo. Una vez que se logra este objetivo, cuando se necesita un cambio, todos los miembros del equipo están alineados y son conscientes de lo que se debe hacer.
A medida que se va saliendo de esta fase de euforia colectiva y de fase creativa, el equipo de desarrollo empieza a cambiar de forma. Al mismo tiempo, el cliente reduce el presupuesto porque entra en una fase de mantenimiento y, si no se presta la debida atención, el dominio del producto empieza a perderse.
No, it's certainly not the tests that can govern the product,
but the minds that conceived it.La rotación de proyectos es un proceso inevitable, a menos que te encuentres en un iglú en medio del poste, sin conexión a Internet, y los pobres programadores que desarrollaron el proyecto ni siquiera puedan enviar un currículum a menos que lo adjunten a un sello (aunque siempre existe la posibilidad de que el programador se dedique a la pesca, su gran pasión reprimida por el código).
Cuando un miembro del equipo cambia, se pierde parte del conocimiento del producto y se empieza a perder el dominio del mismo. En consecuencia, cada intervención se vuelve más costosa, prolongada y riesgosa.
¿El mantenimiento del proyecto cambia las reglas?
En un ciclo de vida normal de un producto, algunas partes requieren actualizaciones frecuentes, mientras que muchas otras, debido a la maduración, la falta de solicitudes o la estabilidad, no necesitan cambios. Realizar cambios con poca frecuencia disminuye el conocimiento del programador sobre el código que escribió. Esto significa que es probable que la persona que escribió esas líneas de código hace dos años no las recuerde y necesite revisarlas para recordar los procesos que llevaron a su creación.
Cuanto más vertical sea el cambio, más difícil será recordar el motivo detrás de él: es posible que no recuerde por qué utilizó un parámetro en lugar de otro dentro de una conexión a un recurso externo , por qué utilizó una suite de cifrado en lugar de otra, o tal vez tenga una rama abierta durante meses, esperando la verificación de un cliente sobre una característica urgente que de repente se volvió menos importante, pero ahora necesita fusionarla en una línea base con 400 empujes más, y se pregunta si tiene más sentido comenzar de nuevo o aplicar los cambios a una rebase.
Entre este tipo de intervenciones se encuentran las tareas diarias, los cambios de características, las correcciones de errores, las solicitudes de nuevas características, las correcciones de errores introducidas al corregir un error, el código introducido por un colega con poco conocimiento del producto, los cambios de comportamiento introducidos por una actualización o un nuevo componente que requiere cambios de código e introduce una anomalía indirecta.
Tú, que escribiste ese código, no lo recuerdas. Entiendes que, ante varios cambios, la modificación a realizar es mayor de lo previsto, pero debes averiguar cómo hacerlo porque recuerdas la lógica detrás del código anterior y entiendes que no es un cambio sencillo. Imagina a alguien que tiene que arreglar el mismo código y lo toca por primera vez.
Como dijo Heráclito:
No man ever steps in the same river twice,
for it's not the same river and he's not the same man.Lenguaje del código: JavaScript ( javascript )Esta afirmación se puede aplicar fácilmente al código: cada cambio, por pequeño que sea, altera el código y el contexto en el que existe, que es diferente del contexto en el que fue creado, y la persona también es diferente de la persona que escribió ese código.
Caso de uso de un conocido banco italiano
Por un momento, imagina ser un programador senior en un “banco aleatorio”, donde te dicen que procedas a una actualización del sistema y la actualización del firmware relacionada, asegurándote de que no causaría ningún daño y que la actualización se haría en producción. Habiendo visto este tipo de intervenciones muchas veces en tu vida, lo primero que te viene a la mente es ejecutar una prueba. Sin embargo, no existe un entorno de prueba que refleje exactamente el entorno de producción, tanto en términos de escala como de casos de uso . Desaconsejas la actualización masiva, pero el proveedor de la solución asegura que no habrá ningún problema. El departamento de seguridad te informa de que la actualización debe implementarse en una fecha determinada para cumplir con las reglas de la empresa y que, en caso de problemas, es posible una reversión.
A regañadientes, aceptas, en parte impulsado por el hecho de que “trabajamos con metodología ágil y debemos estar preparados para el cambio” y que “no siempre podemos ser negativos”.
Disruptions to online services access (such as app, Invest app, Internet Banking, and Smart Business)
occurred following the installation of an operating system update
and related firmware update that led to an unstable situation.
We sincerely apologize and greatly appreciate your understanding.Lenguaje del código: JavaScript ( javascript )Una actualización “simple” del sistema operativo y del firmware provocó una situación inestable durante cinco días.
Claramente, en este escenario hipotético, el problema no fue la actualización en sí, sino la falta de pruebas, la ausencia de un entorno de pruebas que cubriera la producción, la falta de una reversión inmediata y la ausencia de un plan de recuperación ante desastres o la subestimación del riesgo.
¿Cómo es la percepción de los cambios fuera del proyecto?
A menudo, quienes están fuera del proyecto tienen una percepción completamente diferente del desarrollo de software y presionan para que se realicen cambios lo antes posible.
I need it yesterday.Esta frase es un clásico, pero muchas veces no se entiende que un cambio, incluso uno simple, puede acarrear una serie de problemas que van mucho más allá del cambio en sí.
I only asked to change one condition, why is Mario causing me all these problems?
Now I'll assign the task to Bruno, who will solve it in 2 minutes.Existen situaciones dentro de los proyectos que permiten modificar el código muy rápidamente, y otras situaciones en las que un cambio, incluso uno simple, puede requerir mucha reflexión: incluso si se trata de unas pocas líneas de código o incluso de una única condición adicional. Cada programador aborda el cambio de forma diferente en función de su experiencia, conocimiento del producto y comprensión del código . Cuanto más experimentados sean los programadores con el producto, más probabilidades hay de que evalúen cuidadosamente el cambio porque son conscientes de las posibles consecuencias. Cuanto menos sepa un programador sobre el producto, más probabilidades hay de que realice cambios rápidamente.
Conclusiones: convertirse en un programador senior
Cada cambio, por simple que sea, puede generar problemas de rendimiento, regresión, problemas de seguridad, desafíos de mantenimiento, dificultades de comprensión del código, lagunas en la documentación, problemas de pruebas y problemas de implementación.
Las modificaciones externas al proyecto pueden crear los mismos problemas: actualicé el sistema operativo, actualicé un controlador, actualicé el firmware y ahora nada funciona.
La presión sobre un programador aumenta progresivamente con el tiempo porque crece la conciencia de todo lo que puede salir mal y de lo difícil que es resolver un problema una vez que ocurre.
Esto puede llevar a situaciones en las que un programador senior se niega a realizar un cambio porque sabe que los riesgos son demasiado altos o porque sabe que el cambio requeriría demasiado tiempo y recursos para realizarse correctamente.
La próxima vez que veas a un programador que lleva muchos años trabajando en el mismo código y no quiere modificarlo, y te advierte de cada alteración interna o externa del proyecto, no pienses en él como un incapaz, sino como un individuo consciente . Utiliza sus consejos para evitar el colapso del proyecto y sopesa cuidadosamente los riesgos y beneficios de cada cambio porque, como dijo Isaac Asimov:
No sensible decision can be made any longer without taking into account
not only the world as it is, but the world as it will be.