¿Cómo lidiar con excelentes productos escritos con código malicioso?

Question

Me pidieron que mejorara y mantuviera una aplicación web interna utilizada y aprobada por una importante comunidad de usuarios. Esto incluye mejoras de rendimiento y funciones adicionales.

Desafortunadamente, el código está hinchado, a veces muy mal escrito, y es difícil de leer y cambiar. Esto hace que los cambios sean mucho más difíciles de implementar.

A pesar de todo, la aplicación es atractiva, útil, y los usuarios la quieren y quieren cambios.

Es por eso que siento que me han engañado. ¿Es realmente mejor escribir un código malo para un resultado y una gloria más rápidos, y luego irnos a grandes proyectos nuevos dejando atrás una cantidad tan grande de problemas?

Ya he leído mucho sobre este tema en Coding Horror, pero me gustaría leer más de personas aquí que están experimentando esta triste realidad y cómo están lidiando con ella. Probablemente también necesite que le den coraje;)

Como mi idioma principal no es el inglés, puede reescribir esta pregunta con una mejor gramática.

Answer 1

Esto le sucederá a la mayoría de los programadores. El primer impulso es reescribirlo. El mejor enfoque es simplemente hacer lo que se te pide que hagas. Si entra en reescrituras importantes, es muy probable que lo rompa.

Si los cambios requeridos son simples que debe ponerlas en práctica con tan pocos cambios como sea posible, al estilo que ya se ha escrito.

Si los cambios son más complicadas, a continuación, intenta aplicar los cambios en el menor número de lugares posible. Si su plan es limpiar el código a lo largo del tiempo, este es el lugar para comenzar. Tenga cuidado con los cambios que realice, ya que puede romper fácilmente las dependencias que no comprende. Según mi experiencia personal, generalmente puedo agregar nuevas funciones o implementar cambios al eliminar código y reescribir lo que queda en una rutina o método determinado.

Resista la tentación de reescribir todo. Míralo como triage. Dé prioridad a los cambios que le gustaría ver e impleméntelos a medida que implementa los cambios que se le piden. Evite afectar el código que no se le pide que cambie. No obligue a sus usuarios a enfrentar los problemas de los cambios que está realizando solo por su estética.

Answer 2

Escriba una serie de pruebas para el producto para que pueda estar más seguro de que no está rompiendo nada.

Luego refactorice los peores bits del código o los bits que necesita cambiar de todos modos.

Pero, considere "si no está roto, no lo arregle", si un área está funcionando, y no necesita cambiarla, considere si los riesgos de presentar problemas exceden el beneficio de hacer agradable".

Y encontrar los desarrolladores originales y tentarlos en algún callejón oscuro :) O mejor, hacer que hagan los cambios

Answer 3

Sí, algunos programas mal escritas son muy populares. La desventaja es que tales aplicaciones tienden a ser más difíciles de mejorar con el tiempo (por ejemplo, en términos de escalado, adición de nuevas funciones, corrección de errores, etc.).

Pero no, no es bueno escribir el código de la basura. Es bueno identificar lo que los usuarios quieren y darles una buena interfaz, etc. y hacen que el código sea fácil de mantener. Ocasionalmente, esto puede significar que los usuarios tendrán que esperar un poco más para obtener nuevas funciones, en especial desde el principio, pero a la larga podrán hacer más cosas.

En su caso, le sugiero que intente mejorar un poco a la vez. Si puede, forje un área y "solucione" eso, y asegúrese de que nunca vuelva a los "malos viejos tiempos". Luego forja la siguiente área, etc. Eventualmente tendrás una aplicación bien escrita. Puede llevar más tiempo hacerlo que reescribir desde cero, pero podrá brindar mejoras a los usuarios a medida que avanza, y tendrá más confianza en que se trata de un sistema en funcionamiento en cualquier momento.

Answer 4

Casi todos los desarrolladores, nunca, en todas partes, cuando se les presenta un código que no escribieron, quieren volver a escribirlo para corregir los bits de mierda.

Resista el impulso de reescribir todo, arregle los bits que están rotos. ¡Ocúpate de los bits que no se pueden mantener cuando tienes que mantenerlos!

Answer 5

El código de error es technical debt; puede ser menos costoso de escribir, pero se vuelve mucho más costoso de mantener (a menos que pague la deuda refacturando o reescribiendo).

Puede obtener un resultado y gloria más rápidos, pero cuando los usuarios más tarde quieran cambios, tendrá que gastar cada vez más esfuerzo haciéndolos (o reparando los errores inevitables).

Answer 6

He escrito código travieso para algunos proyectos. Sin embargo, el código "malo" sensible. El código malicioso puede ser causado por muchas razones, no solo por las habilidades de la persona (bueno, la mayoría de las veces es por las habilidades)

Los programadores pueden escribir un código muy bueno si tienes suficiente tiempo y no hay presión del negocio. Sin embargo, los empresarios no aprecian la buena codificación, sino las funcionalidades y la apariencia. Considero que el codificador de "mierda" es un tipo inteligente en el negocio. Simplemente él desarrolló el modelo de solución, puso el software en funcionamiento en poco tiempo y también hizo feliz al empleador, supongo. Si deja que el codificador lo escriba de nuevo, puede hacerlo mucho mejor.

En primer lugar, que necesita para convencerse de apreciar cuántas cosas los primeros codificadores que habían pasado, este es uno de los puntos a tener en cuenta si usted es un desarrollador madura o no. LA MAYORÍA de las personas se queja e incluso se ríe de las versiones existentes porque saben que pueden hacerlo mejor. Es como dibujar en un papel en blanco con su imaginación, o hacer una réplica de la pintura existente. ¿Cuál es más difícil?

En segundo lugar, a ver en el código general y saber dónde se puede mejorar, es posible encontrar algo que mal entendido.

En tercer lugar, hoja de ruta del accesorio, que puede contener recientes y futuras TODOs

Por último, comenzar a planificar la forma en que se puede mejorar si se quiere diseñar desde cero, nueva arquitectura, etc., y Preséntelo a la gerencia cuando esté listo y sea completo.

Cada software tiene un espacio para mejorar, es por eso que te contrataron para mejorarlo.

Answer 7

Asegúrese de que su administración y los usuarios sepan que el código no tiene la calidad suficiente desde el punto de vista de la capacidad de cambio. Cuando calcule cuánto tiempo necesita para implementar nuevas características, siempre explíquele cuánto tiempo necesita para limpiar el código afectado.

Answer 8

"A pesar de esto, la aplicación es bien parecido, útiles, y los usuarios les gusta y quieren cambios"

La aplicación es, obviamente, dando a los clientes lo que quieren, pero suena como que ha llegado a la etapa imposible de mantener.

Creo que no hay nada más que refactorizar implacablemente. Esto probablemente sea más fácil y menos doloroso si se resiste a la presión para agregar cualquier funcionalidad no trivial simultáneamente. Por supuesto, dígales a los gerentes que, aunque el software es bueno, corre el peligro de convertirse en una gran pila de basura inmanejable.

Mejorar el código a menudo introduce uno o dos errores propios, pero le ahorrará mucho daño cerebral a largo plazo. Obtenga tantos ojos extra como pueda para ayudar con las pruebas y la depuración, y cumpla con hacer las cosas realmente malas primero.

Considere la posibilidad de introducir pruebas unitarias si el titular anterior aún no lo ha hecho, para que tenga mayor confianza en que la refabricación no ha roto nada. No defiendo el 'si no se rompió ..."La filosofía como esto te mantendrá en el mismo tiovivo poco satisfactorio.

No se preocupe por su inglés, tiene perfecto sentido para mí y su situación es universal.

Answer 9

A veces, cuando un programador selecciona un proyecto antiguo por primera vez y ve todas las clases, interfaces, módulos de código, etc., inmediatamente piensa que está "hinchado". De hecho, podría ser simplemente tener una arquitectura muy profunda, que puede ser abrumadora al principio. Si no hay documentación con el proyecto (por ejemplo, un Diagrama de clase), tómese un tiempo para esbozarlo. No solo lo ayudará a comprender cómo funciona el proyecto, sino también a cualquier persona que lo respalde.

Eso también se aplica a declaraciones como "difícil de leer". Si conoce el lenguaje de programación, entonces no es más difícil de leer que cualquier otra aplicación. El estilo del programador original puede ser diferente al suyo, pero si la aplicación funciona, entonces no harán nada que el idioma no les permita. El flujo puede ser difícil de seguir, pero se puede superar esbozando el proceso (por ejemplo, un diagrama de flujo). La mayoría de los gerentes le dará tiempo a una curva de aprendizaje para familiarizarse con la aplicación antes de realizar cambios. Tómese ese tiempo para esbozar algunos diagramas, usted (y el programador que lo sigue) se alegrarán de haberlo hecho.

En lo que respecta al "código de mierda", eso es muy subjetivo. ¿Es realmente el código (la implementación) que es "malo" o el diseño? ¿Hay una falta de patrones de diseño? ¿Un uso excesivo o mala implementación de patrones de diseño? ¿O realmente implementaron patrones de diseño sólidos pero no estás lo suficientemente familiarizado con ellos como para reconocerlos?

El punto es que puede ser abrumador entregar un nuevo proyecto para mantener y es fácil culpar al programador original por "hinchazón", "código sucio", "difícil de leer y hacer cambios", etc. A veces eso es cierto, pero muchas veces puede deberse a que el programador no comprende el diseño y la arquitectura de la aplicación, ni comprende por qué ciertas cosas se implementaron tal como eran.