¿Qué haces cuando un desarrollador de software que sabe mucho sobre la base de código se va repentinamente? ¿Cómo se las arreglan los demás?

Depende

Si se tratara de un codificador profesional responsable, le tomará algunas semanas ponerse al día leyendo su documentación y documentos de lógica de diseño interno y documentos de estándares de código.

Si formaban parte de un equipo subcontratado, o eran un gilipollas que diseñó de acuerdo con su propia lógica distorsionada, sin documentación y sin estándares, entonces a menudo es más barato y más seguro desechar todo y comenzar de nuevo

No, no estoy bromeando

Si no documentaron, entonces no hay garantía de que la forma en que USTED interpreta su código sea realmente cómo funciona

Si formaban parte de un equipo subcontratado, entonces esperar que sus compañeros de equipo hayan prestado atención a lo que uno de ellos estaba haciendo es una locura, así que desecha todo y llévalo de vuelta a la costa con un diseño adecuado y un código estándar.

Lo he visto seis veces en mi carrera. Cada vez que la gerencia tomó la decisión equivocada y trató de continuar, antes de llamarme. Cada vez que terminé desechando y reconstruyendo todo el proyecto de manera más rápida y confiable que el método de “continuar”

He estado en condiciones de heredar una base de código de otros desarrolladores comerciales.

El mejor que encontré no tenía documentación. Ningún intento de ocultar código sin licencia en archivos de firmware. Una licencia mega costosa para una pieza de software inaudita solo para crear gráficos. Ningún intento de actualizar el código a la versión moderna de Visual Studio. Prácticas de codificación extrañas como una clase de 200 líneas con llamadas .dll para buscar una carpeta, en lugar de usar FolderBrowserDialog. Reglas de herencia rotas en todas partes. Grandes cosas pasaron ByVal en algunos lugares y ByRef en otros. Clases que modifican cosas en la clase que llama a través de tipos pasados ​​(¡AAAARGH!) Variables globales.

Me llevó 8 o 9 meses llegar al punto de poder agregar la funcionalidad requerida. Gran parte de ese tiempo fue simplemente desentrañar la extrañeza y luego introducir el código en Visual Studio 2010. 7 años después, y los problemas de firmware / software todavía nos están llevando a la distracción.

Hay varias cosas que puede hacer como parte de la entrega del empleado que se va al resto del equipo:

• el empleado escribe documentación para los usos comerciales, el diseño y los componentes principales del sistema

• el empleado escribe un manual, también llamado “runbook”, que puede usarse para solucionar problemas que ocurrieron en el pasado

• el empleado organiza reuniones para presentar documentación y codificar partes a otros miembros

• desde el período en que el empleado da aviso hasta que se va, solo los otros empleados escriben nuevas funciones y él / ella lleva a cabo las revisiones

Sin embargo, lo que es más importante es lo que haces para evitar todo este alboroto y esto se llama propiedad compartida. Esto se puede lograr compartiendo eficientemente el trabajo en varios sistemas entre todos los miembros y también asegurándose de que todos los desarrolladores se esfuercen por obtener la mejor calidad de código. Idealmente, el código limpio debería ser legible por los programadores que tienen poco conocimiento del sistema y deberían ser fácilmente comprensibles. Para hacerlo, el código debe hablar el idioma del dominio del problema y no el de la solución (en otras palabras, tener el nivel correcto de abstracción).

Un grupo de desarrollo de software bien gestionado asume que cualquier miembro del equipo podría renunciar, enfermarse o morir repentinamente en cualquier momento. Aplican las mejores prácticas que incluyen el control de versiones con mensajes de registro informativos, revisiones de código para todos los cambios, comentarios que explican la motivación para cualquier cosa extraña, documentos de diseño, pruebas extensas, revisiones de diseño y presentaciones ocasionales por parte de los miembros del equipo senior. Cualquier programa, API o servicio visible fuera del equipo también requiere una guía del usuario. Todos los servicios administrados por el equipo necesitan un runbook y un panel de métricas.

Si su grupo no tiene esas cosas, es solo cuestión de tiempo antes de encontrarse con revisiones de diseño retrospectivas, espeleología en los archivos de registro y escribir documentación que debería haber estado allí en primer lugar, para tomar la decisión. si continuar en esa dirección o desechar todo el desorden incomprensible y hacerlo de nuevo correctamente. Si lo desecha, probablemente sea una buena idea despedir también al gerente del empleado desaparecido.

Esperas que su trabajo esté bien documentado, y que el de ellos haya sido una salida amistosa, completa con una transferencia de conocimiento seria. También se prepara para pagarles algunas tarifas de consultoría de seguimiento, para ayudar cuando las cosas se rompan.

Si se fueron en términos menos que amigables, esperas que alguien en el equipo siga siendo amigable, para que el desarrollador anterior sea receptivo a los pedidos de ayuda.

Bueno, de acuerdo con la ley laboral egipcia (Portal de servicios gubernamentales de Egipto):

1. Si tendrá su primer trabajo (con contrato), debe traer un documento de la oficina de trabajo en el gobierno, es una prueba simple de que este es el primer trabajo, en caso de que haya obtenido este documento antes, puede ‘ No consiga otro nunca.
2. Para obtener un trabajo con contrato, debe traer algunos documentos, uno de ellos es una prueba de que este es su primer trabajo, o un documento de la compañía para la que trabajó directamente antes de que este diga que terminó de trabajar allí, y esto el documento caduca una vez que lo usó una vez.
3. Debe poner su firma (tanto digital como manuscrita) para el contrato de trabajo, ese contrato contiene las reglas que debe seguir, una de ellas es “todo su código y participación en la empresa pertenecen a la empresa, y usted no tiene el derecho de reutilizarlos fuera de la compañía para cualquier otro destino, incluso si no puede usarlos / acceder a ellos después de dejar el trabajo, y la compañía tiene el derecho de demandarlo por infringir cualquiera de estas reglas ”

Entonces, si alguien dejó la compañía repentinamente, no podrá obtener otro trabajo con contrato, y la compañía tiene el derecho de demandarlo especialmente si usó el código base o si escribió algo al respecto (como funciona) más o menos), y generalmente lo demandan sin esperar a que haga esto, porque la ley está de su lado aquí.

¿Cómo hará frente la empresa a esto?

bueno, le piden a otros empleados que trabajen con el tiempo por más dinero y esto es legal aquí, contratan a más personas si es necesario, o simplemente seleccionan los currículums en su base de datos y comienzan un proceso de entrevista.

Un problema que puede suceder es cuando este tipo que se fue es un tipo sólido con mucho trabajo realizado (especialmente solo) en la compañía, en ese momento la compañía apesta, un ejemplo de esto es la compañía Topcoder, por lo que escuché / leí, los empleados que crearon el Topcoder Arena dejaron la empresa, por lo que Topcoder apesta hoy en día y el campo tiene muchos problemas, pero no pueden (no) resolverlo hasta ahora; decidieron comenzar una nueva era de plataformas, que es crear cosas basadas en sitios web en lugar de la aplicación de escritorio.

Espero que esto pueda ayudar.

Con suerte, tendrás otros programadores que conocen la base de código.

Sin embargo, a veces no, he sido ese programador, donde la base de código fue escrita por otro equipo, y ese equipo dejó de existir.

Lleva tiempo entenderlo, pero eventualmente lo hará.

Si está escrito bastante bien, es decir, con encapsulación, etc., es posible que no necesite comprender todo, solo el bit en el que está trabajando.

depende mucho de por qué la persona se fue. Si fue en buenos términos y fue para un mejor trabajo por más dinero, o para un puesto que simplemente no estaba disponible para él o ella a su ritmo. Entonces podrías estar bien. Y podría estar dispuesto a ayudar en la transición.

O su equipo o toda su organización es disfuncional y él está saliendo antes de que todo implosione. Si este es el caso, es probable que sepa que esto también es cierto en su corazón.

O está al tanto de alguna información que usted no tiene. Una próxima adquisición, un despido importante, o la empresa tiene problemas financieros, o que las acusaciones están bajando (el escenario de Enron).

Si la disfunción actual o el riesgo de una disfunción próxima vaya a Amazon y obtenga una copia de DeathMarch por Yourdon. Léelo y prepárate para aplicar esos principios. Si está exento, puede estar haciendo mucho trabajo de forma gratuita. Si es por hora, sus ingresos pueden aumentar considerablemente.

Fui testigo de tal experiencia. Era un desarrollador único con mucho código bajo su administración, una persona bastante reservada y la documentación era posterior. Enfoque típico de “seguridad laboral”. No hay muchos comentarios en el código. Él ya estaba trabajando durante mucho, mucho tiempo. Y murió de repente. La compañía acaba de contratar inmediatamente a los mejores talentos por un salario bastante alto e hizo un grupo de desarrolladores bajo este nuevo talento contratado. Más externalización parcial. Y la calidad del código se ha mejorado considerablemente. Ese es un enfoque estadounidense típico para resolver tales problemas

Obtenga un desarrollador muy competente en la tecnología utilizada por la aplicación en la misma sala con un usuario y alguien experto en el lado comercial, que mapee el proceso e investigue el código correspondiente, repita tanto como sea necesario.

Cuando esto sucede, es un mal olor muy fuerte de una sola cosa, la mala gestión . El patrocinador debe intervenir y eliminar al gerente.

Esto es muy típico de todas las empresas. Básicamente, debería haber un período de “transferencia” que puede variar de varias semanas a meses, dependiendo de la brecha de entendimiento entre la persona que se va y el resto del equipo) durante el cual los otros miembros comienzan a acumular lentamente conocimiento sobre dicha base de código y se sumergen profundizar en su funcionalidad para llegar a ser lo suficientemente competente y poder hacerse cargo y continuar trabajando en ello.

Lo primero que debe hacer es mover todos los plazos asociados con ese software unos pocos meses.

Después de eso, es realmente lo de siempre. El código es código, y las personas que todavía están allí solo necesitan comenzar a aprender más sobre la base de código.

Con suerte, el desarrollador no quema puentes, y todavía está disponible para un correo electrónico aleatorio o una llamada telefónica si es necesario. Sin embargo, la mayoría de las veces, depende del equipo entrar en el código y resolverlo por sí mismos. Si su gerente está haciendo su trabajo, habría tenido una segunda persona al menos parcialmente familiarizada con el código. Después de todo, nunca se sabe cuándo alguien se va de vacaciones, se enferma o muere (esperemos que no), o simplemente se harta y abandone la empresa. Si su tienda queda en una mala situación solo porque una persona ya no está allí, tiene mayores problemas que las consecuencias a corto plazo de perder a esa persona.

Aprende sobre el trabajo en equipo.

Si no puede permitirse al menos tres desarrolladores, cada uno capaz de lidiar con el código solo en un apuro, es irresponsable ofrecer el producto. Debe planear uno de vacaciones, uno en el hospital y otro en el trabajo.

¿Qué hacer ahora?

Contrata a tres personas buenas y trata el código como código heredado. ¿Cómo? De esa manera.

A menos que el código esté escrito en Perl, es solo una cuestión de velocidad. Lo que significa que entregaré las características un poco más lento y diré que las historias son un poco más caras para algunos sprints. Entonces mi velocidad aumentará y eventualmente volverá a la normalidad. No debería ser tan importante. Creo que mi tiempo para volver a la normalidad podría ser un poco más corto que el promedio. No porque sea un copo de nieve especial. Acabo de trabajar accidentalmente en esta habilidad un poco más que un ingeniero promedio que no hizo tanto trabajo por contrato. No solía estar tan cómodo con eso. Algunos ingenieros son más sensibles, pero creo que estarán bien después de un poco de exposición. La única tormenta perfecta sería si la gerencia permitiera que un equipo se hiperespecializara con ingenieros que tienen muy poca experiencia para trabajar con código desconocido.

”

En mi caso, fui yo quien se fue (involuntariamente), y fui el único en la compañía que conocía el idioma lo suficientemente bien como para mantener el código.

Según las historias que me contaron mis ex compañeros de trabajo, la gerencia quería un cambio en el sistema y rápidamente se enteró de que me habían dejado ir. Se dirigieron a alguien que conocía otro idioma, pero no pudo entender lo que escribí (no porque fuera complicado, sino porque no estaba familiarizado con la sintaxis del idioma). En pocas palabras, tomó los aspectos de lo que había escrito y escribió otro sistema en su lugar con los cambios solicitados.

Lo que he notado … Me lo asignan. Ha sucedido todo el tiempo. Me meto en un nuevo proyecto y dicen “bueno, el tipo se fue sin previo aviso y nadie sabe lo que hizo su código … etiqueta, ya está”.

Con suerte hay algo de documentación, o al menos código comentado. Pero lo normal es leer el código línea por línea e intenta entender lo que hace. Eventualmente te conviertes en el experto de esa parte … y nunca se documenta.

Eso es lo que he visto hacer a los equipos para “hacer frente”.