Comencé a trabajar en una gran empresa de software y fui asignado a un proyecto que tiene más de un millón y medio de líneas de código. Es parte de un conjunto de programas que se vende a los clientes (no es un proyecto interno) y el código fuente se puede comprar si lo desean (aunque dadas las tarifas adicionales asociadas con esto, esto parece raro). Han estado haciendo diseño de software durante años y sus productos actuales están destinados a continuar en el futuro previsible.
Para mi sorpresa, el millón y medio de líneas de código carecen casi por completo de documentación. Además, hay algunas áreas de código que son increíblemente complicadas de seguir o que podrían usar algunas refactorizaciones para que sean mucho más fáciles de entender (por ejemplo, una mejora en el lenguaje de programación salió hace más o menos 10 años, lo que generaría grandes porciones de código mucho limpiador, sin mencionar menos propenso a errores). No parece haber ningún esfuerzo para rectificar esto y mis ofertas para hacerlo para las partes con las que estoy trabajando se han encontrado con resistencia, para lo cual realmente nunca obtuve una respuesta clara.
¿Son estas prácticas comunes en una gran empresa en la industria del software? ¿O es mi compañía única en su falta de refactorización y documentación?
Anexo: Basado en algunos de los comentarios, me gustaría aclarar lo que estoy buscando. Entiendo que mi empresa tiene deudas técnicas y esto es malo. No estoy buscando determinar si mi compañía está o no en peor situación debido a esto, solo quiero saber si esta falta de documentación y resistencia a la refactorización es una realidad en el mundo de la programación que tendré tratar si sigo trabajando en ello.
fuente
Respuestas:
Hay una serie de razones por las cuales las compañías no invierten en mejorar sus programas, desde una perspectiva técnica de la deuda:
La reducción de la deuda técnica no agrega nuevas características al software. Por lo tanto, la gerencia percibe que no tiene valor monetario (hasta cierto punto justificadamente)
La naturaleza del negocio de software premia primero al mercado, no el mejor.
Podría continuar, pero todas las otras razones son solo variantes de estos dos. Básicamente, todos se suman al pensamiento a corto plazo, centrándose en las ganancias inmediatas en lugar de la viabilidad a largo plazo.
Todas las empresas con proyectos de software activos no triviales tienen cierto grado de deuda técnica. Ninguna empresa está completamente libre de deudas.
En cuanto a la documentación específica, cuanto menos haya, mejor. Dólar por dólar, obtiene más rentabilidad al hacer que el software sea más simple de usar y más fácil de mantener que al escribir más documentación para él.
Hay algunas encuestas informales sobre la deuda técnica y cómo las empresas la manejan; todo lo que tienes que hacer es buscarlos. Aquí hay uno :
O este :
Parece bastante evidente que su empresa no es la única que tiene este problema. Puede que ni siquiera sea una minoría.
Lecturas adicionales
Tercer taller internacional sobre gestión de la deuda técnica: descripción general
Gestión de la deuda técnica en sistemas con software confiable
fuente
Una perspectiva que no creo que haya sido cubierta en otras respuestas (todavía) es el costo del cambio en tres áreas:
Una empresa con un producto grande deberá probar todos los cambios. Es necesario realizar un seguimiento de estos procedimientos de prueba en varios ejes: diferentes plataformas, diferentes cargas de trabajo, diferentes perspectivas (rendimiento, funcional, usabilidad, compatibilidad con versiones anteriores).
Las personas que trabajan en las áreas de código que está cambiando también necesitarán volver a familiarizarse con el código, y se vuelve especialmente engorroso con múltiples versiones compatibles ("perdón, ¿qué versión es esa? Ahh, esa es la nueva código y necesitas hablar con Bob para eso "). De manera similar, cambiar el código solo para hacerlo bonito tiende a hacer que cosas como los registros de cambios (diferencias, parches, etc.) sean muy complicados de leer ... y rastrear problemas hasta un punto particular en el tiempo cuando se introdujo el error puede ser muy desafiante si hay algo en el historial de código que lo cambia todo. Además, si un error es de larga data (estas cosas suceden) puede estar en múltiples versiones compatibles de su código, y ahora tiene que corregir el código antiguo y el nuevo de maneras potencialmente muy diferentes.
Finalmente, a menudo se debe tomar la decisión de dónde gastar tiempo y dinero. Esto es más que solo su tiempo, sino más bien lo que debería hacer con su tiempo (y el impacto que tiene en los recursos posteriores). ¿Sería preferible pasar el tiempo de su equipo de desarrollo en funciones que pueden producir más ventas, ganar una nueva cuota de mercado y generar ganancias, o si el tiempo / dinero se gasta en cosas que los usuarios finales no notarán, no se pueden poner material de marketing ("oye, nuestro código existente apesta, pero lo hemos mejorado") y es puro costo (sin ganancias).
En pocas palabras, dinero . Siempre (bueno, casi siempre).
fuente
Si. Basado en las aproximadamente 50 compañías que he conocido personalmente, como empleado o consultor, y en las más de 200 compañías que conozco a través de colegas.
El tipo de producto (1.5 millones de líneas) que describe tardó años en construirse, y muchos de los desarrolladores originales se han mudado (o se han convertido en gerentes).
La alta gerencia y los principales clientes continuos solo quieren un pequeño cambio incremental: quieren estabilidad. Lo que nosotros, los técnicos, creemos que las mejoras son riesgos para ellos. Incluso si podemos mostrar que la nueva versión todavía se comporta igual que la anterior, ven un riesgo porque el sistema antiguo tiene exactamente la característica que usted describe: no está documentado. Para ellos, podría haber un comportamiento indocumentado en el que los clientes confían.
Desde su perspectiva: no está roto, así que no lo arregles. También está viendo que hay una cultura corporativa en ese sentido. Las personas que se resisten a sus "mejoras" probablemente hicieron lo mismo que usted cuando comenzaron.
No esperes "ganar". Este es un problema cultural y no se puede cambiar, excepto mediante un cambio a nivel de CEO.
fuente