Que devez-vous laisser pour vos successeurs?

Supposons que vous êtes l'unique développeur à quitter un emploi. Quel type d'information / matériel, en dehors du code lui-même, devez-vous créer et laisser pour votre remplacement?

Une réponse évidente est "tout ce que vous voudriez à un nouvel emploi", c'est sûr, mais cela fait un moment que j'ai commencé un nouvel emploi, et j'oublie quelles étaient les choses les plus importantes dont j'avais besoin à l'époque.

Je pense:

• comptes / mots de passe
• emplacement de l'équipement, des sauvegardes, des CD de logiciels

Quoi d'autre?

• Comptes et mots de passe
• Informations sur le serveur
• Bon code
• Documentation
  • Les diagrammes et explications de la base de données sont incroyables
  • Liste des bizarreries dans le code
• Procédures
• Explication des processus manuels ou du travail occasionnel, non évident
• Liste des programmes qu'ils ont utilisés ou trouvés utiles
• Informations de contact ;)

Une tasse de café forte et une note d'excuses.

Est-ce que je souhaite que je sois parti.

• Documentation. Est-il difficile d'écrire quelques commentaires? Créer des notes, des notes de déploiement, déplacer les notes système. Que faire lorsque vous redémarrez et que tout a disparu.
• Papiers. Ecrivez pourquoi cela se fait de cette façon, donc je n'ai pas à me demander pourquoi vous ne le faites pas autrement. Comment fonctionne le système de sauvegarde, comment le serveur répond-il aux charges, aux tests, aux cas de test, aux cas d'utilisation?
• Remarques. "Lorsque vous utilisez la base de données, ne dites jamais SELECT * FROM clients. Nous ne savons pas pourquoi, mais il vide la base de données" .

Mon adresse e-mail, ou peut-être même mon numéro de téléphone.

D'après mon expérience, il est difficile d'obtenir tous les détails par écrit, donc la meilleure chose est d'être disponible (dans une certaine mesure) si vos successeurs ont besoin de plus d'informations.

Documentation des programmes que vous avez écrits, par exemple leur objectif, l'emplacement des fichiers source pour le développement futur, les mots de passe, etc.

Cela peut être dans le code en tant que commentaire ou à l'extérieur à la vue.

Plus qu'une simple documentation, j'aimerais savoir pourquoi certaines décisions ont été prises quand elles ont été prises. Nous utilisons SWIG actuellement sur un projet et l'un des autres développeurs voulait savoir pourquoi nous n'avions tout simplement pas utilisé Boost :: Python. La réponse simple était que le client ne permettait pas l'utilisation de Boost à l'époque. Maintenant, c'est une autre histoire.

De telles choses les aideront non seulement à comprendre le projet, mais aussi les limites / contraintes / défis que votre mise en œuvre a surmontés. Cela leur donnera un point de départ pour une maintenance future et une augmentation des fonctionnalités.

Une chose que je n'ai vu personne mentionner (bien que j'aie pu l'oublier) est de documenter comment configurer un environnement de développement. Je me rends compte que la plupart du temps, il suffit d'installer quelques éléments, d'obtenir la dernière version, de compiler et vous avez terminé. Cependant, parfois, il y a plus que cela (SharePoint est une situation qui me vient à l'esprit) et documenter quel condensateur de flux doit être configuré de quelle manière sera très utile pour la pauvre âme qui vous suit.

S'il s'agit d'un programme de bureau, comment créer l'intégralité du système à partir de zéro (il peut s'agir de plusieurs programmes distincts), comment créer un package pour la distribution (quelles sont ses dépendances, par exemple les versions de .NET) et comment le déployer sur des serveurs à télécharger le cas échéant, ou à le graver sur un CD ou un DVD.

S'il s'agit d'un programme Web, d'un accès FTP et (le cas échéant) SSH au serveur, et quels outils sont utilisés pour créer et tester localement le code.

S'il s'agit d'un système embarqué, suivez les instructions pour créer l'image binaire, quels outils sont utilisés, comment télécharger et flasher le code dans le produit, comment configurer le système de fichiers sur l'appareil, le cas échéant.

J'ai récemment quitté un emploi dans des circonstances similaires à vous (je n'étais pas le seul développeur, mais nous n'étions vraiment que deux, donc j'avais beaucoup de connaissances que l'autre gars n'avait pas (et vice versa, bien sûr)).

En termes de documentation normale, il est important de documenter une vue d'ensemble de l'ensemble du système. Les composants individuels sont déjà documentés dans le code, mais l'interaction entre les composants et pourquoi cela fait cela ou pourquoi cela doit parler à ce composant sont importants et pas toujours faciles à comprendre simplement en déboguant / en regardant le code.

Puis, pendant environ un mois avant mon départ, chaque fois que je faisais quelque chose que moi seul pouvais faire, j'écrivais exactement ce qui s'était passé, ce que je devais faire et pourquoi. Il s'agissait généralement d'un "il y avait un bogue dans le composant xyz, pour le corriger, je savais regarder dans le fichier abc à cause de X, alors je devais faire ceci, ceci et cela".

Bien sûr, j'ai laissé mon adresse e-mail et mon numéro de téléphone au cas où quelque chose arriverait qu'ils ne pourraient pas comprendre par eux-mêmes. J'ai reçu quelques appels au cours des premières semaines, mais ils ont lentement diminué.

Nous aimerions tous un diagramme de flux de données complet du système avec une liste des exigences fonctionnelles. Il est plus que probable que vous ne l'avez jamais compris lorsque vous avez écrit le système en premier lieu! Comme la plupart des endroits, la meilleure documentation est probablement le code lui-même, donc ce que j'aimerais le plus, c'est un code bien documenté. Lignes et lignes de commentaires dans le code expliquant ce que vous essayez de faire à la fois techniquement et fonctionnellement.

La règle n ° 1 pour la documentation n'est pas ce que qu'elle fait mais pourquoi . Quelle est l'histoire des programmes qui s'exécutent et que font-ils?

Je pense que ce que j'aimerais voir dans les documentations en plus de l'habituel, ce sont les fonctionnalités qui ont été laissées de côté. Comme pourquoi certaines idées étaient PAS mises en œuvre ou une certaine plateforme ou méthode NON utilisée (ce qui était par ailleurs un choix évident).

Cela garantit que le successeur sait toujours quoi ne pas faire ou s'il est plus capable, il peut peut-être trouver une solution et faire fonctionner certaines fonctionnalités.

Ceci est particulièrement applicable aux projets open source. Peut économiser beaucoup de temps et d'énergie cérébrale!