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

23

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?

ChrisR
fuente
66
programmers.stackexchange.com/questions/59050/… Tal vez preste atención a lo mal que la "gran reescritura" generalmente termina desde una perspectiva comercial. Eso sería lo que haría un programador más de "nivel superior".
quentin-starin
22
@qes, lo único peor que hacer la "gran reescritura" es un miedo paralizante de la "gran reescritura". Cuando comencé mi posición actual, heredé un desastre de Perl CGI de dos o tres programadores diferentes sin control de fuente, seguimiento de errores o pruebas. Me tomó algo de tiempo convencer, pero obtuve la aprobación para volver a escribir en Ruby on Rails mientras mantenía el código heredado. 5 meses después, las herramientas eran más fáciles de usar y podíamos agregar nuevas funciones en días o semanas en lugar de meses. Los usuarios están extasiados y no me estoy volviendo loco. La "gran reescritura" requiere una justificación sólida, no una evasión total.
Jason Lewis
1
@JasonLewis: (Supongo que no siguió el enlace en mi comentario anterior?) Parece desaconsejable para alguien que hace menos de un año se describió a sí mismo como carente de habilidades importantes que un alto nivel poseería y no posee No sé por dónde comenzar al comenzar un nuevo proyecto.
quentin-starin
55
@JasonLewis Estoy completamente de acuerdo contigo. Cada vez que alguien pregunta sobre la reescritura de una aplicación en SE, mucha gente viene con esta ideología de "no hacer una gran reescritura". Creo que hay muchas razones para no hacerlo, pero no deberías evitarlo a toda costa. Participé en una reescritura de una aplicación de 100 mil líneas de código y tuvimos mucho éxito, muy similar a lo que has descrito. Incluso pudimos reescribirlo módulo por módulo (primera parte de la interfaz de usuario, luego el servidor, luego el resto). 12 meses después, tenemos una base de clientes muy, muy feliz y todos estamos orgullosos de la decisión que tomamos.
Alex
2
Esto es parte de un problema más general: el de su predecesor que busca resultados inmediatos a expensas de largo plazo. Al asumir el control, debe explicar por qué no puede mantener el mismo resultado.
David Thornley

Respuestas:

23

"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.

Jason Lewis
fuente
77
No hay documentos y el código es bastante poco comprobable a menos que vayamos a refactorizarlo. Estoy bastante seguro de que varios colegas me respaldan, por lo que podría ayudar a otro desarrollador en la discusión.
ChrisR
@ChrisRamakers Esa es una excelente noticia (el soporte, ¡no la falta de documentos!). Es más difícil (aunque no imposible) para los gerentes negar / rechazar la opinión profesional de múltiples desarrolladores. Y si sus seguidores han estado en la empresa más tiempo, pueden tener una valiosa experiencia navegando por la política interna de la organización. ¡Buena suerte!
Jason Lewis
Además, si puede obtener algún software de prueba de carga, puede mostrar cómo podría romperse bajo una carga alta.
HLGEM
13

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.

Stefan Mohr
fuente
5

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.

ViSu
fuente
Sí, he pensado en calcular la complejidad ciclomática promedio y usarlo como argumento, pero estoy seguro de que esto no resultará nada para la gerencia. Pero vale la pena intentarlo, gracias
ChrisR
55
@ChrisRamakers: Nada puede ser "probado" a un gerente. Olvídate de la "prueba". Reunir datos. Los hechos son todo lo que tienes. Más hechos es más convincente. Pero no hay "prueba".
S.Lott
4

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.

JeffO
fuente
1
Después de hacer el cambio, muestre que el archivo diff, que en una base de código incorrecta tocará muchos archivos fuente diferentes, tiene un "¿qué tiene que ver eso con eso?" elemento, etc. Explique a la administración cuánto de este trabajo, es decir, tiempo == $$, se relacionó con la base de código deficiente y que los cambios en el futuro tendrán esta característica.
Larry OBrien el
3

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?).

psr
fuente
2

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.

SoylentGray
fuente
1

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.

Jonno
fuente
8
El único problema es que si él tiene la responsabilidad principal del sistema, será culpado cuando ya no funcione. "¡Pero funcionó antes de que empezaras!", Dirán. Es por eso que aconsejé un enfoque proactivo. Advertirles de antemano, documentar los problemas, y luego su culo está cubierto cuando se rompe, y no sólo puede decir "te lo dije a su jefe, pero él puede decir 'le dije a él por lo que' con el jefe de su jefe.
Jason Lewis
3
@Jason: veo su punto, pero en mi experiencia, la negación opera hacia abajo y 'le dije' que subir la cadena se encontrará muy rápidamente con el 'jugador que no es del equipo' en el camino hacia abajo.
Jonno
2
Depende mucho de cada lugar de trabajo, pero estoy de acuerdo con usted ... Yo podría haberlo dicho mejor ... Mi punto principal estaba documentando las razones es que van a fracasar de antemano, argumentando el punto, y mantener la documentación disponible para cuando lo hace ... en el mejor de los casos, puede arreglarlo. Promedio, no estás jodido cuando falla. Peor aún, usted asimila profundamente el sistema y sus debilidades y cómo solucionarlos lo suficiente como para explicar de manera impresionante (con detalles vívidos) cómo y por qué le dejó su último puesto a su posible empleador cuando termina buscando trabajo después de que falla ;-)
Jason Lewis
1
@JasonLewis Si los jugadores de la compañía usan frases como I told you soesa, entonces esa es una cultura de culpa tóxica y no un lugar en el que el OP desearía trabajar por mucho tiempo. Un buen gerente no tiene la culpa, un buen gerente reconoce problemas y elabora un plan.
maple_shaft
@maple_shaft Estoy de acuerdo. No quise decir esas palabras literalmente, me refería más a cubrir todas las bases. Lo ideal sería que todos tuviéramos gerentes buenos y solidarios en toda la cadena de mando. A menudo, sin embargo, soportamos el proceso de regular a medio para que podamos usar el trabajo que tenemos como trampolín para el trabajo que queremos.
Jason Lewis
1

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.

maple_shaft
fuente
1

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.

BЈовић
fuente
0

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í.
tp1
fuente
Este tipo de actitud lleva a los programadores a disculpar la enorme deuda técnica en la que incurren por ignorancia o pereza. El trabajo de un programador es codificar la lógica empresarial mediante el uso de abstracciones. Los detalles mutables deben vivir en metadatos, no en números mágicos codificados. En segundo lugar, 'ligeramente anticuado' puede ser subjetivo. En mi humilde opinión, 'un poco desactualizado' significa que el marco / plataforma todavía está desarrollado activamente, y tengo una ruta de actualización. La alternativa es 'obsoleta'. El número 3 es inexcusable. Acabas de describir cruft. Nadie ha refactorizado o limpiado la base del código, ¿y esto es aceptable?
Jason Lewis
claro, pero cuál es el resultado después de haber codificado la lógica de negocios mediante el uso de abstracciones ... El código se verá complicado. Esa es la definición de "desorden". el (3) no es cruft, ya que aún se requiere la complejidad; la necesidad de tenerlo no desapareció incluso después de que se resolvió el problema.
tp1