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:
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.
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:
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.
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.
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.
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.
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.
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.