¿Qué hacer con una aplicación que no está bien organizada? [duplicar]

Si eres un programador recientemente examinado, no sugieras The Grand Rewrite. Mejora poco a poco, paso a paso. Estás pidiendo problemas para reescribir toda la aplicación. Creo que el mayor obstáculo para elegir una mejora incremental está en la cabeza: "¿cómo podemos limpiar este desastre?" Pero la mayoría de las veces, es más fácil de lo que piensas, solo da pequeños pasos.

Creo que lo mejor que puedes hacer es establecer un acuerdo con los miembros de tu equipo y discutir los problemas que enumeraste con ellos.
No debería tratarse de culpar a los demás, tampoco debería ser tirar de las sesiones de peluquería. Lo que realmente importa es el proyecto en sí. Todos deberían tener esto en cuenta.

Hable con ellos sobre las decisiones que tomaron, quizás haya una razón (¿quién sabe?)

También ten en cuenta que eres un programador recién graduado, por lo que no debes generar la impresión de que te consideras mejor que los miembros de tu equipo. Porque muchas nuevas personas recién graduadas caen en esta trampa.

Use preguntas (inocentes o no tan inocentes) para exponer la fragilidad de la que habla.

Coge la fruta de baja altura:

Empezaría con vulnerabilidades de seguridad. Dígale a su jefe que le preocupa la inyección de SQL y que demuestren cómo un atacante podría acceder al sistema. Una vez que estén preocupados, dígales que puede solucionar el problema.

Esto le dará credibilidad, una mercancía que tendrá que tener si desea implementar el cambio. A continuación,

Hablaría con otros desarrolladores (y tal vez con su jefe) sobre cómo poner errores en el programa, explicando que ayudará en el soporte del software si supiera dónde y por qué se estaban rompiendo las cosas y haría que la compañía se vea mejor.

He estado en un entorno similar, y esto es lo que he aprendido.

• Asuma la actitud de un estudiante y nunca tenga una actitud superior. Algunas preguntas bien formuladas pueden hacer que los otros desarrolladores consideren ideas que tal vez nunca hayan escuchado antes. Como desarrollador junior, irás más lejos con una influencia sutil y discreta que con trazos audaces.
• Nunca insultes a los desarrolladores o su código. Su objetivo es servir a la empresa y a sus clientes implementando un cambio radical. Hacer enemigos funcionará en contra de ese objetivo.
• Recuerda la línea sobre cómo comer un elefante haciéndolo una mordida a la vez. Los pequeños pasos incrementales permitirán a la organización digerir los cambios fácilmente, sin ardor de estómago.
• No olvides que la teoría y la práctica no son siempre lo mismo. Si bien no hay excusa para la mayoría de lo que describió, hay momentos en que las empresas necesitan una teoría de diseño de triunfo. Por ejemplo, los datos completamente normalizados pueden ser demasiado lentos para el rendimiento necesario.

Averigüe qué condujo a esta aplicación y ataque la razón

En un nivel puramente técnico, ya sabe qué hacer: normalizar la base de datos, agregar restricciones / valores predeterminados, refactorizar el procedimiento almacenado, etc., etc.

Pero, en mi experiencia, esto es sólo circunstancial. El problema real es el entorno que produce tal desorden.

Y puede haber diferentes razones.

• Uno podría ser que honestamente, el equipo no sabe mejor (quiero decir, para cada uno de nosotros hubo un momento en que no lo hicimos). En este caso, podrías tratar de educarlos cuidadosamente. El objetivo aquí sería sensibilizarlos a sus delitos, para que ellos también vean la aplicación y no a usted como el problema. El peligro aquí es aparecer como "el naga", así que tenga cuidado de criticar el código, no a la persona.

• Tal vez se sientan obligados a codificar de forma rápida y sucia . En este caso, trate de establecer que la excelencia tiene su recompensa. En mi experiencia, esto se hace mejor con el ejemplo y con una posición firme donde la calidad está a punto de ser sacrificada.

• el más difícil, y en mi experiencia, el escenario más común es , piensan que es "pragmático" y las mejores prácticas , debido al pensamiento grupal y la poca exposición a la calidad. Hay muchas soluciones propuestas para este escenario (a menudo citado 'cómo hacer que las cosas se hagan como un gruñido'), pero en mi experiencia, eso no funciona: cuando su nuevo código causa un efecto secundario extraño, se le culpa por no tener memorizó todas sus extrañas dependencias ("no se puede llamar a la función de fecha dentro del módulo de clientes, se necesita más disciplina"), y no el ... "programador" que piensa que "acoplamiento suelto" es para hippies.

Para citar a alguien: "Las cosas son como son porque son así ... un paso lógico a la vez". Su problema no es la base de datos desnormalizada, su problema real es la justificación del equipo para ello.

Intentaría explicarle a dos de mis personas mayores en una reunión (un programador, otro no) que está mal escrito y que probablemente le ahorraría dinero a su empleador para permitirle volver a escribirlo ahora y reducir el trabajo de mantenimiento en el futuro. tratar de mantenerlo como está.

Salga de este trabajo. He trabajado en un proyecto similar (excepto que la base de datos estaba bien, pero la aplicación contenía como 3 clases reales, todo el código CRUD era como Issue.Create (50 parameters here) y IDictionary<string,object> Issue.Get(int id) ), puse algunas pruebas, escribí nuevas funciones de manera limpia pero Decidí que quiero hacer otra cosa con la mitad de mi vida.

Odio hacer esta pregunta porque parece que lo he estado haciendo mucho últimamente.

¿Existe un estándar de codificación local? De no ser así, ¿consideraría redactar uno, y nada más para resolver algunos de los problemas más estúpidos, como a) convenciones de nomenclatura, b) manejo aceptable de errores y uso no estándar de idiomas?

¿Tiene algún tipo de sistema de seguimiento de errores de modo que cuando realice algún cambio y resalte algún error preexistente en el que pueda realizar un seguimiento de todas estas cosas?

Si desea permanecer allí, no puede esperar solucionar todos los problemas al mismo tiempo. Es necesario tener en cuenta dos opciones: 1) evitar cosas rotas en el futuro; esto puede ser una prioridad más alta y 2) comenzar a arreglar las cosas que ya estaban rotas. No sé qué tan grande es su código base pero mi dinero está en esto: no lo volverá a escribir todo a corto plazo y si el próximo año consiste en reescribir las cosas rotas, de todas formas querrá irse. .

Me inclinaría hacia el movimiento si hubiera otras opciones alternativas viables. De lo contrario, dese un período de tiempo para ver cómo las cosas se ponen en forma y luego tome una decisión sobre si quedarse o no.

Básicamente tienes dos opciones:

1. Consigue un nuevo trabajo
2. Mejore su entorno de trabajo actual.

la opción 1. se explica por sí misma, pero para la opción 2, eso significa ser un buen programador a pesar de todo lo que sucede a tu alrededor. Religiosamente se adhieren a las buenas prácticas y convenciones. Trate de hacer que estas convenciones encajen con lo que ya existe tanto como sea posible (especialmente en las cosas en las que no importa demasiado, como nombrar convenciones: no tiene sentido hacer algo muy diferente a lo que se ha hecho antes que otras cosas » Terminaré en esta situación: xkcd )

Una cosa que todos odian (independientemente de la verdad real) es que se les diga que lo que han hecho es inútil; especialmente por un joven sin experiencia (me gradué hace 3 años, créeme, realmente no les gusta). Todo lo que puedes hacer es predicar con el ejemplo. Si no tienes suerte y nadie te sigue, al menos algunas de las áreas del código en las que trabajas comenzarán a mejorar. Si tienes suerte, algunas incluso pueden continuar con lo que has comenzado ... Joel Spolsky tiene un buen artículo sobre este tipo de cosas, también hay muchos otros excelentes artículos en su sitio web.

Recuerde también: ningún trabajo es perfecto, nadie escribe el código perfecto y, a veces, no es inmediatamente obvio por qué un fragmento de código en particular fue escrito como lo fue.

Haga bien su trabajo y escuche lo que otros programadores (especialmente aquellos con los que trabaja) tienen que decir. Si no está seguro de sus consejos, hágales preguntas, manténgalos vestidos y nunca los use para dar a entender que no cree que el sistema actual sea muy bueno. Mantenga las preguntas simples y espere una respuesta racional a ellas, de esa manera no levantará las defensas de las personas y obtendrá la respuesta que necesita o será felicitado por detectar un problema / falla que nadie más pensó.

Sugiere revisiones de código a tu programador principal. Esto proporcionará un entorno de no confrontación que puede criticar el código. También te ayudará a elegir técnicas para construir código estable en un entorno frágil.

Abordar solo los problemas específicos que menciona: los graves son 5, 8 y 9. Los usuarios no deben ver excepciones, las malas prácticas con las transacciones perjudicarán su desempeño (a menos que haya una buena razón para ellas: verifique esto antes de comenzar a abordarlo) y SQL debería nunca jamás ser inyectado. De hecho, el hecho de que la aplicación sea vulnerable a los ataques de inyección también indica que es lenta: las consultas parametrizadas son más rápidas porque la base de datos puede estar segura de que son valores y no tiene que verificar si hay uniones anidadas complicadas, etc. , más rápido, mejor experiencia de usuario: estas son cosas de las que debería ser posible persuadir a sus colegas y gerentes del valor real de.

Las otras cuestiones, aunque probablemente sean enloquecedoras (enfatizo que no sé javascript, por lo que no puedo hablar sobre el punto de jQuery), son cosas en las que probablemente solo tengas que dar ejemplo. Asegúrese de que lo que hace sea limpio y fácil de usar y entienda dado el resto de la base de código: el objetivo debe ser que los desarrolladores puedan asumir lo que hace sin una capacitación extensa, y los usuarios pueden hacerlo con (junto a) ningún entrenamiento en absoluto. (Bueno, dentro del alcance de lo que es la base de usuarios. ¡No lo hagas peor es lo que quiero decir!)

Y solo para agregar mis 5 centavos, de unos 20 años de experiencia, trabajando para diferentes personas (muchas) y que otros trabajen también para mí (o para mi equipo, lo que sea). Me estoy inclinando hacia lo que dijeron los nillls.
a) si es demasiado caótico, supongo que podría renunciar al trabajo, pero esa no es la respuesta, no encontrará muchas empresas "ideales" o códigos antiguos, siempre hay problemas, ya sea personas o códigos,
b) trabaje con él, el código y con ellos, la gente - lentamente, trate de hacer valer sus 'estándares' (o cualquier estándar en este caso:) - y explique, hable con ellos. c) No intentes revisar todo, ya que también puedes renunciar al trabajo. Por lo general, termina mal, o peor, todo es culpa tuya, incluso si son susceptibles, no quieres tanta responsabilidad, especialmente ser novato. d) trate de entender por qué es así; a menudo, hay una razón real por la que el código de la vida real es demasiado complicado: muy poco tiempo, demasiados programadores, etc. Es mejor si puede trabajar 'con el sistema', explique con argumentos (que lo que estás haciendo va a ahorrar dinero, mantener, etc.). Además, los proyectos reales nunca son divertidos, y la gente que realmente invierte dinero odia recibir sugerencias de alguien que esté interesado en hacer que las cosas sean "hermosas", así es como se ve su lado: tienes que defender tu caso, y básicamente lo bueno es lo que ahorra dinero A corto o largo plazo, trabaje en esa dirección.
e) olvídese de la codificación "adecuada" o de obtener una patada de la misma - considérela como el trabajo - obviamente tiene la experiencia tecnológica necesaria - trate de aprender las cuerdas con estos trabajos - dolores reales, lidiando exactamente con las situaciones en las que ' en este momento, de eso se trata la mayoría de los trabajos, al menos lo que he visto:)
f) y práctico, consejos de codificación -
haga 'fachada' su código - db o de otro modo
partes separadas que estás haciendo de su código
Aprendí eso y lo que a menudo funciona bien: tienes que integrar algunas partes, pero dado C # y todas las cosas puedes separarlas fácilmente.
... entonces, si no le gusta el código db, haga una pequeña "capa" que usaría, para comenzar, simplemente copie y cambie las cosas lentamente, pero estará construyéndolas correctamente, con una estructura y estándares seguros. y todo (no siempre es posible, pero la mayoría del tiempo)
... así también, podrías separarte de los errores un poco
Si no está relacionado con su error, entonces debería ser capaz de justificarlo. en realidad, úselo en su beneficio para mostrarles por qué el código antiguo crea problemas, mientras que el nuevo funciona perfectamente.
con alrededor de la base de datos es más difícil (dentro de la base de datos, diseño), pero siempre puede intentar y pedir, cambiar las cosas lentamente, campo por campo, índice por índice, etc.
y así sucesivamente en esta dirección
y por cierto este no es el peor trabajo del mundo, saque lo mejor de él, puede establecer sus propios estándares, hacer un mayor impacto, aprender otras cosas
Mejor

Cuando el código parece correcto, la lógica es correcta .

El proceso de cambio de formato y refactorización del código que se le encarga de corregir / cambiar es una técnica eficaz para detectar errores lógicos y casos de esquina no manejados. Es un código práctico que indica que su código depende de (vea la respuesta de Gaga, punto f, para obtener más detalles) . Enfoque de limpieza de código para el uso actual. Crear envoltorios o incluso una capa de API paralela puede ser una forma confiable de evolucionar la base de código mientras se mantiene la compatibilidad con versiones anteriores para el código dependiente que aún no se puede cambiar.

En mainframe y otros sistemas "heredados" donde el tiempo de inactividad no es una opción, donde las herramientas y los idiomas más modernos a menudo no están disponibles, y donde las nuevas contrataciones a menudo se encuentran mientras "aprenden las cuerdas", técnicas de mantenimiento de códigos como Estos pueden ser vitales para el éxito.

(revisado exhaustivamente del original según los comentarios a continuación)