sugiriendo grandes cambios / una reescritura como interno [cerrado]

El contexto:

• es un proyecto interno (que no creo que mucha gente use)
• es viejo
• lo estamos actualizando

Los problemas:

1. abusa del marco mvc (sin uso de modelos, lógica de negocios en vistas, etc.)
2. lo que se nos pide que hagamos es pequeño, pero debido a la baja cohesión tenemos dos opciones:
   1. continuar arruinando cosas
   2. mover grandes porciones de código o reescribir la cosa

Las soluciones (ya veo):

1. continúe trabajando con él, ignore las mejores prácticas a favor de hacerse pronto y no introducir nuevos errores refactorizando / reescribiendo
2. refactorizar / reescribir

Creo que mi pregunta es realmente: si quiero hacer grandes cambios a este proyecto, ¿cómo propongo eso sin insultar a nadie? ¿O sería mejor para mí seguir la corriente incluso si eso significa cinta adhesiva (metafórica) a veces?

Ok, aquí va.

Cree que la aplicación está mal estructurada y mal escrita.

El cliente piensa que hace el trabajo.

Desea reescribirlo sin otra razón que mejorar su "belleza interna".

Por lo tanto, le está pidiendo al cliente que gaste dinero para hacer que la aplicación haga exactamente lo que hace ahora: solo las partes que el usuario no ve o entiende serán de alguna manera "mejores".

La principal objeción al código mal estructurado y mal escrito es que es difícil de entender.

El código es difícil de entender y tiene funcionalidad y características que solo pueden implementarse fácilmente en una aplicación mal estructurada. Entonces, a menos que sea muy bueno en esto, la nueva aplicación no hará exactamente lo que hace la aplicación actual y, debido a que no entendió completamente lo que estaba haciendo el código original, probablemente lo estará haciendo mal.

Por lo tanto, su cliente ahora ha gastado mucho dinero para obtener una aplicación que es notablemente peor que la aplicación original. ¡No vas a ser popular!

Afortunadamente, sus universidades más experimentadas están preparadas para complacerlo (probablemente porque cometieron el mismo error cuando estaban comenzando e incluso pudieron haber tenido la desgracia de obtener la aprobación de la gerencia para un proyecto tan desafortunado).

Por lo tanto, mi consejo sería mantener en funcionamiento la antigua base de código y guardar silencio. El cliente solo quiere un sistema que funcione, realmente no le importa si crees que el código es feo.

Proponer sus cambios. Sea claro en el caso de negocios para cada uno: ¿Por qué su cambio propuesto ayudará al sistema en su conjunto? Si no es así, espera retroceder. ¿Por qué gastar dinero arreglando algo que no está roto? Razones como hacer que el sistema sea más extensible y las separaciones de interés pueden ser válidas (dependiendo de con quién esté hablando), pero el 99% del tiempo, simplemente diciendo "no está implementado correctamente" no lo llevará a ninguna parte. Asegúrese de agregar valor al proyecto y no solo proponiendo hacer el trabajo (incluso si limpia el código).

Desafortunadamente, en el mundo profesional, el hecho de que algo se haya implementado mal no significa que esté roto y, por lo tanto, no es necesario arreglarlo. Además, al solucionarlo, puede introducir problemas imprevistos que podrían afectar otras áreas del proyecto.

Al leer su pregunta, soy escéptico de que valga la pena volver a escribir la aplicación. Tal vez no te molestaste en presentar el caso completo en tu pregunta. Pero, ¿qué posibilidades hay de que el beneficio de la reescritura valga la pena si se trata de una aplicación interna antigua y poco utilizada? Es probable que el costo de una reescritura sea mayor que la suma de todas las actualizaciones y parches que tendrá.

Si cree que eso no es cierto, tendrá que presentar un caso más de lo que hizo aquí.

En cuanto a la mejora de la aplicación, es posible que tenga alguna posibilidad de refactorización que ocurre naturalmente en el curso de sus actualizaciones.

Eres un interno. Presumiblemente, eres nuevo. Probablemente sospechen que eres un idiota.

Entonces, a medida que haces sugerencias, camina con cuidado . Sé humilde y sin pretensiones. Deje que sus ideas fluyan conversacionalmente mientras permite que otros miembros también discutan sus propias ideas sobre la base de código y bajo qué presiones pueden estar (podría haber una muy buena razón por la cual no se ha hecho un esfuerzo para limpiar las cosas).

Quieres ganarte su confianza. Para ello, escriba un buen código para las tareas que se le asignan. Escríbalo limpiamente, use las mejores prácticas que le gustaría ver implementadas, pero solo en lo que se le asignó hacer. Probablemente sean cosas pequeñas, cosas que el resto del equipo probablemente piense que son insignificantes. Haz esas cosas bien. Aclare la esquina donde se encuentra y, a medida que el equipo venga a revisar su código favorablemente, sus ideas también crecerán en importancia.

Eventualmente , a medida que demuestre su competencia y conocimiento, es posible que pueda realizar una sugerencia o dos.

Haría esta sugerencia totalmente, pero solo a un compañero desarrollador . No lo mencionaría con la gerencia, ya que me imagino que la gerencia lo vería como un tipo de sobrepasar los límites.

Después de hacer la sugerencia a un desarrollador con el que estás trabajando, probablemente tengan algunas buenas razones de por qué es la base de código. Las razones pueden variar de "no, en realidad el código está bien, simplemente no entiendes MVC (y por eso eres un interno)" a "esa es una gran idea, ¡vamos a diseñar la nueva aplicación juntos!"

Tenga en cuenta que la respuesta a la refactorización de esta aplicación será más que probable que no; Nunca desearía que un pasante se hiciera cargo de la reescritura de una aplicación interna (¿qué sucede cuando finaliza su pasantía y la reescritura está a medio terminar?) Además, probablemente haya cosas más importantes en las que podría estar trabajando que hurgar en una aplicación interna .

Pero nunca está de más preguntar a tus compañeros, y si lo haces, aprenderás algo. Y eso, 7983879342, es de lo que se trata una pasantía.

Pase lo que pase, espero que te lleves el siguiente mensaje. Como algunas de las respuestas anteriores han señalado a veces una reescritura de código, por la mejor de las razones técnicas a veces no es factible por razones comerciales / de costo. Demasiados programadores viven en la solución técnica y se niegan a considerar que su búsqueda personal de elegancia técnica / legibilidad / mejores prácticas debe estar equilibrada por las necesidades del negocio para hacer las cosas. En mi experiencia personal, el tipo que no logra ese equilibrio (desde cualquier dirección) a menudo se considera una responsabilidad dentro del equipo.

Sin embargo, no deje de cuestionar las cosas, incluso si recibe algunos retrocesos, es la forma en que aprendemos y crecemos.

Otras respuestas han hablado mucho sobre la política de su situación, y tiendo a estar de acuerdo. A menos que pueda presentar un caso comercial convincente, una reescritura probablemente no esté en las tarjetas.

Sin embargo, eso no significa que deba olvidar la Regla de Boy Scout :

Siempre deje el campamento más limpio de lo que lo encontró.

Si mientras implementa algo en esta base de código, puede encontrar una manera de limpiar algún aspecto del diseño o implementación, entonces eso es algo que debe considerar. Probablemente no necesite volver a escribir toda la aplicación para hacer un mejor uso del modelo MVC, y si está implementando una nueva lógica de negocios para una vista en particular, podría considerar mover la lógica de la vista anterior al modelo y agregando tu nueva lógica a eso.

Como han dicho otros, pida a otro desarrollador (uno familiarizado con esta aplicación) que haga un recorrido rápido para que pueda comprender cómo / por qué de la implementación. Explique que, si bien puede comprender los aspectos tecnológicos, pero desea poder conectar los puntos a los requisitos comerciales (los requisitos comerciales prevalecen sobre todos).

Una vez que tenga esta información, puede hacer su evaluación. Si personalmente piensa que debería reescribirse, pero no cree que otros lo vean como un buen uso del tiempo, tómelo como un proyecto personal. Incluso si es una hora aquí / allá cuando tiene tiempo de inactividad, realice la implementación "correctamente". Una vez que termine, preséntelo a los otros desarrolladores como "oye, sentí que esto podría usar un poco de limpieza, así que hice algo de trabajo secundario durante mi tiempo de inactividad. ¿Qué piensa?" No presione el cambio sobre ellos, solo ofrézcalos como un "oye, ¿les gusta esto?" e ir desde allí.

La mayoría de los cambios ocurren de manera incremental, como regla general.

Un par de cosas a tener en cuenta;

• ¿Cuál es el historial de la aplicación?
• ¿Por qué es feo hoy?
• ¿Cuál es el beneficio de los cambios arquitectónicos?

Una buena estrategia es trabajar en las cosas pequeñas y hacer un montón de preguntas sobre cosas (preguntas que no puedes aprender de Google o de la fuente, no pierdas el tiempo de las personas). Después de que se sienta cómodo con la base de código y los desarrolladores, debe tener una buena idea de por qué el código es como es. A veces, es solo, "Sí, tuvimos que hackear algo juntos y empujarlo por la puerta". Si puede proponer cambios leves en pequeñas partes del sistema que ocurren a medida que avanza en su trabajo normal, obtendrá más tracción que las reescrituras radicales.

No hay nada de malo en sugerir una reescritura si preguntas bien y haces un caso lógico (no solo una corazonada o es la mejor manera de hacerlo). Existe una alta probabilidad de que la reescritura de una aplicación de bajo uso sea derribada, y existe una buena posibilidad de que quienquiera que haya escrito originalmente el sistema todavía esté presente (y más alto en la jerarquía que usted) y no sea amable con las críticas.

Así que no digas "Necesitamos reescribir este sistema horriblemente diseñado que viola los principios básicos de MVC", hazlo como una pregunta abierta a los superiores apropiados (personas directamente por encima de ti). Algo así como "Me pregunto si reescribir el sistema en el modelo MVC podría ahorrar mucho tiempo a largo plazo. ¿Qué opinas? Apuesto a que podríamos reducir a la mitad el tiempo de mantenimiento con una reescritura importante (en 2 semanas) incorpora el modelo MVC, TDD, etc. que se realizó y que después de dos meses de mantenimiento de rutina saldremos del equilibrio " La respuesta puede ser, no, no creemos que sea necesario; no estoy de acuerdo con sus estimaciones de tiempo y la probabilidad de que el nuevo sistema sea un reemplazo adecuado. O la respuesta podría ser, bien, adelante, pero recuerde si su nuevo sistema no No funciona tan bien / mejor que el nuevo sistema en el período de tiempo que propuso que la gente lo culpe. E incluso si el sistema se usa poco; puede que no sea aceptable dejar de actualizarlo con correcciones menores durante el período de reescritura.