Embauché en tant que développeur de maintenir et de mettre à jour actuelle de la base de code, pas de docs!

Question

C'est mon premier emploi après avoir obtenu son diplôme:

J'ai été embauché avec littéralement un jour chevauchement des dernières développeur du dernier jour et mon premier jour. J'ai été très très rapide aperçu des fonctions de base et les utilisations qui, apparemment, nous sommes une entreprise a besoin de beaucoup de changements pour chaque client...

Voici mon problème: Le code n'a pas de commentaires. Le code n'a pas de développeur de documents de toute sorte. Où dois-je commencer? Je pensais à la création d'un développeur wiki que j'ai appris ce système, mais je suis très débordé dès maintenant. Je suis à la recherche des milliers et des milliers de lignes de code, et personne pour les aider. Suggestions de toute personne qui a été dans cette situation serait très apprécié!

Answer 1

Si personne d'autre n'est familier avec le code à tous, alors vous devriez bébé étape de votre chemin à travers le code.

1. Choisir un simple changement de la liste.
2. Trouver le point d'entrée principal.
3. Commencer à creuser jusqu'à trouver l'endroit où le changement est dû.
4. Document le code dans un wiki et d'ajouter des commentaires dans le code que vous creusez.
5. Toute modification doit ÊTRE RÉVERSIBLE, afin de ne pas casser ce qui fonctionne (n'oubliez pas d'utiliser le contrôle de version).
6. Ajouter des tests unitaires pour le code pendant que vous creusez.

Bonne chance!

Il y a un livre systématiquement recommandée ici pour ce genre de scénario: Travailler Efficacement avec le Code existant

Voici un simple PDF à partir du même auteur.

Answer 2

Attention les notes que vous allez vous seront utiles, comme le fait d'utiliser quelque chose comme Doxygen pour obtenir un haut niveau de l'image de la façon dont les parties du système sont liées. Cependant, cela ne fera que vous obtenez jusqu'à présent. Ce que vous avez besoin de plus, c'est de savoir "pourquoi", vous pouvez découvrir ce que vous allez.

Pour cela, vous devez entrer en contact avec la précédente développeurs, parfois, si vous pouvez demander raisonnablement rapide des questions vous pouvez trouver quelqu'un pour vous aider. Vous pouvez aussi proposer à votre patron que vous essayez de ré-embaucher l'une des développeurs sur un contrat de courte durée strictement à des fins de formation.

Answer 3

L'ajout de la montagne de bons conseils, il y a un autre excellent livre sur ce sujet (même si c'est principalement concentré sur le C et l'Assembleur) appelé Logiciel Exorcisme: Un Manuel pour le Débogage et l'Optimisation du Code existant.

Mes techniques -- et je suis en train de faire une telle bête dès maintenant à partir de l'un de mes clients, sont semblables à beaucoup d'autres réponses que vous allez voir ici:

1. La tâche immédiate: Déterminer (le cas échéant) de bibliothèques tierces sont utilisés dans le projet. Cette étape est cruciale, car la connaissance de qui des assemblées.NET), les emballages ou d'autres bibliothèques dans le projet sont en dehors de votre contrôle permet de réduire le "travail" de code, vous devez vous frayer un chemin dans. (Notez que vous avez encore à trouver de la documentation ou des échantillons pour a dit de la 3e partie des bibliothèques.) (Note n ° 2: C'était l'une des leçons les plus difficiles que j'avais à apprendre.)
2. Ne quiconque est familier avec le projet existe toujours dans l'entreprise? Bien, ils sont vos nouveaux meilleurs amis. Horaire du temps face à face avec eux qu'il est humainement possible. Acheter du café, des beignes et des bagels. Vous voulez savoir ce que cette bête était censé faire. (Vous n'avez pas de soins, mais, ce qu'il fait . Vous, mais pour l'instant découvrez ce que l'entreprise avait besoin de cette application pour le faire, et puis regarder tout le code de ce point de vue.) Prendre des notes. Des tas et des tas de notes.
3. Commencer petit. Comprendre un seul module ou débit. Comprendre ses dépendances immédiates. Puis commencer à se diversifie dans les dépendances les dépendances et ainsi de suite.
4. Ne pas commencer à changer les choses encore. Obtenez de l'un à mi-chemin décent sur la poignée de la structure et les normes du projet. Et oui, l'absence de structure et des normes est (malheureusement) elle-même une norme. Mon vieil adage qui dit "il vaut parfois mieux être cohérent que correcte" peut s'appliquer, mais votre kilométrage qui peuvent varier. (En tant que consultant, j'hérite de beaucoup de code, code qui peut ou peut ne pas être conservée en permanence par moi. Je serais normalement plutôt correspondre à ce qui est là, donc le gars à côté est plus facile de temps.)
5. Commencer à développer votre propre documentation. Il n'a pas à être formel, il peut même être "notes". Si vous utilisez Office 2007, OneNote est très pratique pour cela, mais régulière d'un document de traitement de texte peut fonctionner tout aussi bien. Simplement capturer ce que vous apprendrez sur le code.
6. Le projet de tests unitaires? Bien sûr que non -- je n'ai jamais une fois hérité d'un projet qui fait. Donc, sonne comme un bon moyen d'obtenir vos pieds humides avec le code, n'est-ce pas? Pourquoi nous écrivons ces maintenant? Parce que les tests unitaires sont une excellente façon de documenter ce code, et plus important encore, ce qu'il est prévu de le faire. Vous ne pouvez pas savoir ce que l'intention du développeur précédent a été, mais vous savez ce que votre intention est. Pour le meilleur ou pour le pire, le code est maintenant le vôtre, assurez-vous de savoir ce qu'il fait. Vous n'avez pas besoin d'écrire des tests pour l'ensemble de l'application tout à la fois, mais assurez-vous de faire assez que vous êtes prêt pour ...
7. Le temps de changement! Comme les autres ont dit, commencer petit. Et assurez-vous d'avoir des tests unitaires qui sont déjà au travail pour tout votre changement de touche. Cela signifie que toutes vos modifications dépendances, à la fois haut et vers le bas-stream. Les tests unitaires ne pas seulement s'assurer que le code fonctionne, mais dans ce cas, fournir quelques (petites) niveau de tests de régression pour vous.
8. Testez vos modifications, à la fois dans et hors du débogueur. Assurez-vous que votre changement "semble fonctionner."
9. Maintenant trouver quelqu'un dans l'entreprise afin de le tester.
10. GOTO 6

Bonne chance! Je vais être honnête, l'ensemble de l'analyse médico-légale bits est probablement ma partie préférée de une nouvelle application, même si les bases de codes sont généralement pourri jusqu'à leurs cœurs. C'est l'un des plus difficiles de travail que vous avez à faire en tant que développeur.

Answer 4

Je pense que votre idée de construction de la documentation que vous allez est un bon un, et un wiki peut travailler.

Vous ne dites pas dans quelle langue vous faites affaire avec, alors cette idée suivante peut ne pas fonctionner pour vous, mais face à une charge de Java ne sais pas bien, je laod en un langage de modélisation UML de l'outil. Cela me permet de construire des diagrammes de classe de pièces intéressantes.

Je pense aussi à propos de l'ajout de la documentation dans le code, au moins pour les principales classes (si c'est ce que vous avez). Donc, dans mon monde Java je voudrais commencer à ajouter un peu de Java doc.

L'idée générale étant non seulement de comprendre ce qu'il se passe, mais laisser les choses dans un meilleur état pour quand vous vous déplacez, ou lorsque vous devez revenir à tout cela après une pause.