No es una codificación "genial" si nadie más que los codificadores originales puede mantenerla (si recuerdan lo que hicieron y por qué).

La implicación aquí es que estos genios entraron en el código base, agregaron sus cambios, los probaron unitariamente sin importar si su porción de genio interfirió con la porción de genio de otro tipo y la rompieron por completo. Y supongo (por la actitud entusiasta), que no hay documentación de los cambios o documentación funcional actualizada, por lo que ahora nadie sabe qué cambios se realizaron, por quién, con qué propósito o quién los aprobó.

Y esta es la línea que le da a la gerencia

Puede ser genial, pero es imposible de mantener.

Todo lo que puede hacer por ahora es hacer que funcione de alguna manera antes de la fecha límite y luego analizarlo y hacerlo mantenible en etapas.

Si realmente no se puede hacer que funcione antes de la producción, depende de usted emitir un "No Go" y exponer los motivos. Esperemos que la gerencia entienda y retrase la implementación.

Ignore la política en esto: ese es el trabajo de su gerente. Solo cuéntale los hechos y deja que él se encargue de las consecuencias.

Como regla general, la gerencia "quiere soluciones, no problemas". Como tal, decir "hay secretos codificados en el código" es un problema, mientras que "Resolver falla regulatoria de secretos codificados: 0,5 días" es una solución.

Me tomaría unas horas evaluar adecuadamente el código y documentar todas las cosas que desea cambiar/arreglar en él para convertirlo en un "producto mínimo viable". Si hay alguna herramienta objetiva de análisis estático que pueda ayudarlo aquí, entonces mucho mejor: 100 problemas de seguridad en Code Climate o lo que sea que sea más difícil de discutir que su opinión profesional. Sin embargo, su opinión cuenta aquí y está tratando de dar una evaluación honesta.

"Producto mínimo viable" (MVP) es un término ligeramente subjetivo. Realmente depende de usted hacer lo suficiente para ejecutar algo en Producción y dejar que algunos o todos los usuarios propuestos lo vean. El administrador del sistema puede estar reiniciando cada hora, y puede haber configuraciones codificadas y secretos en todo el código, pero siempre que no muestre los detalles de su cuenta bancaria a la persona equivocada, está listo para funcionar. Arreglarás todos los errores, problemas y malas prácticas más adelante.

Ahora tiene una lista (una acumulación), que debe priorizar. Las estimaciones son difíciles, pero trate de cuantificar cuánto trabajo es probable que sea cada elemento. Asegúrese de marcar todo esto como estimaciones y no como un compromiso.

Escriba todo esto: comience con un resumen de uno o dos párrafos de los problemas y las soluciones. Luego, su 'atraso' completo (con una línea roja, debajo de la cual se encuentran los trabajos que podría hacer después de pasar a producción). Por último, apéndices con análisis de código estático o cualquier otra cosa que tengas.

A continuación, reserve un tiempo con su jefe y cualquier otra persona que sea realmente relevante (incluya suficientes personas, pero nadie que no tenga que estar allí al 100%). Incluya su informe como una "lectura previa" en su invitación a la reunión. Presente sus hallazgos (en resumen, no más de 10 a 15 minutos de conversación) y espere las preguntas. Consulte su informe en tantas respuestas como sea humanamente posible.

Por último, esperar una decisión. La forma en que responda su gestión es importante. Si deciden invertir en las soluciones que ha propuesto, entonces está bien. Si eligen no hacerlo porque van a reemplazar la solución con otra cosa, entonces está bien. Si intentan que haga algo "a bajo precio" o "más rápido" de lo que ha propuesto, entonces debe considerar su posición cuidadosamente, ya que están pidiendo cosas poco realistas y no están preparados para proporcionarles los recursos adecuados. tampoco, eso suele ser una señal de que tampoco decidirán invertir repentinamente una vez que el código esté en producción.

Desde un punto de vista práctico:

Su gerencia no sabe nada sobre código. Es una caja mágica que hace la cosa. Les prometieron la cosa, probablemente vieron una presentación sobre la cosa. La cosa es real. Ellos lo quieren. Lo pagaron y ahora tiene que funcionar.

Me he encontrado con que tienes que trabajar "alrededor" de la gestión, no tanto incorporarlos en el proyecto o en la toma de decisiones. No entienden sus problemas, sus necesidades o lo que es una buena práctica.
Por lo general, no les importa cómo, siempre que funcione. Se podría reescribir todo el asunto, siempre que en la superficie se parezca al asunto.

Te sugiero que trates esto como un proyecto nuevo.

• Analiza cuál debe ser el propósito de la cosa.
• Vea si puede crear la cosa en código limpio.
• Solo use el código incorrecto como referencia para obtener información sobre lo que se discutió al respecto y cómo debería funcionar en teoría.
• Recuperar código utilizable, refactorizarlo en algo práctico.
• Codifique la cosa limpiamente en los dos meses.
• Cuando termine, dígale a la gerencia, está hecho, todo funciona.
• Bajo ninguna circunstancia mencione que "borró" el código antiguo. Solo diga que lo refactorizó para que cumpla con las especificaciones.

La gerencia mira la caja negra y dice hurra.

Si dice que el código es basura, entonces su gerencia tiene dos opciones: confiar en usted o despedirlo. No confiar en ti y mantenerte en el proyecto no es una elección racional.

Y si no entiende el código porque es demasiado inteligente (he visto código que no quería entender, pero no hay código que no pudiera entender), entonces ese código debe eliminarse.

Es hora de sacar a relucir tus habilidades de redacción técnica. Cree un informe. Explique brevemente que no podrá hacer que el producto sea viable en 2 meses. Luego proponga una solución o soluciones en su informe y una estimación del tiempo y las ventajas y desventajas de esos enfoques. Por ejemplo:

'Opción 1: una reescritura completa. Mi estimación inicial es que esto tomará 11 meses, pero nos dejará con un código base robusto, funcional y mantenible.' (además, buena suerte para que se apruebe, todos los desarrolladores del mundo que ingresan a un nuevo proyecto quieren hacer una reescritura completa)

'Opción 2: lanzar más desarrolladores al problema. Necesitaremos X desarrolladores más para sacar esto a la luz en 2 meses. Esto costará más y perderemos tiempo de desarrollo en otros proyectos, pero (probablemente) lo sacaremos adelante'.

'Opción 3, trabajo al máximo y trato de hacer todo lo posible. No creo que pueda completar todo el producto, pero aquí hay un ejemplo de un MVP que creo que puedo hacer. ¿Hay alguna característica que le gustaría que priorizara sobre las que he presentado aquí?'

Etcétera.

Luego, como apéndice, describa brevemente (en términos sencillos) los problemas tal como nos los ha descrito, y considere proporcionar referencias para que tenga cierta credibilidad detrás de sus argumentos.

La idea es presentar soluciones de inmediato para que sus gerentes puedan priorizar este producto. ¿Están bien esperando más tiempo? ¿O necesitan arrojar más recursos en él. Sea razonable y profesional.

Editado para centrarse más en ofrecer soluciones en lugar de criticar el código, según los comentarios a continuación.

Tienes que socavar la reputación de los cachivaches mágicos.

No puedes decirles que apesta, porque entonces se sentirán estúpidos y decidirán que eres estúpido para poder volver a sentirse inteligentes.

Si ya lo hiciste compilar, me saltearía eso. Era una oportunidad para socavar el accesorio mágico, pero ahora que lo arreglaste, no querrás quejarte.

Comenzaría con las contraseñas codificadas y sin cifrar. Llévelos a la gerencia y señale que esto tiene el potencial de causar muchos problemas. Arregla las contraseñas y sigue adelante.

Las funciones no llamadas y las API de galimatías pueden esperar. Si en realidad no hacen nada, probablemente tampoco puedan romper nada. Pasaría a las direcciones IP o bibliotecas.

Cuando encuentre un problema con el objeto mágico, asegúrese de comunicárselo a la gerencia y luego explíqueles cómo lo solucionó . Con el tiempo, te convertirás en su accesorio mágico, lo cual es genial.

Recoger los problemas que está viendo en una forma estructurada relacionada con su impacto comercial práctico lo ayudará mucho:

Piense en los problemas y la evidencia que pueda encontrar, y agrúpelos de esta manera:

1. Observaciones que sugieren que, si se pone en el mercado, fallará en su uso y generará reacciones negativas . No se puede compilar. Hay errores lógicos en el código. La entrada no está validada. Los datos no se procesan en una ruta que garantice una alta probabilidad de no corrupción. Los aspectos de seguridad no están en su lugar y los datos podrían ser exfiltrados/hackeados. No se puede garantizar que las funciones clave funcionen por una buena razón, o puede mostrar que las pocas que ha verificado de todas ellas, a menudo, en realidad no funcionan según lo previsto. Esa clase de cosas.
2. Observaciones que sugieren que puede haber problemas que no se revelarán en las pruebas, pero que conllevan un riesgo sustancial de problemas si se comercializan. Al igual que arriba, pero el n.° 1 es algo que ha encontrado, esta es una evidencia que sugiere que se esperan/anticipan/consideran un riesgo significativo problemas significativos no encontrados. Por ejemplo, si ha corregido casos extremos relacionados con el procesamiento incorrecto en algunos casos de validación de datos, eso sugiere que pueden existir otros casos y no se conocen, lo que podría provocar la pérdida/corrupción de datos. Si utilizaron enfoques obsoletos/dudosos conocidos para un problema, eso sugiere que hicieron lo mismo en otros problemas. Si la base de datos está sujeta a condiciones de carrera/actualizaciones no atómicas en un área, sugiere que esto podría ser un problema en el código en general. Y si es multiusuario pero el procesamiento del lado del servidor no permite que la entrada/procesos de múltiples usuarios colisionen de manera sutil, eso sugiere que podría colapsar bajo las cargas adecuadas.
3. Observaciones que sugieren que la tripulación original engañó a la gerencia(Deliberadamente o no, o tal vez simplemente por no ser contundente y fácilmente anulado/ignorado: ¡podría haber sido culpa de la gerencia, no de ellos!). En este momento, el equipo anterior es un regalo de Dios para la administración porque han entregado un producto brillante. Tienes dudas con ellos porque, aunque es un gran producto, no estás contento, no puedes hacerlo funcionar, no lo entiendes, etc. Pero si tienes observaciones que contradicen directamente las cosas que han dicho, entonces te vuelves el que sabe lo que pasa y el zapato se les vuelve en contra. Entonces su trabajo se vuelve más fácil. Por ejemplo, si le dijeron a la gerencia que el proyecto tiene la seguridad webUI adecuada y usted observa lugares donde no validaron la entrada/secuencia de comandos cruzada/inyección de SQL,
4. Observaciones que muestran que, si se ponen en el mercado, los niveles habituales de seguimiento/expectativa/servicio serán poco prácticos/inviables, o los costos serán mucho mayores de lo esperado. Por ejemplo, si el código es demasiado pobre o carece de aspectos de depuración, cuando un cliente tenga un problema, no habrá una forma práctica de rastrear el error y, sea cual sea el problema, puede llevar semanas, no horas, solucionarlo. Si el código se repite, esto significa que no se puede cambiar la validación o mejorar las estructuras de datos "solo en un lugar". Si no está documentado o está mal estructurado, los intentos de realzarlo o mejorarlo se verán gravemente obstaculizados porque no habrá una forma práctica de hacer un desarrollo significativo y asegurarse de que las cosas no se rompan, o de lo contrario, la verificación de roturas llevará tanto tiempo como para ser antieconómico. Si es un desastre, una vez en el mercado dependerán de usted personalmente cada vez que surja un problema; ya que no puede garantizar estar allí los fines de semana y a las 11 p.m. solo debido a un error en la fecha límite del cliente, o podrías caer debajo de un autobús, ¿qué harán? Si los datos se pueden manipular pero necesitan una atención manual excesiva, es posible que su soporte en producción no pueda escalar para proporcionar eso, o para garantizar que se pueda mantener lo suficientemente simple, por lo que los errores de procesamiento pueden ser de mayor riesgo. Si depende de plataformas específicas y esas plataformas no se administran claramente en el código, es posible que los cambios en las plataformas (actualizaciones de Windows, lanzamientos de navegadores, versiones de bibliotecas) no sean factibles en escalas de tiempo habituales o comerciales, o arreglar cualquier cosa que rompan puede ser complejo. , dejando a los clientes incapaces de mantener o usar sus plataformas como se esperaba. por lo que los errores de procesamiento pueden ser de mayor riesgo. Si depende de plataformas específicas y esas plataformas no se administran claramente en el código, es posible que los cambios en las plataformas (actualizaciones de Windows, lanzamientos de navegadores, versiones de bibliotecas) no sean factibles en escalas de tiempo habituales o comerciales, o arreglar cualquier cosa que rompan puede ser complejo. , dejando a los clientes incapaces de mantener o usar sus plataformas como se esperaba. por lo que los errores de procesamiento pueden ser de mayor riesgo. Si depende de plataformas específicas y esas plataformas no se administran claramente en el código, es posible que los cambios en las plataformas (actualizaciones de Windows, lanzamientos de navegadores, versiones de bibliotecas) no sean factibles en escalas de tiempo habituales o comerciales, o arreglar cualquier cosa que rompan puede ser complejo. , dejando a los clientes incapaces de mantener o usar sus plataformas como se esperaba.
5. Observaciones que simplemente te molestan . Ese es tu trabajo. Si no entran en las categorías anteriores, arréglalos lo mejor que puedas en tu tiempo libre. El problema de la administración son los primeros 4 artículos anteriores, no esto.

Estos le ayudarán a alinear su perspectiva técnica y "práctica" con su perspectiva empresarial. Si puede demostrar que hay problemas en las primeras 4 categorías anteriores y exponerlos claramente, estará bien encaminado para solucionar su propio problema, mostrándoles buenas razones por las que es su problema y no su falta de competencia.

Si reúne una lista como esta y parece convincente, haga una presentación, preséntelos y guíelos a través de problemas de ejemplo, incluido código específico o fragmentos de flujo de datos que ejemplifican el punto.

Tu presentación

Para que sea efectivo,

• Encuentre otro codificador en el que confíen, o pida permiso para traer a un colega por un día, y tenga a alguien que esté preparado para ayudarlo. De esa manera, no todo depende de usted; tienes a alguien más que puede decir: "Sí, me mostró este código, y lo siento, no está exagerando la seriedad".
• Espere tener que educar un poco, brevemente. No son programadores pero tienen sentido común. "Es por eso que usamos código estructurado, exactamente para que podamos hacer cada tarea una sola vez, aislar las partes y estar seguros de cómo interactúan las piezas. Pero estos tipos no lo hicieron, mira aquí , aquí y aquí . Entonces surge el problema de que en su código, no puedes ver cómo interactúan las piezas, o si hay errores lógicos o inconsistencias, y no puedesasegúrese de que las partes independientes realmente sean independientes, o que todo se debe cambiar en otro lugar si es necesario cambiar algo, o incluso que se comportará bajo cargas del mundo real, como lo hace durante la prueba. Suponiendo que podamos probar esto de manera realista y arreglarlo en menos de 3 años de trabajo a tiempo completo por parte de un equipo de diez, lo cual es dudoso. Esa es exactamente la razón por la que los profesionales codifican de manera cuidadosa, porque sabemos que, de lo contrario, el impacto en el negocio es grave".
• Espere ser presionado o coaccionado para decir que no es tan malo. Habla claramente. "Lo siento, lo que sea que te hayan dicho, claramente lo que crees que es el caso no lo es. Aprecio que sea un shock, pero como profesional, también es así". Dígales: "No, no es un trabajo de alta calidad, es un trabajo criminalmente descuidado y les han mentido todo el tiempo". (Sí, puedes decir eso para enfatizar, ¡no es como si estuvieras diciendo que son criminales!) Di "Sí, lo siento, pero estoy seguro".
• Entra con detalles. Si solo dice "Las teclas Ssh están en texto sin formato", eso es genial para alguien en su nivel y lo ve como lo hace. Para la gerencia bajo presión y creyendo que es genial y por qué tanto alboroto, es demasiado inespecífico. En cambio: "Las claves de cifrado utilizadas para evitar que el panel de configuración del cliente para usuarios remotos se almacene de manera insegura, de una manera que cualquier persona con conocimientos mínimos diría que roza lo criminalmente descuidado " . ¡¡Están diciendo que son criminales!!) . Si miras aquí (OK, no pueden seguir el código, pero sacan el código y apuntan a ese bit de todos modos, por credibilidad)verá que la clave está almacenada en formato abierto. Ni siquiera han hecho el cifrado básico de la década de 1990. Ponga esto en línea y los datos del cliente/usuario serán pirateados tan pronto como alguien piense que vale la pena los 10 minutos que tomará". Muéstreles " Aquí , aquí y aquí puede ver una llamada al sistema de rutina [API] que puede o puede No se rompe en varios casos, porque se dan datos incorrectos para la llamada". Dígales "Estos son errores básicos fundamentales. Es así en todas partes". Muéstreles "En este módulo usan esta biblioteca, pero aquí usan esa biblioteca. Pero el fabricante deja en claro que las dos bibliotecas en realidad no son compatibles.ambos se pueden usar en el mismo código, porque puede dejar datos incorrectos/puede corromper datos/porque la salida de uno se procesará incorrectamente/se corromperá/se manejará mal si se le da al otro". Así, en términos para que puedan dar sentido a y vea la importancia de ello. Dígales "¿Puedo arreglarlo? Bueno, dicho de otra manera, si esto es tan grave, ¿qué tan realista crees que es rehacer toda la infraestructura de seguridad para el proyecto en menos de 6 meses?" Ese tipo de enfoque. Haz que lo vean.
• Ir con una solución pre-pensada. ¿Qué harías en sus zapatos? De hecho, vaya con 3 soluciones y pros/contras/estimaciones aproximadas del impacto de estas. Nunca olvides que "no hacer nada" o "adelante de todos modos" es una opción , inclúyela (y sus pros/contras/riesgos) en tu lista también.
• Deles tiempo para estar conmocionados, molestos, en negación y en modo de culpa. Es humano y ellos también tienen presiones. Espere que esto suceda, y siéntese, acepte su conmoción, guíelos para superarlo, recuérdeles amablemente que la búsqueda de culpas y las autopsias pueden esperar; en realidad no resuelven los problemas de la empresa. Sea su asesor.
• Si es necesario, después de un tiempo, simplemente diga: "Tengo algunas soluciones propuestas. Ninguna es ideal; lo ideal sería que este lío no existiera. Pero son viables. Ha sido una sesión intensa. Tomemos 10 minutos/¿Podemos reunirnos?" nuevamente después de un breve descanso para tomar café/después del almuerzo/tengo una reunión, nos vemos después de eso, para centrarnos en las soluciones y lo que podemos hacer para solucionar esto". Poner esto en una reunión separada después de un "cambio de escena" mental, incluso al otro lado de un descanso para tomar café, ayudará mucho.
• Decir que tiene soluciones a menudo puede esperar un poco, hasta que hayan ocurrido las primeras explosiones, porque la reacción humana a menudo será ignorarlo o negar la necesidad, en las primeras etapas. Solo una vez que dispersen algo de su malestar (si son de ese tipo) vale la pena decir esto, porque en muchas personas, simplemente no lo escucharán si se dice cuando todavía están en un modo de culpa avergonzado enojado acalorado. Si eso no es un problema, vaya directamente a las soluciones después de explicar la gravedad/riesgo del impacto, si cree que están escuchando.

Evite cuidadosamente cualquier cosa que pueda implicar que está siendo perfeccionista o que está haciendo más que lo mínimo para la viabilidad del mercado. Cualquier cosa más que lo esencial, en este punto, simplemente no es una prioridad.

Soluciones prepensadas y tono

En cuanto a una solución prepensada, la mía sería, recursos adicionales. Si no te creen, todo está muerto de todos modos (suponiendo que tengas razón). El software se derrumbará y la asociación lo quemará: busque nuevos trabajos que comiencen ahora. Pero si después de su presentación, le creen, están preocupados o buscan que usted lo arregle, esto se convierte en su beneficio.

Porque lo que necesitas es un equipo . Póngalo algo como esto:

"Lo siento chicos, pero 1.5 G de código como este, sin elementos básicos ni documentación, llevará un año más o menos entenderlo, tal vez 5 años arreglarlo. Tal vez sea necesario reescribirlo y podemos guardar lo que se puede reutilizar, tal vez solo partes de la GUI, los conceptos básicos de flujo de datos, para no reinventar la rueda, y luego rehacer el back-end y todo lo demás".

"La primera prioridad, tal como lo veo, es la evaluación. Puedo ver que es malo, pero ¿qué tan malo y cuál es el mínimo para que sea seguro pasar a la producción?" [refleja su preocupación de alto nivel]

"Tal como lo veo, necesitamos saber que dentro de 4 a 6 semanas, yo diría que 3 semanas, pero es una tarea importante en sí misma y necesita una revisión línea por línea. 4 a 6 semanas con un equipo de 3, y sabremos qué tan grave es el daño". [Si no puede, o es demasiado grande, sustitúyalo por lo que sea sensato]

"Entonces, tenemos que arreglarlo. Puedo quemar las velas pensando qué hacer, pero necesito manos en los teclados. Cualquier cosa de 4 a 6, por hasta 6 meses".

[Si es relevante, agregue: "Y necesito un número 2 competente para ello. No puedo revisar todo lo que pusieron, solo, si también estoy navegando por los problemas y las soluciones". ]

"Es un dolor que sea tan severo, pero es lo que es, y primero tenemos que cavar para salir del hoyo, y culpar y litigar más tarde. Para eso, dame 2 personas por ahora, y presupuesto para otras 2 o más". 4 en alrededor de 4 a 6 semanas, y lo conseguiré, bien hecho. O al menos mínimamente viable". [Nuevamente, si no puede, o es demasiado grande, sustituya lo que sea sensato en su lugar]

"También puede pedirle a [nombre de un contacto que conocen, que es director en algún negocio de TI adecuado] que envíe a alguien por un día, para verificar dos veces mi vista inicial, enfoque y tiempo, antes de comprometer un presupuesto. será bueno y también tranquilizador. Pero si funciona, y lo hará, entonces tenemos que movernos rápido, y lo único que ahorrará nuestro tiempo de comercialización es arrojar recursos rápido y en gran medida".

"Esa sería, en mi opinión, la solución sensata. No podemos usarlo tal como está, y perdemos más por retrasos y daños que lo que ahorramos pagando a los contratistas o sacando personal de otros trabajos".

"Lamento traer malas noticias. La buena noticia es que podemos salir del hoyo".

"¿Preguntas?"

Lo que intentaría hacer:

Concierte una reunión en persona con el gerente (su jefe, el líder del proyecto, quien sea el máximo responsable de este código). Dígale con palabras amables pero claras que el código no funciona y arreglarlo no será cuestión de semanas. Si no te cree, ofrécete a mostrárselo a otros desarrolladores para obtener una segunda opinión.

Lo que usted piensa y lo que piensa la gerencia no es relevante. Tienen un producto que quieren entregar y usted tiene un montón de código heredado que ha intentado convertirse en ese producto.

En su estado actual, o funciona correctamente como ese producto o no. Si no es así, lo que queda es desarrollar un plan para hacer uso de los activos disponibles (su tiempo y habilidad más cualquier componente útil del código que haya heredado) para producir ese producto. No es necesario insistir en las deficiencias del código que ha heredado; lo que importa es que desarrolle un plan para convertirlo en el producto que debe ser.

A su gerencia le gustaría que eso sucediera dentro de un plazo determinado. O puedes administrar tu tiempo para lograr ese objetivo o no puedes. Si no puede, necesita más recursos y debe hacérselo saber. Si no hay más recursos disponibles, entonces se debe sacrificar el plazo. Es así de simple. Lo que quieren de ti es un plan: debes descubrir cómo se puede hacer. Insistir en todas las razones por las que no se puede hacer no es constructivo. Es lo que es: tienes que lidiar con eso y seguir adelante.

Hay dos cosas que haría aquí:

1. Enmarca la situación. Hay algunas señales de alerta, por lo que es fundamental que no diga nada para inducir a nadie o para asegurarles que todo estará listo a tiempo. Recuerde que los problemas/condiciones del código base son el resultado de quienes trabajaron en él antes, pero tan pronto como comience a asumir la responsabilidad, será responsabilidad suya. No se permita ser un chivo expiatorio.

2. Evalúe lo que hace el producto en su estado actual frente a los requisitos comerciales establecidos. El error que está cometiendo es que se está enfocando demasiado en la calidad del código, lo cual es subjetivo (no puede darse el lujo de pelear esta batalla ahora). A la gente de arriba realmente no le va a importar eso, les importa si funciona o no. Hazlo de manera objetiva. Si les dijeron que algo funciona y no funciona, debe poder documentarlo y demostrarlo. Desde aquí, puede comenzar a estimar cuánto tiempo realmente necesita y respaldarlo con hechos/elementos de trabajo reales.

En resumen: sea honesto, sea objetivo, no prometa demasiado y evalúe en función de los requisitos comerciales en lugar de la calidad del código. También desea ser visto como un solucionador de problemas, no como un creador de problemas, así que asegúrese de concentrarse en la solución y el camino a seguir.

Siento ser el portador de noticias cínicas pero...

Si fuera tan ingenioso, no te lo habrían entregado 2 meses antes de la fecha de lanzamiento, a menos que piensen que posees tanto o más ingenio que los desarrolladores anteriores.

Esto suena como una configuración para el fracaso. La gerencia sabe que esto es un lío, pero necesita pasarle la responsabilidad a algún trabajador desprevenido para que pueda culpar a los demás en lugar de a sí mismos una vez que la alta gerencia comience a solicitar actualizaciones de estado.

Si ha presentado el estado de este código a la gerencia como lo ha hecho con nosotros, y todavía están convencidos de que está en perfecto estado de funcionamiento y solo se necesitan dos meses para la entrega...

No puedes hacerles cambiar de opinión, ya están convencidos de esto. O peor aún, son conscientes del problema y están tratando de jugar a la ignorancia para poder pasarte la responsabilidad cuando falla.

Todo lo que puede hacer en este punto, si desea mantenerse comprometido con el proyecto, todo lo que puede hacer es abrocharse el cinturón y hacer todo lo que esté a su alcance para que este código funcione, incluso trabajando horas extras.

Además, le recomiendo encarecidamente que practique a través de la documentación, tanto dentro como fuera del código, de modo que cuando se le culpe de una falla en la aplicación, pueda, al menos, demostrar que ha ido más allá. el llamado del deber de salvar tanto como puedas.

Con suerte, alguien en la gerencia será lo suficientemente inteligente como para reconocer a un codificador trabajador que quiere esforzarse para arreglar su proyecto de desastre.

Dicho esto, este proyecto suena extremadamente mal administrado. Le aconsejaría que dedique algo de tiempo a repasar su currículum o buscar una transferencia dentro de su empresa a un nuevo proyecto. Porque por lo que has dicho, las cosas no pintan bien para este.

Como enfoque alternativo, podría sugerir que otro desarrollador eche un vistazo a esto. Dos, tres o quince personas que digan que no funciona y que no funcionará pronto podrían convencer a la gerencia.

Solo funciona si hay alguien más que no está interesado en el proyecto y, por lo tanto, no tiene que enmascarar la verdad.

En primer lugar, no asuma que el código es tan "malo".

Prácticamente cada vez que he visto a un nuevo desarrollador llegar a un proyecto, pronuncian mal el código, sin importar cuán bueno o malo sea o quién lo haya escrito. Una vez que había estado trabajando en un producto durante dos años, contrataron a un nuevo contratista y le dijo a mi jefe que mi código era un código "espagueti" sin valor y necesitaba ser reescrito. Lo despidieron unos 2 meses después por falta de productividad.

En general, debes resistir la tentación de reescribir todo.

Trate de limitar sus cambios a lo que sea necesario. No estás tratando de crear la Mona Lisa aquí; empezar haciendo lo mínimo para lograr lo que sea necesario hacer. Si cree que eso significa reescribir todo el proyecto, probablemente el problema sea usted, no el código.

No hay absolutamente ninguna razón para hacer comentarios editoriales sobre la calidad del código a su jefe. Estás ahí para agregar funcionalidad, no para ser un crítico de cine. Guarda tus opiniones para ti mismo, hasta que hayas probado tu valía.

Siento que tengo que agregar una respuesta específicamente porque ya ha aceptado una. No está exactamente mal, pero, en mi opinión, no se entiende el punto.

Olvida el código por un momento. No será el primero ni el último código postal que tenga que mantener. Como se sugiere, trabaje hasta que obtenga una apariencia de un código base funcional, intente hacer coincidir los plazos, etc.

La parte que necesita tanta preparación y cuidado es tu propia situación: te diriges de cabeza a una fase crítica de tu vida, en la que tú mismo podrías ir a por los perros si no prestas atención. Tal como está ahora, según su descripción de su situación, todos los que están por encima de usted creen que todo está bien, que tienen una mina de oro y que realmente no hay problema.

Las pocas citas que ya diste parecen sugerir que no te creen y piensan, bueno, no exactamente mal de ti, pero al menos neutralmente; usted no parece tener posición con ellos. No importa cuán malo sea el código. Si no funciona en la fecha límite, será su culpa y solo su culpa. Puede documentar todo lo que quiera, pero las citas que dio parecen claras en el sentido de que no están interesadas en argumentos y tampoco le creen del todo.

El problema no es necesariamente que sean malvados o que te persigan. Es un problema común que las personas en un cierto nivel piensen de manera muy diferente a las personas en otro. Eso no es culpa de nadie, pero así es a menudo. Ver; con tanta frecuencia escuchan a los técnicos quejarse de lo difícil que es una tarea o de lo rota que está una aplicación, que para ellos es como un ruido de fondo. Ellos no quieren escucharlo. No es un argumento válido en su mente. Y tienen razón en eso: no es su trabajo conocer los detalles técnicos (y la calidad del código es parte de un detalle técnico...). Lo que sí necesitan saber es lo que te estás perdiendo para alcanzar ese objetivo.

Entonces, en una situación óptima, tendría suficiente influencia para decirles "Necesito 3 personas más y un experto en XYZ para cumplir con este plazo". Proporcionan lo que pides, llegas a la fecha límite y todo está bien.

Desafortunadamente, no veo ninguna señal en tu publicación de que tengas esa influencia. Parecen predeterminados a que usted, y solo usted, solucionará los problemas. Cuando no cumple con la fecha límite (y especialmente cuando comienza a culpar al código), entonces, dependiendo de dónde viva, es un nuevo trabajo para usted, o al menos su carrera en esa empresa podría haber terminado.

Entonces: tenga un gerente de su lado, tal vez un líder de equipo que todavía tenga raíces en el aspecto técnico. Encuentre un entrenador en su empresa que pueda hablar por usted o con usted y ayudarlo a asignar más trabajadores. Pero lo que es más importante: prepárese para una fase de estrés extremo, no porque tenga que trabajar horas extras, sino porque puede encontrarse con discusiones que le parecerán extremadamente injustas/hirientes, y extremadamente desafiantes y deprimentes. Esté atento a los signos de agotamiento, depresión u otros síndromes de estrés (por ejemplo: no encontrar la energía para hacer más deportes, no poder hablar normalmente con su familia, etc.), y tire de la línea antes de sufrir daños.

¡La mejor de las suertes!

(Fuente: BTDT)

Esta situación es típica de lo siguiente que ha sucedido:

En el punto A en el tiempo, existe un conjunto de reglas comerciales para un proceso y se conoce, aunque no está documentado formalmente (o la documentación se destruye por error más tarde, consulte el punto D).

En el punto B en el tiempo, estas reglas comerciales se implementan en el código, trabajando junto con aquellos que las conocen. La existencia del código es un incentivo para no documentar las reglas de negocio, y olvidarse de ellas y/o dejar de preocuparse por no ser olvidadas.

En el punto C en el tiempo, el código está en uso y, dado que funciona, no es NECESARIO conocer las reglas comerciales detrás de él la mayor parte del tiempo. El código ES el conjunto de reglas comerciales de facto ahora.

En el punto D en el tiempo, una cantidad crítica de personas que tenían el conocimiento del punto A abandonaron la empresa, olvidaron las reglas comerciales o descartaron la documentación existente por obsoleta. Nadie se da cuenta.

En el punto E, el código comienza a mostrar defectos debido a cambios en el entorno o necesitaría cambios funcionales. Estas necesidades se resuelven en lugar de satisfacerse, ya que si bien cualquier extensión o corrección de código se puede realizar técnicamente, no hay una manera fácil de PROBARLAS, ya que las reglas comerciales que dictaron qué debe considerarse una entrada válida y qué es una salida válida, son parcial o totalmente desconocidos.

Lo que empeora esa situación es un eterno dilema sobre la documentación: mantener la documentación antigua y desactualizada es importante; al mismo tiempo, no saber en un momento posterior si la documentación que tiene está incluso más desactualizada que la que existía, ya que nadie lo sabe. si existe una versión más actual y se ha extraviado o se ha destruido.

¿Puedo preguntarte por qué quieres trabajar aquí? Su proyecto es un desastre, lo cual es malo en sí mismo, pero a algunos les gusta el desafío de limpiar algo como esto. El verdadero problema aquí es que aparentemente a un grupo de programadores se les ha permitido trabajar en un producto durante meses (1.5 gb de código, malo o no, no es un trabajo de unas pocas semanas), aparentemente también abandonaron este proyecto, y la gerencia ha estado tan alejada del proyecto que ni siquiera conocen el estado actual del mismo.
Estas son enormes banderas rojas para mí. ¿Cómo va a ser capaz la gerencia de administrarlo y permitirle hacer su trabajo de manera eficiente si no pudieron hacerlo con el grupo anterior? ¿Por qué se han ido todos los programadores anteriores? ¿Cómo vas a crecer y aprender en esta empresa cuando aparentemente no les importa un carajo la calidad del código? Pero quizás la pregunta más importante de todas, ¿quién será su recurso cuando surjan problemas?
Tal como está actualmente, no tiene la seguridad de que no será arrojado debajo del autobús la próxima vez que las partes interesadas exijan una demostración. Este es un entorno tóxico y es muy probable que los programadores anteriores se hayan ido por eso, y ahora la gerencia está tratando de encubrirlo afirmando que es un "código genial" y que "ya está en producción", cualquier cosa para distraerte del montón de estiércol gigante. ese es tu proyecto heredado.

Su plan de alto nivel debe ser el siguiente:

1. Diseñar un camino a seguir. (*)
2. Calcule cuánto tiempo llevará implementar su "camino a seguir".
3. Reúnase con las partes interesadas del negocio y comunique lo siguiente:
   1. Que no puede compilar/ejecutar el código actual (si eso sigue siendo cierto).
   2. Que le tomará 'X' días/semanas rehabilitar el código base en un estado compilable/construible/ejecutable.
   3. Que hay trabajo adicional , más allá de hacer que el código sea compilable, que debe hacer para que el código sea compatible y extensible.
   4. Que le tomará 'X' meses implementar su camino a seguir. Luego explique su camino a seguir.(**)

--

(**) Esto es muy importante porque deberá persuadir a las partes interesadas comerciales no técnicas de que su plan es sólido, factible y valioso.

--

(*) Aquí está mi recomendación para un camino a seguir, que puede comenzar inmediatamente después de que pueda compilar, compilar y ejecutar el código.

1. Cree pruebas unitarias automatizadas.
   1. Las pruebas unitarias demostrarán que comprende el código.
   2. Las estadísticas de cobertura de código le recordarán continuamente qué partes de la base de código comprende y qué partes aún necesita sondear.
2. No permita que nadie se fusione con la rama maestra sin una solicitud de extracción que haya sido aprobada por al menos dos personas.
   1. Las solicitudes de extracción socializarán la comprensión en evolución de su equipo sobre la base de código.
3. Fomente una cultura de apoyo, especialmente durante este momento difícil, entre sus desarrolladores.
   1. Trate de no perder la calma. Otros desarrolladores notarán su frustración y pueden frustrarse ellos mismos.
   2. Cuando un desarrollador tiene dificultades con algún código heredado complicado, aliente a otros desarrolladores a que le echen una mano y aborden juntos el código difícil, tal vez con programación en pareja.

Dev aquí con alguna entrada:

Sus preocupaciones sobre el código son semi-válidas en el mejor de los casos:

Hay la misma función, los mismos nombres de variables del mismo alcance en todo el código base (en un idioma que no admite eso).

Si el idioma no lo admite, ¿cómo se publica una versión? Parece que te estás perdiendo algo aquí.

Las funciones se definen pero nunca se llaman.

¿Qué afecta esto? ¿Quizás fue apagado por algo que nunca se implementó? ¿Tal vez sea para completar la API?

Uso e inicialización de variables fuera de servicio.

Esto es común en el código bajo mantenimiento, aunque no es ideal en su situación, nuevamente esto es común en el código anterior.

Versiones incompatibles de bibliotecas utilizadas.

Ver #1, ¿cómo surgió?

URI y direcciones IP codificadas sin documentación sobre lo que hacen.

No es ideal, pero de nuevo, ¿qué afecta en términos de entrega?

Rutas de API solicitadas aleatoriamente que no devuelven nada o un galimatías; que luego no se utilizan.

Ver #2 de nuevo

Contraseñas codificadas, sin cifrar y claves ssh privadas.

Ver #5 de nuevo

Ahora, después de abordar esas preocupaciones como inconvenientes, pero triviales, tengo una preocupación válida sobre si usted establece algún tipo de dirección, lo siento, así es como es en la industria por lo que he visto.

Sin embargo, tengo un pequeño consejo: necesita un tipo diferente de entorno de codificación, como... una tienda de códigos, así que busque una empresa de comercio electrónico o tecnología, donde los estándares de codificación están mucho más cerca de la sangre vital de el negocio que decir finanzas o fabricación.

En cuanto a llevar sus preocupaciones a la gerencia... Me gusta la respuesta de Tschallacka. Simplemente arregle lo que está mal sin decirle a la gerencia y tírelo como experiencia profesional que luego puede incluir en un currículum. Creo que sé el tipo de administración de la que está hablando (opiniones personales a un lado) y están ahí para administrar, no para innovar, por lo que trabajar en torno a ellos es el camino a seguir si desea hacer lo último.