¿Qué tan difícil es para un segundo desarrollador de aplicaciones venir nuevo y trabajar en la codificación de una aplicación que está a medio camino? ¿Qué se debe considerar para hacer esto?

Aquí está la gama:

El trabajo del segundo desarrollador es …

… más fácil si …
Conocen los marcos y los idiomas utilizados por el primero. Tienen todos los recursos reunidos por el primero [es decir. esta no es una situación de “el tipo me dejó con código pero sin arte”]. Se les da tiempo para analizar el código existente y proporcionarle comentarios sobre su suposición de “a mitad de camino” [lo que probablemente sea muy incorrecto]. Se les da tiempo para reorganizar cualquier cosa en el código existente que deberá reorganizarse antes de que puedan iniciar el sprint desde su marca imaginaria “a medio camino” hasta la línea de meta.

… más difícil si …
No conocen los marcos o los idiomas utilizados por el primero. No tienen todos los recursos reunidos por el primero … ya ves a dónde va esto, ¿verdad?

Las empresas a veces tienen esta noción especialmente en ingeniería de que los ingenieros son reemplazables de forma / ajuste / función. Ese no es el caso. Joe no podía venir a sentarse en mi asiento e inmediatamente retomar donde lo dejé, saber todo lo que necesita saber, saber dónde pongo todo lo que necesitará, saber qué suposiciones había hecho, saber qué herramientas de banda lateral estoy usar para automatizar el trabajo, etc. Tendrá que dar al Sr. 2do desarrollador de aplicaciones tiempo adicional para que se ponga en marcha y sea efectivo. Pero esperaría que el Sr. Segundo desarrollador de aplicaciones se acercara a ti y te dijera algo como “amigo … el primer tipo te estaba engañando … ¡ni mucho menos!”

sobre cuán difícil, esto varía según la complejidad de la aplicación y la calidad del código en sí mismo, de todos modos, al menos creo que (nunca trabajo como programador) recibirás alguna orientación, como documentaciones, etc., por lo que esto podría simplificar poco.

Lo que debe considerarse es primero el proyecto en sí, luego si el equipo tuvo algún problema con el desarrollador anterior, ya que esto podría tener alguna relación con el software en sí, entonces verifica los posibles errores y valora su relevancia para el software, si es posible, mira La rutina de desarrollo, las dependencias internas y recomiendo comenzar desde el punto más fácil, especialmente si dicho punto tiene dependencias menos correlacionadas. De todos modos, si está en una etapa desarrollada, de lo contrario, lo que se hace, se hace, dé preferencia a la continuación del desarrollo y no a lo que se desarrolló y luego, si tiene condiciones, mire el desarrollo anterior con mayor precisión e intente como puede aislar su desarrollo para asegurarse de que cualquier problema que tenga se base en sus propios errores y no en problemas anteriores. También guarde una copia del software antes de comenzar a desarrollar, que lo ayudará a recordar lo que había desarrollado y lo que se desarrolló antes, lo que puede ser útil en casos de errores para determinar si los problemas estaban en su desarrollo o en el correlacionado dependencias e intente ponerse en contacto con el desarrollador anterior si tiene algún problema, pero no piense que fue sobre su propio desarrollo, eso puede ahorrarle mucho tiempo. Una cosa que debe tener en cuenta es que los errores no necesariamente aparecen de inmediato, algunos solo aparecen cuando algunas funciones ofrecen respuestas inesperadas que solo aparecerán en etapas más avanzadas, también es bueno hacer algunas suposiciones (si cree que no sean muchos y tómese su tiempo) sobre los errores que podría tener en adelante con los problemas basados ​​en el desarrollo anterior (tal vez podrían existir algunos programas para aprovechar esta cuestión de expectativas) Si hay pocas cosas desarrolladas, puede invertir el orden y comenzar buscando el desarrollo anterior.

Observe también las descripciones que los desarrolladores ponen junto al software, que pueden ser muy útiles y los proyectos en sí mismos podrían tener sus propios históricos de desarrollo.

En mi experiencia, trabajar en un código de propietario diferente es como tratar de usar los zapatos de otra persona. Aunque muchas veces, el código es mucho más grande que es prácticamente imposible reescribirlo todo.

Sugiero tratar de entender realmente el problema e intentar reutilizar todo el código reutilizable, pero intente hacer el trabajo con su propia lógica.

Todo depende de en qué estado se encuentre el código y qué tipo de marco se haya utilizado. Si puede ver lo que está sucediendo, entonces no debería ser demasiado difícil continuar. Si no puedes saber qué está pasando, solo terminarás haciendo un desastre.

Cuando el desarrollador comienza a codificar, claramente necesita saber dónde afectará todo este código. Por lo tanto, el segundo desarrollador de la aplicación necesita una transferencia de conocimiento adecuada del primer desarrollador.