Cambiar una línea de código toma 6 días (2015)

(edw519.posthaven.com)

2 puntos por GN⁺ 2023-07-17 | 1 comentarios | Compartir por WhatsApp

La fábrica se está utilizando en menos del 10%.
La política de la empresa limita la creación de un backlog de más de 3 meses.
Si se cambia la política a 4 meses, el problema se resuelve.
Un cambio de configuración en software heredado requiere modificar una sola línea de código.
El proceso para implementar el cambio incluye enviar un ticket, completar las secciones requeridas y obtener la aprobación del director.
El cambio es urgente para evitar despidos.
El programador logra cambiar el código con éxito, pero surgen problemas debido a variables codificadas de forma fija y otros errores.
El código requiere revisión por pares y pruebas, y solo después puede pasar a producción.
El acceso al entorno de pruebas necesario se retrasa por problemas de permisos y disponibilidad.
Los registros de parámetros deben renombrarse y contar con una traza de auditoría.
El programador realiza los cambios necesarios y vuelve a enviar el código para revisión.
Las pruebas requieren un plan de pruebas adecuado que incluya los casos de prueba elegidos por el usuario y los resultados esperados.
Después de 6 días, el programa es aprobado para pasar a producción.

1 comentarios

GN⁺ 2023-07-17

El problema clave es negarse cuando los revisores piden cambios que afectan otras partes de la base de código.
Las pull requests enfocadas y la resistencia al scope creep son lecciones importantes.
El proceso de revisión de código puede estar lleno de observaciones difíciles y comentarios triviales.
Es posible que el equipo de seguridad no responda rápido a las solicitudes de permisos.
El título del artículo puede ser engañoso, y hubo mejoras adicionales durante esos 6 días.
Un cambio de una sola línea puede provocar consecuencias inesperadas.
El proceso de revisión de código puede convertirse en un gatekeeper y retrasar el avance.
Permitir comentarios sin bloquear los commits puede llevar a un desarrollo más eficiente.
Pasar de un equipo que hace revisiones de código formales a uno que no las hace puede ser refrescante y empoderador.
Hay diferencias en la forma de gestionar a los trabajadores de fábrica y a los desarrolladores de software.
Retener cambios con base en ideales cambiantes del equipo es disfuncional.
El problema está en el proceso de la empresa, no en la revisión de código en sí.