Que regardez-vous en premier: le code ou le design?

Si vous venez de découvrir un nouveau projet, quelle est la première chose que vous recherchez pour avoir une idée de son fonctionnement?

Cherchez-vous d'abord le design? S'il y a un design, que cherchez-vous dedans? Diagrammes de classe ou diagrammes de déploiement ou diagrammes de séquence ou autre chose?

Ou allez-vous directement pour le code? Si oui, comment comprenez-vous comment les différentes couches interagissent?

Je commence par le code. S'il y en a, des documents de conception séparés sont tout aussi susceptibles d'être erronés ou mal conçus que non. Donc, je commence par essayer de tracer un flux simple à travers le code; s'il s'agit d'une webapp, il peut s'agir d'une requête ou d'une séquence de requêtes, par exemple. Une fois que j'ai fait ça, j'ai une sorte de squelette pour mieux comprendre. Ensuite, je pourrais revenir en arrière et lire des conceptions ou d'autres documents, mais à ce stade, j'ai quelque chose de concret pour les relier et les valider, afin de pouvoir détecter les informations duff. Ou je pourrais simplement continuer à lire du code, ou des cas de test, etc.

Je commencerais à un niveau supérieur. S'il existe une documentation destinée à l'utilisateur - manuel d'utilisation ou guide. À défaut, jetez un coup d'œil aux spécifications pour que vous ayez une idée de ce que le logiciel est censé faire. Je voudrais que de regarder la conception et d'essayer de le mapper sur les fichiers de code. J'espère que ceux-ci sont structurés en dossiers d'une manière sensée. Je choisirais ensuite une partie de la conception et irais dans les fichiers pour suivre le flux du code sans être trop embourbé dans les moindres détails.

Je commence par mettre en place un système de développeurs. J'utilise la procédure documentée. Cela permet au chat de sortir du sac sur la synchronisation de la documentation avec la réalité.

Il me dit également quelles sont les dépendances. C'est important.

Maintenant que j'ai une configuration pour les développeurs (et que je marque le document d'installation avec des corrections au fur et à mesure), je crée une version. Je finis par poser des questions tout au long de cette phase.

Maintenant qu'il est construit, je fais l'exercice d'introduction à partir du manuel d'utilisation. Cela me dit à peu près ce que fait réellement le système.

Maintenant, j'ai un indice partiel sur le système, j'ai lu les documents de conception, que je crois maintenant proportionnellement à la façon dont les documents ont été erronés jusqu'à présent.

Une fois que j'arrive à la documentation comportementale réelle, je peux commencer à regarder le code et à voir ce qui est vraiment là. Ils ne font jamais la queue, mais je sais maintenant combien croire.

Ensuite, je regarde la sortie IDE pour les commentaires "todo" et "fixme". Des choses comme «corriger dans la version 2.0» sont également des astuces.

Il s'agit donc d'apprendre la véracité, et comme les gens le soulignent, les documents de conception séparés sont rarement à jour ou corrects, mais cela vous dit ce que les gens pensaient à un moment donné. Et bien sûr, ces gens ne sont probablement pas là pour interroger.

Ma préférence est de commencer par la conception pour obtenir un aperçu du projet et essayer de comprendre certaines de ses principales caractéristiques et / ou structure avant de percer les détails.

Toujours le design. Avec le code, cela vaut la peine de passer par les étapes de configuration du développeur (vérifier la source, construire le projet, apporter les modifications de configuration nécessaires), mais il est inutile d'essayer d'apprendre la structure d'une application à partir de son code. Cela ne vous dit que ce qu'est la structure, pas pourquoi la structure est ou ce que les autres développeurs pensent que les points forts et les mauvais points sont de l'architecture. Ceux que vous apprenez des diagrammes du tableau blanc et des discussions avec les développeurs.

Pour un logiciel complexe, je l'aborderais à peu près comme s'il s'agissait d'un nouveau projet de développement. Commencez par les grandes idées - vision, contexte, portée, parties prenantes. Lisez la documentation utilisateur et voyez comment elle est utilisée. Obtenez une formation utilisateur avec le logiciel si possible (ou applicable). Ensuite, commencez à examiner les exigences et la documentation de conception pour avoir une idée de son fonctionnement à un niveau élevé. Parlez aux designers s'ils sont toujours là. Regardez l'architecture du système sous différentes perspectives. À partir de là, commencez à creuser dans la fonctionnalité de base et à regarder du code, en revenant aux exigences et à la conception si nécessaire. Lorsque vous regardez le code, exécutez le logiciel pour le voir en action. Pendant ce temps, compilez une documentation récapitulative pour référence future - vous possédez Cliffs Notes. Branchez-vous jusqu'à ce que vous ayez une assez bonne idée de la façon dont tout cela fonctionne et s'emboîte, mais concentrez-vous sur les pièces avec lesquelles vous allez travailler. Vous avez maintenant une compréhension de haut en bas de l'ensemble du système, ou du moins des parties qui vous concernent.

Bien sûr, dans le monde réel, vous n'aurez peut-être pas le temps de passer par tout cela avant de commencer à vous salir les mains, en particulier sur les grands projets. Mais c'est comme ça que je le ferais si ça ne tenait qu'à moi.

Vous devez travailler dans les deux sens entre le code lui-même et tous les documents de conception.

• Vous pouvez commencer par le code ou la conception, et cela n'a pas vraiment d'importance. Lisez le code jusqu'à ce que vous soyez bel et bien confus, puis consultez les documents de conception. Ou, lisez les documents de conception pour obtenir une image de haut niveau, puis regardez le code pour voir à quoi il ressemble. Répétez presque indéfiniment tant que vous travaillez avec le code.

• Sachez que les documents de conception sont presque toujours obsolètes et incorrects à bien des égards. Cependant, tant que vous gardez ces points à l'esprit, les documents obsolètes vous aident toujours à comprendre l'esprit de l'auteur à un moment donné dans le passé. Beaucoup de problèmes et de préoccupations de haut niveau seront toujours valables, et vous pourrez très probablement comprendre plus rapidement comment le code est arrivé là où il se trouve, si vous avez même une image datée de l'endroit où l'auteur pensait à l'origine qu'il allait aller.

• Pendant que vous travaillez sur le code et la conception, créez vos propres documents qui décrivent votre compréhension du code aujourd'hui. Peut-être que ces documents sont un simple croquis ou deux, peut-être qu'ils sont écrits dans un wiki, peut-être qu'ils sont autre chose. Ne les compliquez pas trop: pas de documents Word de 30 pages. Décrochez simplement vos idées, ce qui clarifiera grandement votre propre pensée.

Cela dépend du type d'application. Si c'est une application centrée sur les données, je commence généralement par la conception de la base de données. Si elle a une interface utilisateur que vous pouvez exécuter (ou de bons designs d'écran), ceux-ci peuvent également vous donner une bonne idée de ce que l'application fait très rapidement (je ne parle que de quelques heures ici au plus). Après cela, je commence à creuser dans le code et cela aura plus de sens car je sais ce que fait l'application.

Je commence par la documentation de conception. En particulier, la spécification - qui indique l'intention de la chose examinée.

Si possible, je regarde ensuite les notes de conception et la documentation pour avoir une idée générale de la façon dont cela a été fait, du processus de réflexion, du style et de la nature des personnes concernées.

Si possible, je parle ensuite aux personnes qui y ont travaillé - que fait-elle? Comment? Pourquoi? Où sont les corps enterrés?

Les développeurs ont tendance à sauter dans le code: "Laissez-moi vous montrer ce code". C'est bien pour eux mais a tendance à détourner mes besoins - qui est de comprendre le haut niveau qui donne du contexte aux choses de bas niveau.

Il utilise de grandes quantités de puissance cérébrale pour regarder de petits morceaux de code, hors de leur contexte complet, et comprendre quoi que ce soit de significatif. Donc, si possible, amener les développeurs à parler du PRINCIPE, de la structure, des unités, des modules, tout ce qui mène à une appréciation de la tâche.

Ce n'est qu'alors qu'il vaut la peine d'essayer d'entrer dans le code.

Dans le grand schéma des choses, regarder le code, c'est comme regarder une page pleine de 0 et de 1. Il y a du sens, mais il faut beaucoup de temps pour le comprendre. Avoir une idée de l'endroit où chercher et des parties significatives aide à réduire l'espace de recherche.

Tout cela dit - quand il n'y a pas de doco, pas de personnes et seulement du code - alors il n'y a rien d'autre à faire que de regarder le code.

Dans ce cas, je n'essaye pas normalement de le comprendre par une lecture lente et profonde, je fais une passe rapide, parcourant tout. Parfois, il s'agit simplement de fichiers ouverts et appuyez sur la touche page suivante. Vous pouvez obtenir une appréciation incroyable d'une vue d'ensemble juste en faisant cela. (Et dans certains cas, je jette même des fichiers exécutables de vidage de chaîne et les fouille à la recherche de signatures et de modèles. Cela a été incroyablement fructueux au cours des 20 dernières années.)

Je commence par les tests. Si les tests unitaires et les tests d'intégration sont bien écrits, ils décrivent les cas d'utilisation. S'ils ne sont pas bien écrits, ou pas du tout (malheureusement, c'est en grande partie le cas), je commence par les points d'entrée dans le code et je fais correspondre ceux-ci avec le design.

J'écrirai ensuite des tests pour chaque cas d'utilisation, découvert par l'arborescence que vous trouverez après avoir examiné les points d'entrée, pour sonder le code et utiliser les utilitaires de couverture de code pour voir ce qui me manque. Ces tests me disent exactement comment fonctionne le code.

J'essaie toujours d'ajouter de la valeur à quelque chose que je regarde; écriture de tests, nettoyage de code, refactorisation de grandes fonctions (20+ lignes).

Je trouve que la création de documentation à elle seule n'ajoute aucune valeur réelle au code car elle n'interagit jamais avec le code.

eh bien, c'est quoi "le design"? un README? un diagramme uml? vous pouvez créer un document de conception à mi-chemin (et la plupart le font), vous ne pouvez pas coder à mi-chemin

n'importe quelle conception va simplement être une opinion , alors que le code est le fait

je ne ferai référence à des documents secondaires que si je ne comprends pas le raisonnement du code

la lecture de code est une compétence essentielle pour un développeur. vous pourriez aussi bien l'apprendre maintenant, de toute façon vous n'aurez pas accès à une documentation très utile au cours de votre carrière

Ensuite, je regarde le README, TODO et Changelog du développeur. Si je ne comprends pas pourquoi le logiciel a été écrit, comment il a été écrit et où il va ... je ne l'utilise pas.

Concevez d'abord, puis codez, de haut en bas si vous le souhaitez, donc je comprends le contexte à chaque niveau où je dois travailler.

Mais si je dois faire un changement très spécifique, comme fixer un rapport ou un calcul, je vais juste regarder le code.

Plus précisément, mon approche "design first" est celle-ci:

Je commence par le modèle de domaine s'il y en a un, s'il n'y en a pas, j'en construis au moins un de base (un bon point de départ est le modèle de données). Il définit le "glosaire" de l'application et la relation entre les objets (classes).

Il représente "quels objets sont traités" par l'application.

Ensuite, je cherche le modèle de cas d'utilisation pour découvrir "quels processus sont effectués" par l'application, bien que je préfère une carte de processus si c'est le cas, qui montre des séquences de processus.

Après cela, je devrais avoir une belle image de l'application, puis je pourrai concevoir le changement.

Soit dit en passant, la réponse ci-dessus se situe dans le contexte des applications métier.

Le code ne ment pas. Certainement une bonne idée d'avoir d'abord un aperçu du projet pour comprendre ce qu'il fait. Cependant, si votre tâche est d'obtenir une compréhension détaillée du fonctionnement du projet, regarder le code, du moins pour moi, c'est comme regarder un puzzle pièce par pièce, sauf qu'avec chaque classe que vous regardez, vous en ajoutez une autre pièce du puzzle. Si le code est bien structuré, vous pouvez voir un modèle se former à partir des noms des classes sans même rechercher ce que fait la classe. Dans de nombreux cas, vous pouvez obtenir des conseils et des indices du code qui vous aideront davantage.

Enfin, vous obtenez ce qui est une idée irrévocable de ce que fait le programme, un puzzle terminé. La documentation peut être incomplète ou inexacte, mais le code ne ment jamais. Tout cela, vous pouvez le faire sans comprendre ce que fait chaque méthode individuelle. Tout le monde ne peut pas en apprendre davantage sur un projet de cette façon, mais si vous le faites souvent, cela vous est plus facile, sans oublier que vous pouvez obtenir l'essentiel d'une application de taille moyenne en quelques heures d'étude. Bien que je suppose que tout se résume à la préférence.

1. Le but fonctionnel de l'application
2. La portée fonctionnelle et le flux de l'application et sa liaison avec d'autres systèmes du client.

Après avoir vu le code du module / point d'application le plus critique: voir le code, je peux vérifier la qualité de la conception.

Exemple:

Vous devez travailler dans la gestion des applications d'une application Web sur les rapports financiers.

1. Je demande et lis la documentation sur le but: quelles données doivent être déclarées? Qui utilise cette application?
2. Quels sont les systèmes liés? Y a-t-il une date limite pour recevoir ou envoyer des données à quelqu'un? Si ce système est en panne, quelles autres applications sont endommagées ou arrêtées, quels autres services sont endommagés?

Après avoir lu le code sur le message, l'application de début et de fin (pour un verrouillage probable en db), le processus maître de création de données, ce qui doit être signalé, etc., etc. (par exemple, dans le stockage de gaz, le processus maître concerne le calcul du stock de gaz dans la zone de stockage des clients avec approvisionnement et injection; le processus secondaire est la facturation concernant ces données calculées précédemment)

Ni code ni design. J'aime parler aux parties prenantes et aux utilisateurs finaux et découvrir comment cela fonctionne de leur point de vue. Une fois que je peux créer une image dans mon esprit à partir d'eux, j'ai un aperçu rapide de la conception technique, puis du code.

J'irai d'abord avec la conception puis le code simultanément. C'est très important car chaque projet est différent. Vous devez élaborer un plan et un niveau élevé de flux de travail de processus de A à Z avant de pouvoir commencer à travailler sur les codes simultanément. Chaque décision prise doit être documentée afin que les autres équipes (ou vous-même) qui développent / développent les codes connaissent la dernière mise à jour et ce qui a été confirmé.

S'il existe un bon document de conception de haut niveau, je l'utilise. Il doit être concis et à jour. Si c'est trop verbeux ou obsolète, je vais me diriger vers le code.

Bien sûr, cela dépend du projet, non? Un projet extrêmement complexe ou à multiples facettes est peut-être mieux abordé par le biais de la documentation (si la documentation est suffisamment solide.)

Un module simple ou une application simple est, à mon avis, presque toujours mieux approché au niveau du code.

Il n'y a pas de bonne réponse pour chaque situation!