Comment lisez-vous le code des autres? [fermé]


23

Presque tous les programmeurs avancés disent qu'il est très utile de lire le code d'autres professionnels. Habituellement, ils conseillent l'open source.

Le lisez-vous ou non? Si vous le faites, à quelle fréquence et quelle est la procédure de lecture du code? De plus, il est un peu difficile pour les débutants de gérer SVN - un tas de fichiers. Quelle est la solution?

Réponses:


25

Le lisez-vous ou non?

Oui.

Si vous le faites, à quelle fréquence

Du quotidien. Constamment. Je travaille avec de nombreux projets open source (principalement liés à Python) et je dois lire la source car c'est la documentation la plus précise.

et quelle est la procédure de lecture du code?

Hum. Ouvrez et lisez.

De plus, il est un peu difficile pour les débutants de gérer SVN - un tas de fichiers. Quelle est la solution?

Ouvrez et lisez. Alors lisez plus.

Ce n'est pas facile. Rien ne facilite les choses. Il n'y a pas de voie royale pour comprendre. Il faut du travail.


Merci pour votre réponse. Comment définir si le code est bon ou non? Parce que tous les projets open source ne sont pas réalisés par de vrais professionnels?
Sergey

1
@Sergey: "Quelle est la façon de définir si le code est bon ou non?" Lisez le code. "Bon" est subjectif. Si c'est utile et que vous pouvez le comprendre, c'est bien. Si c'est déroutant ou ne fonctionne pas vraiment, ce n'est pas bon. Il existe de très nombreux attributs de qualité: maintenable, sécurisé, adaptable, hautes performances, etc., etc., etc., le code peut être bon pour l'un et moins bon pour l'autre.
S.Lott


@Sergey - même s'il s'agit du meilleur code jamais écrit, si vous ne pouvez pas le lire (en raison de votre niveau d'expérience), cela ne vous fera aucun bien. Même si vous ne le considérez pas comme la meilleure utilisation de votre temps, vous allez vous exposer à du code mal écrit, vous pourriez donc aussi bien faire la différence. Comme l'a dit S.Lott, cela prend du temps et du travail.
JeffO

Bien que j'admire ceux qui peuvent s'asseoir et lire du code comme ils lisent un roman, je le trouve parfois un peu fastidieux. J'ai réalisé que pour moi, `` lire du code '' ne décrit pas vraiment les activités que j'entreprends - une meilleure expression pour ce que je fais est `` comprendre le code '' et cela implique de lire la documentation, de la parcourir dans un débogueur et même de lire les tests. J'ai écrit un long article sur la lecture de code - technikhil.wordpress.com/2010/07/06/how-to-read-code-a-primer
Nikhil

9

Il y a plusieurs couches à l'énigme que vous avez. Tout d'abord, commencez au niveau élevé, une vue à vol d'oiseau pour ainsi dire. Une fois que vous avez extrait un projet, il y aura un tas de fichiers dans une structure de répertoires. C'est la même chose que vous cherchiez en open source ou en source fermée (le code source est le code source après tout). Commencez donc par ceci:

  • Comment les fichiers source sont-ils organisés? Pouvez-vous dire par le nom du fichier ou le nom du répertoire contenant ce que vous pourriez trouver à l'intérieur? Nous, les programmeurs, avons tendance à aimer les noms prévisibles et la structure logique. Vous devriez pouvoir avoir une idée approximative de l'endroit où chercher un problème spécifique.
  • Quelle est la nature de l'application, est-elle basée sur le Web, en ligne de commande, GUI? La raison pour laquelle cela est important est que vous voulez savoir par où commencer le suivi de l'exécution. Si c'est sur le Web, vous voulez commencer par où l'application commence à traiter la demande. S'il est construit sur un framework, tant mieux. Une fois que vous connaissez le framework, vous pouvez généralement comprendre le code qui s'y trouve. Sinon, vous commencerez par le point d'entrée respectif de l'application de ligne de commande / interface graphique.
  • Obtenez une feuille de papier et un crayon, ou si vous êtes chanceux, un tableau blanc et des marqueurs effaçables à sec. Donnez les noms des composants (ou utilisez ceux fournis dans le code) et tracez des lignes entre les cases avec des flèches pour voir comment les choses sont traitées. Alternativement, si vous regardez un algorithme, esquissez les structures de données d'une manière que vous pouvez comprendre et esquisser comment il est manipulé.

Cela demande de la pratique, mais c'est certainement faisable. Plus vous en savez sur les bibliothèques et les frameworks que l'application utilise, plus vous savez comment le code doit être organisé et où chercher des réponses à des questions spécifiques. Certains codes sont un peu plus difficiles à suivre, surtout s'ils sont assez indirects. C'est pourquoi vous avez besoin du crayon et du papier. Finalement, une ampoule s'éteint dans votre tête et vous l'obtenez. C'est à ce moment-là que la lecture du reste du code prend tout son sens.


Un aspect de la lecture du code est l'abstraction. Des choses telles que découvrir comment les sources sont organisées résumeront certainement le processus de lecture de code.
David Gao

5

Ce n'est pas lire comme vous lisez un roman, mais plutôt comme lire un livre de référence. Un bon moyen est de choisir un bogue récemment corrigé dans un message d'archivage, de faire une différence de ce qui a changé et de lire les parties pertinentes jusqu'à ce que vous compreniez à la fois le problème et la solution. Les vulnérabilités de sécurité bien connues sont des bugs amusants à choisir car il y a beaucoup de discussions à leur sujet sur les forums. Ensuite, choisissez l'un des bogues «fruits suspendus bas» dans le suivi des bogues et lisez jusqu'à ce que vous compreniez comment le corriger vous-même. La plupart des professionnels de la lecture de code font des incidents lors de la correction de bogues ou de l'ajout de fonctionnalités.

Habituellement, les meilleurs exemples de code sont à peine perceptibles. Vous les comprendrez instantanément sans les lire plusieurs fois. Ils donnent l'impression qu'il était extrêmement facile à écrire, même si le code aussi bon passe généralement par de nombreux brouillons. Cela produit le sentiment paradoxal que, bien sûr, le code donné est la façon évidente de le faire, même si ce n'est pas la première façon de penser.

Lorsque vous rencontrez un code comme celui-ci, essayez de comprendre les informations qui ont servi à l'écrire et les principes de conception impliqués.Ainsi, lorsque vous vous retrouverez dans une situation similaire à l'avenir, vous pourrez, espérons-le, appliquer les mêmes principes.


4

Une astuce que j'utilise assez souvent lors de la lecture d'une fonction compliquée, le segment de code consiste à commencer à le refactoriser en quelque chose de plus lisible sans changer la logique.


1
+1: Moi aussi. // J'ai eu une fois un patron qui a remarqué la refactorisation et m'a accusé de perdre du temps. Il ne pouvait pas comprendre. Quel fou.
Jim G.20

2

Comment est-il difficile de gérer "un tas de fichiers"? Ce n'est pas différent de lorsque vous écrivez votre propre code, sauf que vous n'avez aucune connaissance préalable de son organisation à moins qu'il ne soit documenté.

Si vous, en tant que programmeur prétendu, ne pouvez pas comprendre la structure du projet à partir "d'un tas de fichiers", c'est un projet extrêmement mal organisé, ou vous êtes un programmeur incompétent (ou, dans les cas extrêmes, les deux).

Commencez à lire, essayez de trouver des points d'entrée ou d'autres classes / méthodes pivot essentielles, et construisez une compréhension de la façon dont tout se combine à partir de là. Ce ne sera pas instantané, cela prendra du temps, mais cela peut être fait même s'il n'y a aucune documentation.


3
"Cela prendra du temps" pour "construire une compréhension" est à peu près la définition de "dur". Ce n'est pas parce que c'est une difficulté à laquelle nous devons faire face tous les jours qu'il est moins difficile. "Où dois-je faire ce changement?" est une question courante même chez les professionnels. En outre, le contrôle des sources et le traitement des grandes bases de code sont l'un des énormes trous dans les études collégiales. Je pense que j'ai fait un ou deux projets au collège qui nécessitaient plus d'un fichier source, et ils n'ont obtenu qu'une dizaine de fichiers.
Karl Bielefeldt

0

La meilleure chose que vous puissiez espérer en lisant le code d'un autre projet, que ce soit une API ou un logiciel, c'est que les variables, les fonctions et les noms de macro ne sont pas abrégés de manière ambiguë ou nommée afin que vous puissiez comprendre leur intention.

Mais à part cela, il faut une quantité décente de connaissances réparties sur le langage, les techniques de programmation et également sur le but du code lui-même pour pouvoir plonger dans du code complexe.

J'essaie actuellement de voir comment Lua fait une partie de sa magie, mais j'arrive au point ci-dessus où de nombreux identifiants sont nommés vaguement et plutôt abrégés au point où je ne peux pas comprendre quelle ligne essaie pour faire la chose que je sais doit être faite à un moment donné dans le code de fonction ... Les variables fréquentes à une seule lettre et les noms de macro / fonction plutôt abrégés font ma tête.


0

Après avoir regardé le "Tout d'abord, commencez au niveau élevé, une vue à vol d'oiseau", comme @Berin Loritsch l'a suggéré, vous pouvez rechercher des tests et / ou des tests d'intégration s'il y en a.

il est intéressant de voir comment les détails (api-) fonctionnent.

Le test d' intégration donne généralement un bon aperçu des processus métier.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.