it-swarm-es.com

¿Qué debería dejar para sus sucesores?

Suponga que es un desarrollador único que deja un trabajo. ¿Qué tipo de información/material, fuera del código mismo, debería crear y dejar para su reemplazo?

Una respuesta obvia es "lo que quieras en un nuevo trabajo" seguro, pero ha pasado un tiempo desde que comencé un nuevo trabajo, y olvido cuáles eran las cosas más importantes que necesitaba en ese entonces.

Estoy pensando:

  • cuentas/contraseñas
  • ubicación de equipos, copias de seguridad, CD de software

¿Qué más?

18
Steven Evers
  • Cuentas y contraseñas
  • Información del servidor
  • Buen codigo
  • Documentación
    • Los diagramas y explicaciones de la base de datos son increíbles
    • Lista de rarezas en el código
  • Procedimientos
  • Explicación de procesos manuales o trabajos ocasionales, no obvios
  • Lista de programas que usaron o encontraron útiles
  • Información del contacto ;)
26
Tarka

Una taza de café fuerte y una nota de disculpa.

Es lo que deseo I quedaba.

  • Documentación. ¿Qué tan difícil es escribir algunos comentarios? Cree notas, notas de implementación, moviendo las notas del sistema. Qué hacer cuando reinicia y todo desaparece.
  • Documentos. Escribe por qué se está haciendo de esta manera para que no tenga que preguntarme por qué no lo estás haciendo de otra manera. ¿Cómo funciona el sistema de respaldo, cómo responde el servidor a las cargas, pruebas, casos de prueba, casos de uso?.
  • Notas. "Cuando use la base de datos, nunca diga SELECT * FROM clients. No estamos seguros de por qué, pero descarga la base de datos ".
22
Josh K

Mi dirección de correo electrónico, o quizás incluso mi número de teléfono.

En mi experiencia, es difícil anotar todos los detalles, por lo que lo mejor es estar disponible (hasta cierto punto) si sus sucesores necesitan más información.

8
Vetle

Documentación de los programas que ha escrito, p. Ej. su propósito, ubicación de archivos fuente para desarrollo futuro, contraseñas, etc.

Esto puede estar dentro del código como un comentario o afuera a la vista.

7
Jeremy

Más que documentación, me gustaría saber por qué se tomaron ciertas decisiones cuando se tomaron. Actualmente estamos usando SWIG en un proyecto y uno de los otros desarrolladores quería saber por qué simplemente no usamos Boost :: Python. La respuesta simple fue que el cliente no permitió el uso de Boost en ese momento. Ahora es una historia diferente.

Tales cosas los ayudarán no solo a comprender el proyecto, sino también a las limitaciones/restricciones/desafíos que superó su implementación. Les dará un punto de partida para el mantenimiento futuro y el aumento de funciones.

6
wheaties

Una cosa que no vi mencionar a nadie más (aunque podría haberla pasado por alto) es documentar cómo configurar un entorno de desarrollo. Me doy cuenta de que la mayoría de las veces es solo instalar algunas cosas, obtener la última versión, compilar y listo. Sin embargo, a veces hay más que eso (SharePoint es una situación que me viene a la mente) y documentar qué capacitador de flujo debe configurarse de qué manera será muy útil para el pobre que lo sigue.

4
Ken Henderson

Si se trata de un programa de escritorio, cómo construir todo el sistema desde cero (puede haber varios programas separados), cómo crear un paquete para su distribución (qué dependencias tiene, por ejemplo, versiones de .NET) y cómo implementarlo en los servidores. para descargar si es aplicable, o grabarlo en un CD o DVD.

Si se trata de un programa basado en web, acceso FTP y (si corresponde) SSH al servidor, y qué herramientas se utilizan para crear y probar localmente el código.

Si se trata de un sistema integrado, complete las instrucciones sobre cómo crear la imagen binaria, qué herramientas se utilizan, cómo descargar y actualizar el código en el producto, cómo configurar el sistema de archivos en el dispositivo, si corresponde.

3
tcrosley

Recientemente dejé un trabajo en circunstancias similares a las tuyas (yo no era el único desarrollador, pero en realidad solo éramos dos, así que tenía bastante conocimiento de que el otro chico no ' t tengo (y viceversa, por supuesto)).

En términos de la documentación normal, es importante documentar una descripción general de todo el sistema. Los componentes individuales ya están documentados en el código, pero la interacción entre los componentes y por qué esto hace eso o por qué necesita hablar con ese componente es importante y no siempre es fácil de averiguar con solo depurar/mirar el código.

Luego, durante aproximadamente un mes antes de irme, cada vez que hacía algo que solo yo podía hacer, escribía exactamente lo que sucedió, lo que tenía que hacer y por qué. Por lo general, esto era un caso de "había un error en el componente xyz, para solucionarlo sabía que debía buscar en el archivo abc debido a X, luego tuve que hacer esto, esto y esto".

Por supuesto, dejé mi dirección de correo electrónico y mi número de teléfono en caso de que surgiera algo que no pudieran resolver por sí mismos. Recibí algunas llamadas en las primeras semanas, pero fueron disminuyendo lentamente.

2
Dean Harding

A todos nos gustaría un diagrama de flujo de datos completo del sistema con una lista de requisitos funcionales. ¡Lo más probable es que nunca lo entendiste cuando escribiste el sistema en primer lugar! Como en la mayoría de los lugares, la mejor documentación es probablemente el código en sí, así que lo que más me encantaría es un código bien documentado. Líneas y líneas de comentarios en el código que explican lo que está tratando de hacer tanto técnica como funcionalmente.

1
bigtang

La regla # 1 para la documentación no es qué hace sino por qué. ¿Cuál es la historia de fondo de los programas que se ejecutan y qué hacen?

1
Andy Lester

Creo que lo que me encantaría ver en las documentaciones, además de lo habitual, serían las características que se omitieron. Por ejemplo, por qué ciertas ideas NO implementadas o una determinada plataforma o método NO utilizado ( que por lo demás era una elección obvia).

Esto asegura que el sucesor siempre sepa qué no hacer o si es más capaz, entonces tal vez pueda encontrar una solución y hacer que ciertas características funcionen.

Esto es especialmente aplicable a proyectos de código abierto. ¡Puede ahorrar mucho tiempo y capacidad cerebral!

0
Kasahs