¿Cómo puedo evitar errores críticos en un nuevo entorno de código?

Con varios desarrolladores que realizan cambios en la misma base de código (y no siempre están actualizados entre sí), estas cosas sucederán. Yo mismo soy un desarrollador; no es nada para obsesionarse, nos pasará a todos al menos una vez. Sin embargo, hay un par de cosas que puede hacer para reducir el riesgo de que vuelva a suceder.

Por el contexto, parece que probaste todo localmente y funcionó bien. Fue solo más tarde que algo salió mal. Esto sugiere que su propia base de código estaba un poco desactualizada y/o que alguien más tenía un código desactualizado cuando realizó sus propios cambios. Lo mejor que puede hacer, justo antes de confirmar su código, es extraer cualquier cambio reciente de su repositorio (o como lo llame) para que pueda estar seguro de que sus cambios funcionan con el código más actualizado. Si pasa todas sus pruebas, entonces puede comprometerse con la conciencia tranquila.

También sugeriría hablar un poco más con sus colegas. Si está realizando cambios en un sistema crítico, menciónelo. Incluso si se trata de una solicitud simple como "Estoy a punto de cambiar esta parte importante, ¿tienes tiempo para revisar el código?" . De esta manera, su equipo no pasará días buscando el problema, si lo hay, y puede estar tranquilo sabiendo que usted Y sus colegas confían en los cambios. Algunos equipos de desarrollo hacen stand-ups diarios donde expresan en qué están trabajando; ayuda al equipo a ser más consciente de en qué está trabajando y si existe el riesgo de que sus cambios entren en conflicto con los de otra persona.

Aprenderás haciendo. Si está bien versado en lenguajes como C #, ¡podría aprender Java más rápido de lo que piensa!

Esta situación ocurre de vez en cuando: haces algo que tiene efectos colaterales imprevistos en otra cosa que no conocías antes.

El hecho de que no lo despidieran de inmediato o lo pusieran en un PIP significa que la empresa reconoce que ocurren errores, se solucionan y la vida continúa en consecuencia.

¿Qué puedes hacer al respecto? Conozca esta consecuencia y vea si hay algo más relacionado que debería haber tenido en cuenta o cualquier otro equipo al que debería haber preguntado sobre los efectos colaterales de cambiar una API.

Todo es parte de la acumulación de experiencia y no debería desanimarte a seguir adelante.

La forma de evitar este problema también le brinda la oportunidad de contribuir significativamente a su nueva empresa: la raíz de este problema son las pruebas inadecuadas, no usted (a menos que haya sido negligente de una manera que no aparece en su publicación).

En todos los entornos de desarrollo, debería ser posible averiguar si el cambio que ha realizado va a causar una falla importante antes de registrarse, así como averiguar si el código va a romper la compilación. Si bien definitivamente es vergonzoso ser el que encuentra un todo tan enorme en el proceso de la empresa, ahora puede ser un líder al tratar de establecer dicho proceso en su nueva empresa.

Puede proponer que el equipo comience a escribir pruebas unitarias y comience a configurar un entorno de integración continua que reconstruiría el proyecto y ejecutaría las pruebas unitarias cada vez que se registre el código, y donde las pruebas se puedan ejecutar individualmente antes del registro. Las pruebas unitarias requerirán el compromiso del equipo, pero se puede configurar un entorno de CI básico con bastante rapidez a partir de proyectos de código abierto, siempre que pueda dedicarle una máquina virtual o un servidor.

Editar: las revisiones de código son otra buena práctica de programación que puede minimizar este tipo de errores, y también es bastante fácil de poner en marcha.

TL; DR aproveche esta vergonzosa oportunidad para modernizar los procesos de desarrollo de su empresa. Saldrás oliendo a rosas.

El problema surge cuando se hace referencia a la API en un archivo de flujo de trabajo BPMN que no se mostró cuando busqué las referencias o el nombre de la API como texto en el IDE.

¿Qué hizo la retrospectiva de los equipos con respecto a este incidente? ¿Qué procedimientos del departamento podrían implementarse para que esto no se repita? ¿Qué cree el equipo que es necesario cuando se incorporan nuevos desarrolladores? ¿Y qué nuevos procedimientos de incorporación se van a desarrollar?

PD Ser proactivo en lo anterior es una gran manera de aprender y liderar.

¿Dónde se almacenaron los archivos BPMN que no estaban visibles cuando buscaba otros consumidores de API?

Parece que el problema era que no sabías o no tenías acceso a todos los consumidores de la API.

Si no forman parte de su conjunto de trabajo de desarrollo estándar y, por alguna razón, no se pueden agregar a él, cualquier API que se consuma en ese momento debe documentarse como tal en los comentarios de encabezado de llamada de método equivalentes. Dependiendo de qué tan formal sea su proceso de revisión, verificar explícitamente que no se vean afectados podría ser un cambio de proceso válido.

El problema de no saber acerca de todo lo que está fuera del código base en el que está trabajando y que debe verificarse debe ser planteado en su próxima reunión/retrospectiva si sus compañeros de trabajo no lo saben. Algo así debería haberse cubierto como parte de su incorporación al proyecto.

Tienes que cambiar tu mentalidad.

No cometiste un "error crítico". Trabajó lo mejor que pudo; estabas abierto a trabajar en un entorno desconocido; fuiste transparente sobre tus conocimientos y todo lo demás, antes y después; trabajaste junto con los otros chicos para solucionar el problema, presumiblemente no hiciste una rabieta en la oficina. Después de la debacle, vienes aquí y tratas de mejorar aún más.

En resumen: me chuparía los dedos por tener más empleados como tú.

Para responder tu pregunta:

1. Usted personalmente no puede evitar tales cosas, en general. El error técnico estaba completamente fuera de tu alcance. Si quisiera estar 100% seguro, se detendría. No puede verificar partes de un sistema de las que no sabe nada.
2. Los sistemas (incluidas las computadoras y los humanos) tampoco se pueden construir para evitar tales cosas, tan pronto como se vuelvan lo suficientemente complejos.
3. Una forma de abordar esto es el enfoque DevOps/Agile de invitar al fracaso y fallar fuerte y rápido. Esto es de lo que se trata todo el CI y especialmente el CD. Se implementa con tanta frecuencia y rapidez que fallará muy a menudo; y cada vez que solucione el motivo particular con la máxima prioridad (utilizando las técnicas habituales: pruebas automáticas y manuales, reversión sin dolor de pequeñas confirmaciones, implementaciones azul-verde con cambio de reversión de chasquido de dedo, etc.). Esto lógicamente da como resultado que todo el proceso sea más robusto muy rápidamente. Lo ideal es que hagas eso desde el día 0. ¿Fácil? No. ¿Se puede mejorar pieza por pieza? Sí.

Independientemente de lo que usted o cualquiera haga para minimizar los errores, los errores ocurrirán .

Hay, por supuesto, "mejores prácticas" técnicas que ayudarán y sí, están todos los tópicos sobre aprender de los propios errores. Pero tienes todo eso, parece. Sin embargo, ¿todavía te sientes lo suficientemente mal por el incidente como para tomarte el tiempo de escribirlo en Workplace.stackexchange.com?

Creo que hay algo tangible que puedes hacer que te ayudará a ti y a los demás a sentirse mejor con todo este asunto.

Lo mejor que puede hacer es tomar nota de la amabilidad y generosidad que se le mostró y expresar algo de gratitud por ello .

En lugar de disculparse aún más profusamente y hacer promesas de "nunca más" que pronto se olvidarán, tómese el tiempo para AGRADECER personalmente a las personas que ayudaron a resolver el problema y a las que le causaron molestias. Si es apropiado lleva una caja de donas (por ejemplo) a la oficina y complementa a tus compañeros de trabajo.

Y luego, la próxima vez que algo suceda y alguien más cometa un error, sé amable con ellos, ayúdalos y devuélvele la amabilidad que te dieron a ti . Eso es. Serás un mejor equipo gracias a cosas como esa.

Haga que sus compromisos sean lo más pequeños posible, y si puede compilar desde el servidor de compilación después de cada impulso. (Si no se compila con frecuencia, ¡es posible que desee compilar antes de su impulso también!)

Esto no te ayudará a no cometer errores, pero los hará mucho menos críticos. Si sabe qué compromiso/grupo de compromisos causó que la compilación se rompiera, es trivial revertirlo mientras trabaja en el problema, y ​​si los compromisos son lo más pequeños posible, entonces es más fácil localizar la fuente del problema.

Si está utilizando git, incluso hay un comando para ayudar con esto: git-bisect , que le permitirá realizar una búsqueda binaria a través de un grupo de confirmaciones para encontrar la que causa el problema.