Comment suivez-vous les grands projets?

Lorsque je traite un projet contenant de nombreux fichiers différents, il me semble toujours perdre de vue la façon dont les parties interagissent les unes avec les autres. Je n'ai jamais vraiment eu beaucoup de mal à comprendre des composants plus petits de manière isolée, mais à mesure que la complexité du projet augmente, je me trouve incapable de construire mentalement une compréhension de ce qui se passe. Je le remarque en particulier avec les projets OOP, car le nombre de méthodes et de fichiers source augmente.

Mon parcours: je suis programmeur web autodidacte. J'ai traité principalement de python pour des scripts rapides et sales, mais j'ai également fait quelques projets de base de django . J'aime les frameworks Web tels que les flacons , car dans la simplicité d'une mise en page à fichier unique, je peux facilement suivre (principalement) ce qui se passe.

Je me retrouve maintenant dans une situation où j'ai besoin d'interagir avec un grand projet PHP Zend Framework que quelqu'un d'autre a développé, et je suis accablé d'essayer de comprendre le code réparti sur de nombreux fichiers.

Quelles techniques et quels processus avez-vous trouvés utiles pour comprendre une grande base de code que quelqu'un d'autre a développée? Y a-t-il un diagramme particulier qui vous aide à saisir l'image plus grande?

L'astuce pour comprendre une grande base de code est de ne pas essayer de tout comprendre. Après une certaine taille, vous ne pouvez pas tenir un modèle mental dans votre tête. Vous commencez avec un point d'ancrage qui a du sens pour la tâche sur laquelle vous devez travailler en premier, puis vous vous connectez à partir de là, en apprenant uniquement les pièces dont vous avez besoin et en vous assurant que le reste fonctionne comme annoncé. C'est comme comprendre la récursivité. Si vous essayez de tenir la pile entière dans votre tête, votre cerveau explose.

Grep, débogueurs et intellisense sont vos amis ici. Si vous ne savez pas comment une fonction finit par être appelée, définissez-y un point d'arrêt et descendez la trace de la pile.

L'autre chose à noter est que les grandes bases de code ne surgissent de nulle part. Plus il est grand, plus il y a de programmeurs expérimentés, alors demandez-leur par où commencer, mais soyez précis. Posez des questions telles que "Je dois ajouter un nouveau fournisseur de paiement. Où dois-je chercher dans le code?" Concentrez-vous uniquement sur cette tâche au lieu d'essayer de comprendre toute la base de code et, pièce par pièce, votre familiarité augmentera.

Il n'y a pas de raccourci. Vous n'avez qu'à en souffrir.

Pour répondre à votre question sur la façon d'obtenir des diagrammes, doxygen est ce que vous voulez. AFAIK ça marche avec PHP.

Plus généralement, je passe par les étapes à peu près suivantes lorsque je rencontre une nouvelle base de code:

1. Comprenez ce qu'il fait du point de vue de l'utilisateur. Être capable d'utiliser réellement l'application vous-même comme un utilisateur expérimenté. Comprenez comment les vrais utilisateurs finaux travaillent avec. Cela pourrait nécessiter de s'asseoir avec eux jusqu'à ce que vous compreniez bien ce qu'ils font.

2. Communiquez avec les développeurs d'origine, si possible. Au début, vous aurez des questions architecturales stimulées par l'expérience de l'utilisateur final. Plus tard, vous aurez des questions sur l'implémentation des cas limites et des détails. Être en mesure d'obtenir des réponses des développeurs aidera beaucoup plus que tout commentaire ou documentation (qui est au mieux incomplet et souvent trompeur ou totalement absent).

3. Découvrez le cadre que vous utilisez. Au minimum, vous devriez pouvoir créer un "bonjour le monde" ou une autre application simple avec ce cadre avant de plonger dans l'application de production.

4. Maîtrisez tout le processus de déploiement (mieux fait pendant que les développeurs d'origine vous tiennent la main). Si vous ne pouvez pas prendre la base de code actuelle et la construire et la déployer via un environnement de test / validation / prod, vous êtes toast. Même le plus petit changement nécessitera de sauter à travers tous les cerceaux du déploiement, alors pourquoi ne pas descendre cette partie tout de suite? Ce faisant, vous découvrirez tous les charmants serveurs, bases de données, services et scripts utilisés par l'application - vous saurez «où elle vit».

5. Maîtrisez les tests fonctionnels (le cas échéant). Comment savoir si la chose fonctionne correctement? Que doivent faire les opérateurs pour le soin et l'alimentation de l'application?

6. Comprenez les journaux de l'application. Bien que je n'ai jamais travaillé avec PHP, je vais faire une supposition folle et dire que toute application PHP sérieuse aura un certain type de journalisation. Si vous comprenez les journaux, vous aurez un bon point de départ le moment venu pour les problèmes de débogage.

---- Notez que jusqu'à présent, je n'ai même pas mentionné regarder de près la base de code. Il y a BEAUCOUP que vous pouvez apprendre sur un grand projet sans même regarder le code. À un moment donné, bien sûr, vous devez vous familiariser avec le code. Voici ce qui m'aide:

7. Pour les diagrammes, doxygen est un excellent outil qui générera pour vous des graphiques d'appel et d'autres relations. Il se trouve que la fonctionnalité PHP est disponible! Si vous n'avez pas essayé le doxygène, vous devez absolument l'essayer. Bien que je ne puisse pas garantir à quel point il sera intelligible pour le code dans un cadre, mais cela pourrait aider. Les développeurs originaux sont souvent choqués par ce qu'ils voient lorsqu'ils sont présentés avec des documents générés par doxygen de leur code. La bonne nouvelle est que cela aide vraiment à rafraîchir leur mémoire et à mieux vous aider.

8. Si vous avez une suite de tests unitaires, en y regardant de plus près, vous devriez avoir une fenêtre sur le fonctionnement interne de l'application. Ce sera également le premier endroit pour rechercher les bogues que vous pourriez avoir introduits lors des modifications.

9. Les signets IDE sont inestimables pour baliser les points chauds dans la base de code. Le fait de pouvoir les parcourir rapidement favorisera la compréhension.

10. La lecture des rapports de bogues récents et de leurs résolutions est également utile pour comprendre les points chauds et vous aidera à vous familiariser avec les parties les plus pertinentes de la base de code.

Comme demandé, voici mon commentaire comme réponse.

Lorsque je travaille avec du code d'autres personnes, j'ai tendance à créer ou si possible à générer des diagrammes de classes UML pour me donner un aperçu de la structure statique. Le diagramme visuel m'aide surtout quand je dois revenir plus tard et que j'ai déjà oublié le contexte d'une classe. Je le fais parfois pour un comportement dynamique et à la ligne sur les interactions entre Contributors, mais je ne le fais pas que souvent.

Si la base de code contient des tests (intégration ou unité), ceux-ci valent parfois la peine d'être vérifiés également.

En fait, je vais commencer à le faire au cours de cette semaine, où un nouveau client a besoin d'améliorations pour un produit qui a été laissé par un autre développeur. Voici les étapes à suivre:

a) Identifiez le cadre de programmation utilisé, ce qui aide à savoir comment circule l'application.

b) Identifier les services communs - journalisation, gestion des exceptions, MVC, connexion à la base de données, audit, affichage (génération de pages) car ce sont les parties que nous utiliserons le plus.

c) Parcourez les flux d'utilisateurs courants (dans l'application), puis essayez de les aligner sur la façon dont le code est présenté

d) Essayez de faire quelques changements et voyez comment ils sortent. C'est la plus grande étape car jusqu'à ce que vous commenciez à apporter des modifications, le code reste une boîte noire ....

Je vous ferai savoir quelles autres idées je reçois au cours des deux prochaines semaines

Je pense que vous devriez lire la documentation. Je sais que les pirates adorent vous dire "le code est la documentation" et l'utiliser comme excuse pour ne pas écrire de documentation, mais ils ont tort. Regardez le noyau Linux, un projet logiciel massif de plusieurs millions de lignes de code: je ne pense pas que quiconque puisse vraiment venir sans avoir lu un livre et simplement le ramasser. Si le code avec lequel vous travaillez n'est pas documenté (ou bien commenté s'il s'agit d'un projet plus petit), ce n'est probablement pas du bon code.

Si vous travaillez avec quelque chose de vraiment gros sans aucune documentation (j'y suis allé aussi, c'est difficile!), Ce que j'ai trouvé qui aide est d'essayer d'isoler la partie sur laquelle vous travaillez. Dans cette partie du code, déterminez comment les données / événements / messages / interactions entrent et sortent de cette unité. En d'autres termes, inversez l'ingénierie de l'interface. Écris le. La prochaine fois que vous travaillez sur une autre unité (bonus si elle parle à celle que vous avez travaillé en premier), faites la même chose. Conservez toute votre documentation. Après quelques mois, vous aurez une belle image de la façon dont la chose coule.

Déterminez l'interface d'une petite unité sur laquelle vous travaillez et enregistrez-la pour référence ultérieure. Au fil du temps, vous assemblerez la plupart de son fonctionnement. Trouvez ce que fait votre programme et retracez le flux de ce message. Par exemple, si votre système prend un message réseau d'entrée et envoie un message de sortie, retracez comment ce message circule dans le système, sans vous soucier de tous les détails - voyez simplement où il va.

Ce que je fais, c'est de créer un modèle UML unique à partir de tous les fichiers qui ont été inversés de java en UML. Cette approche signifie que le modèle n'est plus seulement une vue abstraite du projet mais le projet lui-même entièrement mappé sur MOF et donc UML.

Ce que j'obtiens est un grand modèle unique composé de plusieurs sous-modèles composés chacun par des packages qui sont composés par des classificateurs, etc. Je veux dire que la même méthode peut appeler un classificateur dans le projet A et un autre classificateur dans le projet B. La seule façon de voir la structure complète du projet est de les inverser tous les deux en même temps. Je n'ai pas le temps de créer des diagrammes de composants et les informations ne sont pas vraiment précises. Je préfère demander à l'ordinateur d'inverser le projet complet pour moi. Je fais un reverse à chaque itération avec l'équipe et tous mes diagrammes sont immédiatement mis à jour. L'ingénierie inverse est incrémentielle et utilise le mappage des ID Java vers UML. Je veux dire que chaque élément java est mappé à un élément MOF unique et unique qui reste le même pendant toute la vie du projet, même s'il est refactorisé. Cela ne donne plus de limite à la modélisation UML et permet une modélisation de projet très très vaste et complexe. Pour votre information je travaille avec des projets ayant plus de 5 000 000 lignes de code OOP. Tous mes projets sont inversés correctement et la navigation graphique est possible

J'utilise uniquement des diagrammes de classes car à partir de mon modèle UML, je peux créer autant de vues que nécessaire qui sont toujours à jour. Je peux également modéliser des projets très complexes.