¿Cómo demostrar que una aplicación está construida sobre una base de código incorrecta?

Actualmente estoy revisando un sistema creado por algunos desarrolladores que anteriormente trabajaban en mi trabajo. El sistema funciona bastante bien desde el punto de vista del usuario, pero al profundizar en la revisión del código es un completo desastre. Estoy más que convencido de que la forma en que se construye la aplicación no servirá para futuras actualizaciones, y mucho menos para los altos aumentos en el uso.

El problema es que sé lo malo que es, pero mis superiores no. ¿Cómo puedo demostrárselo a mi gerente para que realmente vea el problema y pueda convencerse de hacer un triaje mínimo en la base de código actual y, en un futuro próximo, comenzar una nueva línea de desarrollo para la próxima versión de la aplicación?

"Pero funciona ahora" es la respuesta de gestión estándar a las frustraciones legítimas de los ingenieros de software. Lo primero que haría sería compilar la documentación (si la hubiera) y usarla para demostrar contradicciones entre el código y la documentación.

Si puede, prepare un conjunto completo de pruebas unitarias. Ejecútelos con cada cambio para que pueda documentar las regresiones que pueden atribuirse a la base de código existente.

Por último, si puede atraer a un desarrollador de otro departamento en cuyo trabajo confíe, obtenga un segundo par de ojos en el código. Un desarrollador que dice 'esto es una mierda' es más fácil de descartar, que cuando un desarrollador senior que ha estado por un tiempo responde por él y dice: 'No, Jim, tiene razón. Esto es una mierda en una galleta de mierda.

Por supuesto, todo depende de su entorno, tamaño de la empresa, etc.

Siempre recomiendo echar un vistazo al Programador pragmático si no lo has leído. No solo debe requerirse la lectura para todos los profesionales del software, sino que tiene algunas buenas sugerencias para tratar con la administración, los compañeros de trabajo, los usuarios, etc., que no ven la ingeniería del software como un oficio.

Desde la perspectiva de la gerencia, el sistema no tiene nada de malo y solo te estás quejando porque [solo quieres reescribirlo / no entiendes lo que hicieron los ingenieros anteriores / quieres que tu trabajo sea fácil]. Es un poco tímido, pero cuando alguien en la cima ve que las cosas están funcionando bien en este momento, no está dispuesto a ver una crisis en el lugar donde está (estoy seguro de que hay una alegoría del cambio climático en algún lugar ...) .

Hasta cierto punto, tienen un punto. La administración ve problemas cuando las versiones van más allá de su estimación original, las estimaciones parecen demasiado altas para el trabajo que se está realizando, "esto es imposible con nuestra base de código existente", y las altas ocurrencias de errores que se escapan del control de calidad. Si las cosas ronronean bien, es fácil darte palmaditas en la cabeza y decirte que hagas tu mejor esfuerzo, porque no está afectando el resultado final.

Qué hacer depende de su organización y del software en sí. Básicamente, sin embargo, sugiero documentar cada complicación que surja como resultado de un mal código heredado. Al estimar las tareas, deje en claro a la gerencia por qué cree que llevará tanto tiempo, con explicaciones detalladas sobre qué aspectos de la antigua base de código están agregando este costo adicional. Cuando se introducen errores en el código, incluya las razones por las cuales este error pudo introducirse y cómo los problemas en la antigua base de código son responsables.

Sugeriría expresar sus inquietudes a las partes interesadas de una manera que sugiera que el software ha superado su diseño original y ahora es problemático para continuar mejorando.

Hay varias herramientas disponibles que pueden hacer cobertura de código y revisión de código. Herramientas de Google adecuadas para su tecnología, normalmente son herramientas estándar del sector. Le sugiero que use estas herramientas y presente un informe de calidad de código y lo presente al Gerente. Asegúrese de que su crítica sea constructiva y no política.

Elija un ejemplo que sea fácil de entender donde la gerencia pensaría que es una simple solicitud de cambio, pero debido al diseño existente es mucho más difícil.

No desea que se detengan en la solicitud específica, pero asegúrese de informarles que así será CUALQUIER solicitud de cambio. Nadie quiere ser pintado en una esquina con una aplicación. Los desarrolladores creen en YAGNI, pero la gerencia cree en CYA.

Las sugerencias para la prueba de carga podrían ser un buen enfoque, pero es posible que no estén convencidas de que el aumento de las preocupaciones de uso cumpla con el potencial de crecimiento del mundo real (la compañía no se duplicará en un año).

Todo es relativo. Es posible que no quieran poner los recursos en este proyecto cuando tienen planes para proyectos más importantes en los que pasar su tiempo. No te etiqueten como no viendo el panorama general.

Cuando habla de probar algo, todo ese método científico entra en juego, y parte de lo que eso significa es que si va a aceptar estándares objetivos para decidir qué es verdad, debe aceptar la posibilidad de que, después de la investigación, esos hechos molestos resulta no estar de tu lado.

En su caso, creo que hay 2 cosas por probar.

Primero, que la base de código actual es "mala". Lo que probablemente pueda probar es que "la opinión profesional de casi todos los desarrolladores que examinan este código es que es malo".

Segundo, que sería mejor reescribir la base de código de la compañía. Esto es un problema porque incluso si el primer punto es verdadero, el segundo podría no serlo. Además, no sabes lo suficiente como para hacer esta determinación. Este es el trabajo de la gerencia, y si desea que respeten su juicio profesional sobre el primer punto, debe respetar el suyo sobre el segundo.

Pero no pueden determinar el segundo punto sin la información que usted proporcione. Debe comunicar lo que sabe sobre cómo los problemas en el código afectarán al negocio, y lo que sabe sobre cómo una reescritura afectaría al negocio. Esto es difícil, ya que ambos implican predecir un futuro que tiene mucha incertidumbre.

Pero puede intentar exponer el problema en términos comerciales. ¿Cuánto tiempo extra se gasta en cambios y regresiones? ¿Cuánto costaría una reescritura? ¿Con qué rapidez subirán los costos del sistema actual con el tiempo si no se reescriben? ¿Qué pasa si hay un aumento en el uso, cuál es la posibilidad de un desastre si se mantiene el código actual? Realmente no puedes saber nada de esto, pero puedes adivinar mejor que nadie. Dé un rango o algo para comunicar con qué precisión cree que puede predecir estas cosas.

A la mayoría de los desarrolladores no les gusta mantener código pésimo. Es por eso que puede ser desafortunado que el código que es fácil de escribir desde una perspectiva de desarrollador no valga la pena volver a escribir desde una perspectiva comercial.

Por ejemplo, incluso si la reescritura termina siendo rentable, podría valer menos que el costo de oportunidad de gastar el dinero en otra parte de la empresa. O la base de código incorrecta puede tardar más en cambiar y tener más regresiones, pero no lo suficiente como para que una reescritura sea rentable. Es posible que estén buscando ser comprados en los próximos meses, y gastar dinero en una reescritura aparecerá en los libros, pero el software con errores no lo hará.

Trate de pensarlo desde la perspectiva comercial y no cocine los números para obtener lo que desea. Una gran reescritura casi nunca es obvia desde un punto de vista comercial. Si desea probar algo que no es directamente demostrable, haga todo lo posible para refutarlo. Si usted siempre está tratando todo lo posible para llegar a una forma no volver a escribir desde cero, pero nada de lo que ocurrió con las marcas sentido, tal vez entonces ya es hora de volver a escribir desde cero. Y hacer ese esfuerzo le mostrará a su gerencia que usted se toma en serio la representación de los intereses de la compañía, no los suyos (usted representa los intereses de la compañía, no los suyos, ¿verdad?).

Supongo que depende de lo malo de la base del código. Ser "No de la forma en que haría las cosas" no significa que sea una mala base de código.

Cosas que realmente hacen una mala base de código:

• Agujeros de seguridad

  Problemas que dejan el servidor, la aplicación y / o los datos vulnerables. Especialmente cualquier cosa que deje en riesgo la información confidencial de la empresa, el cliente o el cliente. Estos deberían ser fáciles de documentar.

• Trabajando roto

  Solo funciona porque da masajes a los datos y realiza el mantenimiento de la aplicación de forma casi continua para que siga funcionando. Si te fueras y nadie tomara el relevo, ya no estaría funcionando. - Documente cuánto tiempo pasa haciendo esto. Y tenga en cuenta cuánto podría ahorrar. Muy a menudo, estos procesos también son ineficientes para los usuarios y es posible que también pueda documentarlos.

• En realidad no funciona

  Parece funcionar pero los resultados son incorrectos. Esto generalmente causa problemas en el futuro, como números que no coinciden, alta tasa de defectos, etc.

Lo que no es una mala base de código (simplemente no es buena):

• Escrito en tecnología obsoleta no compatible. (VB6, COBOL, .net1.1 Etc.)

Tenga en cuenta las ventajas de migrar a una nueva tecnología. Intente encontrar una ruta de migración que mueva las piezas a la vez para que pueda minimizar el riesgo y generar confianza en la administración y los usuarios. Asegúrese de que la lógica funcione básicamente igual que la original.

• Código no documentado / mal formateado

Esto es lo más fácil de solucionar porque generalmente puede agregar comentarios y corregir el formato sin afectar realmente el código. Pero no requiere una reescritura. Si cree que esto se combina con otros problemas, lo primero que debe hacer es solucionarlo para poder evaluar mejor la viabilidad del código.

Has respondido tu propia pregunta de alguna manera.

La forma de convencerlos de que gasten dinero en el sistema es esperar hasta que no funcione bien para el usuario. Si cree que no escalará, espere a que eso suceda o haga una prueba de carga para probarlo.

Entonces es una simple propuesta de limpiar esto a escala que costará X horas.

Esta es una situación difícil porque, desde la perspectiva del usuario, todo está en un punto aceptable y estable ahora. Principalmente con los gerentes no técnicos, no hay nada de qué preocuparse en este momento, pero pedir reescribir la base de código es una decisión enorme y no debe tomarse a la ligera, especialmente en la opinión y los esfuerzos de un solo hombre (usted mismo) .

Por lo tanto, está en una situación difícil de tratar de hacer un caso para una reescritura debido a una deuda técnica abrumadora (en su opinión, no tenemos ningún ejemplo y tenemos que tomar su palabra al respecto), así como estar en la situación difícil. de tener la dificultad de mantener y agregar características a este sistema.

Sus estimaciones para las nuevas características serán altas, justifique estos números altos con hechos, lo que demuestra que estas cosas realmente tomarán una gran cantidad de tiempo. Si no transmite esto correctamente, entonces su gerente puede asumir que es incompetente y ciertamente no quiere eso. Cuando cuestione las altas estimaciones, explique por qué siente que la deuda técnica acumulada está obstaculizando la capacidad de agregar funciones de forma rápida y económica al software actual. Si su gerente tiene dos células cerebrales para frotar, comenzará a comprender muy rápidamente.

El punto es que no debe tratar de convencer a su gerente, sino guiarlo con información apropiada (y cuidadosamente seleccionada) de que él / ella puede convencerse de que una reescritura es un curso aceptable. Tienes que hacer que el gerente piense que fue su idea todo el tiempo.

Primero determine la deuda técnica acumulada en su código base. Luego, eche un vistazo a esta pregunta y sus respuestas , donde se explica cómo convencer a la gerencia para que pague la deuda técnica antes de continuar.

Hay una razón por la cual todo el software maduro parece un desastre:

1. Todo el desastre está codificando la lógica crítica en la que se basa el negocio. Sin ella nada funciona. Todo fue necesario para resolver el problema del usuario.
2. Está utilizando tecnología ligeramente desactualizada. Los programadores actuales parecen pensar que si no usa un poco de magia de plantilla, es solo un desastre. Esta es una vista rota. Cualquiera que llegue tarde a un proyecto más grande tendrá esta etapa mientras aprende todos los detalles.
3. Los requisitos que fueron críticos hace algún tiempo ya no son tan críticos. Esto se debe a que el software ya solucionó esos problemas. Llegando tarde al proyecto, puede parecer que el software es complejo sin una buena razón: el problema ya no existe, pero la complejidad del código sigue ahí.