Compilar | Zheng Liyuan
Listado | CSDN (ID: CSDNnews)
"Esta es una historia real."
Sí, leyó bien, "tardó 6 días en cambiar 1 línea de código" es algo real, incluso la línea de código modificada solo cambió 1 byte, es decir, de "3" a "4".
Presidente: O despedir personal o mejorar la eficiencia
Philip (presidente) : Descubrí que la tasa de utilización de nuestra fábrica era un 10 % más baja y, en ese caso, comenzamos a producir más pedidos atrasados o tuvimos que despedir trabajadores. Busco más mantener a todos ocupados, acumular inventario y prepararme antes de la temporada alta. ¿Cómo crees que deberíamos hacer esto?
Lee (Gerente de Operaciones) : La política de la compañía limita nuestro backlog a 3 meses, si cambia la fecha límite a 4 meses, tenemos mucho trabajo por hacer.
Philip : Bien, entonces, ¿cómo lo implementamos ahora?
Lee : No estoy seguro, pero creo que tenemos que cambiar una configuración en el software antiguo.
David (Director de TI) : No hay problema, debería ser un cambio de una línea en el programa principal. Complete un ticket y envíelo a Servicios de TI.
Judy (Administradora de TI) : asigné el número de ticket 129281 a esta solicitud, pero en este momento la sección sobre el impacto comercial debe completarse y aprobarse por el director.
David : Este es el pedido de Philip, si no lo atendemos de inmediato, tendremos que hacer despidos.
Judy : OK, entonces llenaré esta parte yo mismo y priorizaré este ticket.
2 días después
David : ¿Qué pasa con 129281?
Judy : Es la primera mejora en la cola de desarrollo, después de 14 informes de errores.
David : Olvídate de la cola, márcalo como urgente y envíaselo a Ed de inmediato.
En 1 hora
Ed (Programador) : En la línea 1252 del módulo ORP572, cambié la variable codificada de forma rígida MonthsOfBacklog de "3" a "4". Realicé con éxito las pruebas unitarias y realicé la prueba por lotes dos veces, esperando un aumento del 10 % en la cola de trabajo operativo. El cambio está en su lugar, lo envié para la revisión del código y me trasladé a Homer para la prueba de aceptación del usuario.
Shirley (revisión de código) : la política actual de la empresa prohíbe el uso de variables codificadas y debe documentar esto en el archivo de parámetros. Además, hay dos comandos de depuración antiguos, un mensaje de advertencia para variables no asignadas y una identificación de empleado codificada, todo lo cual tuvo que corregirse antes de que este módulo entrara en producción.
Ed : Tsk, problemas.
Shirley : Entendido, pero así son las cosas. Ahora que se le asignó trabajar en ORP572, debe corregir los errores existentes que violan la nueva política de la empresa, y no puedo dejar que su solución pase por revisión.
2 horas después
Ed : Bien, listo. Acabo de volver a enviar para la revisión del código.
Julie (pruebas de TI) : Homer no está disponible actualmente para las pruebas de aceptación del usuario, ya que Fred está realizando pruebas controladas para el cierre contable de fin de mes, puede usar a Marge en su lugar.
Ed : No tengo acceso a Marge.
Julie : Entonces contacta a Joe en el departamento de seguridad de TI, él te dará permiso.
2 horas después
Joe (Seguridad de TI) : No puedo darte acceso a Marge sin la firma de David, pero está de viaje de negocios, ¿por qué no esperas hasta el lunes?
Ed : No, Philip tiene que ocuparse de ello inmediatamente, pedirle que apruebe el permiso.
Shirley : Su nuevo registro de parámetro "MoonsOfDemand" necesita ser renombrado, porque los programadores en el extranjero pueden no entender lo que significa. Además, debe tener un registro de auditoría de los cambios.
Ed : ¿Eh? ¿Qué normativa lo dice?
Shirley : Las regulaciones actuales no establecen claramente que el equipo extranjero actualizó el wiki con 3 meses de retraso, pero les aseguro que todos los nuevos registros de parámetros deben cumplir con los nuevos requisitos de nombres y mantener registros de auditoría.
1 día después
Ed : Cambié el nombre del registro de parámetros "MonthsOfDemand" a "SelectedMonthsOfBacklogDemand", agregué el módulo PAR634 para mantener este registro y su seguimiento de auditoría, y lo envié a revisión de código.
Tony (Pruebas de TI) : Veo 129281 en Marge, pero no tengo un plan de prueba.
Ed : Simplemente ejecute la forma antigua y la nueva, y observe el aumento total en el informe de horas de la orden de trabajo.
Tony : ¿Este es tu plan de prueba? No, esto afecta todo en la fábrica. Debo tener el caso de prueba seleccionado por el usuario, el resultado esperado, la ejecución de la prueba registrada y obtener la confirmación del usuario.
2 días después
Philip : David, dile a Tony que ponga en producción el programa de Ed de inmediato.
David : Está bien, jefe.
En resumen:
Tiempo total empleado : 6 días.
Líneas críticas de código cambiadas : 1 línea.
Bytes de código clave cambiados : 1 byte.
Analgésicos para el dolor de cabeza tomados : 24 pastillas.
Horas de furor en Hacker News : 14 horas.
Programador testifica en línea: "Este tipo de cosas son absolutamente ciertas"
En otras palabras, la fábrica tardó 6 días en modificar solo 1 línea de código, o incluso 1 byte, no se sienta ridículo, porque el comienzo de este incidente decía: Esta es una "historia real".
Al mismo tiempo, muchos programadores de Hacker News también confirmaron la autenticidad de esta situación:
▶ “Es absolutamente cierto que el proceso de revisión de código de la mayoría de las empresas está lleno de críticas y comentarios mezquinos”.
▶ "Una anécdota: después de trabajar en un equipo con revisiones formales de código durante algunos años, me mudé a una empresa donde no había revisión de código, es decir, todos eran libres de comprometerse/fusionarse en cualquier rama. Tenía sentimientos encontrados cuando me uní a la empresa por primera vez, pero obviamente también me hizo sentir muy fresco y motivado, así que después de unos días era muy productivo".
▶ "Las revisiones de código tienen buenas intenciones, pero algunos guardianes rechazan todo por razones triviales. Siguen diciendo que se trata de mantener la "calidad del código", pero lo peor que puede hacer es mantener el código con errores después de que se hayan solucionado los errores, o retrasar el lanzamiento de funciones para que nadie pueda probarlas".
Entonces, como programador, ¿también resuenas con este tipo de cosas? Bienvenido a dejar un mensaje en el área de comentarios para compartir su experiencia.
Enlaces relacionados:
https://edw519.posthaven.com/it-takes-6-days-to-change-1-line-of-code
https://noticias.ycombinator.com/item?id=36746014
