¿Qué tan difícil es para un programador hacerse cargo del mantenimiento y desarrollo de una aplicación que originalmente fue codificada por otra persona?

Tengo mucha experiencia trabajando en cosas como esta temporalmente. A veces es bastante desagradable. A veces, bueno, miras el código y te ríes mientras lo arreglas 🙂

Aquí está mi respuesta:

1. Depende de la complejidad de la aplicación.
2. Será más fácil si alguien trabajó en él todavía está en el equipo
3. El idioma, a menos que no esté familiarizado con él, no debe ser una barrera para que pueda comenzar a trabajar.
4. La codificación, me refiero al diseño, los detalles de implementación, los comentarios y, sí, la documentación, si los hubiera, podrían hacer que su toma de control sea fácil o difícil.
5. Y hay trampas (¡trucos para que funcione!)
6. La pesadilla es que esta cosa no tiene ninguna prueba automatizada. Y lo peor es que no hay un documento que describa cómo se probó (el manual, aunque no se recomienda, es mejor que nada)
7. Quizás haya errores ocultos, errores, números mágicos y otras cosas que simplemente “suceden” para que la aplicación funcione. Puede ser difícil de profundizar.
8. Eso es todo sobre el programa en sí. Los propietarios de la aplicación también pueden tener expectativas poco realistas si desafortunadamente no saben mucho sobre programación o si realmente no han investigado el código. Trate de establecer expectativas bajas y golpee el suelo y corra.

Puede ser muy difícil si el programa es complejo, pero aprenderá mucho más con el mantenimiento del código como nuevo programador que escribir un código nuevo. Mantener el código de otra persona es, por naturaleza, una experiencia lista para usar y no es algo que se enseña en la escuela. También puede aprender sobre el negocio y ver “un” enfoque para resolver los problemas con el código. Esto le dará una perspectiva informada sobre el problema en lugar de solo una opinión y eso aumentará su valor para la empresa.

Sé que las analogías médicas son populares aquí, así que considera el mantenimiento del código en tu residencia de MD. Simplemente no pases tu vida como residente. Aprenda y sepa cuándo es el momento de seguir adelante.

Eso depende en gran medida de dos cosas. El primero es el lenguaje utilizado.
El segundo es el estilo del programador original.

Tuve una experiencia en la que me llamaron para rescatar a una compañía que había contratado a un programador para escribir toda su programación comercial principal, como control de inventario, facturación, etc. El programador se imaginó a sí mismo como un genio. El no estaba. Rompió todas las reglas del libro y su estilo era hacer todo lo más complejo posible para poder cobrar más y dependerían de él durante años. Me llevó dos años arreglar su desastre con muchas reescrituras, reorganizaciones masivas, pruebas y documentación. Odiaba cada minuto, a pesar de la paga. Pensé que si conocía a ese programador anterior, lo envolvería en su código sin sentido y lo tiraría al río.

Por otro lado, tenía un nuevo cliente cuyo jefe de programadores murió repentinamente. Si creyera que había un cielo, diría que fue a él. Un novato podría haber recogido sus libros, sentarse en una computadora y en un par de días dominar lo que estaba escrito. Arte puro y algunas de las programaciones más bonitas que he visto.

Entonces, en mi experiencia, puede ir de un extremo a otro.
Es por eso que en mi tienda tenemos estándares para programación, documentación y revisión por pares, además de las pruebas funcionales estándar.

¡Es más dependiente del programador en cuestión que nada!

¡Si el programador más viejo siguió los estándares de programación, entonces todo lo que se necesita es un poco de esfuerzo y concentración para dominar el código! ¡Si no …… bueno, se necesita una gran cantidad de esfuerzo y concentración para hacerlo! ¡Si la cosa está realmente complicada pero funciona, solo quédate con lo que debes hacer y no interfieras en ningún otro lugar! 😀

Varía muy ampliamente. Un código parece que alguien compró “Este idioma para tontos, aprende en 36 horas”. Un montón de códigos de espagueti y duplicados y nombres de variables sin sentido. Otro código fue escrito con simplicidad y facilidad de mantenimiento en mente y puede ser muy fácil de asumir. Lamento decir que es aproximadamente el 80% del primero y el 20% del último.

Si se ordenó al desarrollador anterior, documentó su trabajo, se probó de manera formal y automatizada, se codificó cuidadosamente, se tomó en serio los estándares, entonces su trabajo no puede ser tan fácil.
Cada uno de los factores mencionados anteriormente aumenta la dificultad en un 10-30% cuando se omite.
El escenario es tuyo.

Depende de qué tan claro sea el código, nombres de variables decentes, flujo claro del programa y qué tan bien se escriben las documentaciones (si está allí)

Puede ser fácil o difícil, los buenos desarrolladores trabajan para hacerlo más fácil sabiendo que dentro de seis meses cuando miren el código, la documentación es increíble

Bastante difícil. Cada uno tiene un estilo diferente, y acostumbrarse a eso no es tarea fácil.

Trabajé en una tarea que incluía editar un motor de chat existente para reutilizarlo en otro lugar. El motor de chat estaba demasiado unido a la lógica de negocios que tuve que reescribir gran parte del código.

Además, como han dicho otros, la documentación es muy útil.