documentation - Hacerse cargo de un proyecto: ¿qué debería preguntarle al programador anterior?

project (21)

"Si pudieras volver y desarrollar este sistema, ¿qué harías diferente?"

Estoy asumiendo el desarrollo de un sitio web comercial. Este sitio fue desarrollado durante dos años por otro programador. Es principalmente un trabajo de un solo hombre (mantener y expandir el sitio). Tendré un período de transición de 2-3 días cuando el otro programador me mostrará el sistema. Pero por lo que sé, hay poca documentación. Todo está en el código (que está algo documentado). Esto es lo que planeo preguntar hasta ahora:

Explicación sobre los elementos más complejos del sistema
Descripción de la arquitectura general
Descripción de las herramientas de soporte (configuración IDE, pruebas unitarias, mecanismo de despliegue)
Cualquier libro, sitio web, podcast que utilizó para influir en la arquitectura del sistema

¿Algún otro me estoy perdiendo?

[EDITAR] Gracias a todos. Perdido de buenas proposiciones. ¡Ojalá pudiera aceptar más de una respuesta! Además, también agregaría:

¿Qué has hecho específicamente para mejorar el rendimiento del sistema y dónde está el cuello de botella ahora mismo?
Relacionado con eso, ¿qué has hecho con respecto a la seguridad del sistema? (¿Qué has hecho y dónde están los agujeros de seguridad ahora mismo?)

Una última cosa: el desarrollador dijo que estará disponible para responder mis preguntas más adelante si lo necesito. Es su "bebé" después de todo. ¡Pero realmente creo que en 6 meses habrá avanzado y su disponibilidad será mucho más reducida!

¿Cuál es el "trabajo manual" periódico que el sistema requiere?

Ya sabes, esos pequeños trabajos que surgen de vez en cuando y que aún no han sido automatizados. ¿Cómo lo arreglas y cómo lo reconoces?

¿Cuáles fueron los principales problemas con los que se encontró el sitio y cómo se resolvieron? Es demasiado fácil tratar de arreglar algo que no tiene sentido en absoluto, solo para descubrir que lo que parece absurdo es en realidad la única solución para algún error sutil pero desagradable.

Revisando el código y mirando todo lo que parece difícil de entender y simplemente preguntando "¿qué hace esto, por qué lo agregaste?"

Asegúrese de anotar sus respuestas , quizás incluso coméntelas en el código para que estén allí cuando las necesite. No hay nada más molesto que esa sensación de " Sé que me dijeron acerca de esto ..."

Además de las cosas techy (eso es "fácil" de entender :)) ¡averigüe sobre las reglas comerciales! Rara vez se documentan adecuadamente (en mi experiencia) y, por lo general, uno se da cuenta por el mal camino cuando algo sale mal.

Antes de mirar el código:

Borre los objs y los exes, y permita que él / ella reconstruya la cosa. Esté atento a cualquier interacción manual (¿se desarrolla a través de "hacer" solo o hay algún toque de viñeta involucrado).

Mejor aún: déle una máquina desnuda (recién comprada), déjelo demostrar un pago y reconstruir. Luego, vea cómo se inicia y aparece la aplicación (¿alguna opción secreta para ingresar?).

Luego: en una sesión de programación de un par, agregue una o dos características al sistema y vea dónde y cómo se implementan.

Lo anterior puede sonar estúpido, pero he visto proyectos en los que construir solos era una pesadilla, y el cerebro del desarrollador solo tenía muchos conocimientos. No tener un entorno de construcción confiable y tener que descubrir cómo reconstruir es una pesadilla.

Asegúrate de poder CONSTRUIRLO Y LIBERARLO.

Demasiadas veces hay problemas con la falta de información.

Debes SABER TODAS las cosas auxiliares.

Obtenga una máquina nueva y asegúrese de poder duplicar una compilación y una versión.

EDITAR: después de eso sería: "¿Cuáles son todas las cosas que has estado tratando de corregir pero no has logrado y no están documentadas en ningún lado"?

Asegúrese de obtener todos los "errores" para la aplicación. A menudo son los datos o elementos de negocios que son demasiado pequeños o extravagantes para tener documentación formal, pero terminan teniendo grandes impactos o mucho tiempo de depuración si no sabes lo que está pasando.

Por ejemplo, en una de las aplicaciones que mantengo actualmente, nos conectamos con un sistema de terceros que tiene un cliente tipo "web viewer". El "error" con esto es que el visor web no mantiene adecuadamente el estado de sesión del usuario (roto cuando se actualizó a su última versión para solucionar otros problemas críticos). Como resultado, tengo que recordarles a los usuarios de vez en cuando que simplemente minimicen la ventana del navegador para que el tiempo de espera se agote de forma natural, de lo contrario quedarán bloqueados durante un período prolongado hasta que la gente de Ops instale la versión más nueva. .

Asegúrese de solicitar toda la información de inicio de sesión para los servidores web, registradores de dominio, servidores de bases de datos, servidores de correo electrónico y cualquier otra cosa que se le ocurra . Suena loco, pero a menudo los desarrolladores registran nombres de dominio consigo mismos como contactos administrativos y técnicos. La compañía tendrá que pasar por todo tipo de aros con el registrador para recuperar el dominio, si el programador original no puede ser contactado.

De 2 a 3 días suena corto para el traspaso, así que no temas pedir más.

Primero, obtenga un entorno local en funcionamiento con control de fuente, ide, compilación y pasos de liberación, todo en ejecución local.

Luego intente obtener una impresión de la calidad del código revisándolo brevemente. Si se ve mal, es posible que no obtenga tanta información útil sobre la implementación de su predecesor.

Sin embargo, todo lo que se refiere a implementaciones, servidores de bases de datos, estrategia de respaldo, registros, etc. debe ser verificado. También todas las licencias para bibliotecas, etc. y también una lista de los errores más comunes (si tienen una herramienta de seguimiento de errores, esto puede ser útil)

También necesita ver qué tan útil fue su predecesor, ya que he visto varios estilos de handover en los que la persona que entrega el handover era amistosa pero engañosa y daba respuestas sarcásticas a las preguntas que se le hacían en forma de cuestionario ( que aunque divertido no era profesional) simplemente desinteresado.

La primera pregunta que suelo hacer cuando me encargo de un proyecto es cómo sacarlo del control de la fuente (básicamente, "¿Dónde está?"). Aparte de eso, creo que has alcanzado todos los puntos altos.

Configuración IDE, pruebas unitarias, mecanismo de despliegue

son probablemente las cosas más importantes que puede preguntar.

Al preguntar qué sitios web influyeron en el que está tomando el control, asegúrese de obtener una lista de enlaces. Descubrí que muchos desarrolladores mantienen marcadores en los sitios de los que han tomado muestras. Asegúrate de obtenerlos.

No preguntes Ciérrelo en una habitación: indíquele que no recibirá comida ni agua hasta que comience desde el principio y le cuente todo lo que sabe sobre el sistema. Luego haga preguntas relevantes a medida que surjan. Después de esto, pasa un par de días mirando el código. Luego repite el proceso. Haga esto hasta que se sienta cómodo con el sistema.

Pregunte acerca de cualquier obstáculo o solución temporal que encontró el desarrollador original.

Conozca a sus clientes también. ¿Son quisquillosos? ¿Qué esperan?

Pregunte cuáles son los requisitos reales . La mayoría de los proyectos no tienen requisitos escritos o requisitos escritos desactualizados. La documentación real suele ser conversaciones verbales. Averigua con quién hablar. Si tiene requisitos conflictivos de diferentes usuarios, descubra quién es más importante para hacer feliz.

Pregunte: a) ¿qué no quieren que les pregunte sobre este sistema? b) ¿Qué le hará más feliz cuando ya no trabaje en este proyecto? c) ¿Cuáles son las partes del sistema que son demasiado complejas para ser documentadas?

Revise cuidadosamente la aplicación y trate de resolverlo primero. Luego ve a tu reunión con preguntas y, lo más importante, con el contexto .

Su teléfono.

Ver el código durante 5 minutos es el mejor comienzo, si el código está realmente bien organizado y comentado, puede que no haya ningún motivo para hablar con él.

Si el código es horrible, así que no esperes ninguna razón inteligente por la que haya pirateado algo, en el mejor de los casos puedes usarlo como referencia para un código cruddy y te pregunta cuál es el propósito.

De cualquier manera, hablar con el desarrollador anterior es lo menos útil que hacer, porque de cualquier manera, estás atrapado con eso ahora.

Conocido ¹ problemas
Conocido ¹ áreas de mejora
Los datos de cobertura de código existentes, tasa de aprobación de prueba, etc. se utilizarán como referencia
Sugerencias para la solución de problemas (comprensión de archivos de registro, fallas de depuración, errores comunes)
Explicación de los parámetros de configuración

¹ Conocido solo por él o ella

Cómo instalarías el sitio en un nuevo servidor.
Qué hace el sitio y para qué se utiliza
Qué bases de datos se usan y dónde están.

¿Has estado trabajando en la misma compañía?
Si no, y esto no está directamente relacionado con el proyecto, pero le preguntaría por qué se va. Puede darle una idea de la política involucrada o si algo le molesta trabajando con ella o con el cliente.

¿Quiénes son sus usuarios expertos? ¿De quién debo buscar o confiar?

¿Quiénes son sus usuarios peligrosos no expertos? ¿A quién debo escuchar y luego ignorar activamente?