En tant qu'ingénieur logiciel, est-il important de lire le code des autres?

Je suis un ingénieur logiciel en herbe (maintenant un étudiant en deuxième année, majeur en CS) et j'ai vraiment du mal à comprendre les programmes des autres. Je veux savoir si cette compétence (ou son absence) peut être un handicap pour moi, et si oui, comment puis-je la développer?

C'est essentiel.

La façon dont vous le développez est en écrivant votre propre code (en grande partie), et oui, en luttant pour lire le code des autres.

Le problème, bien sûr, est que tout le monde ne pense pas comme vous. J'étais dans une classe Java de première année il y a longtemps et on nous a confié une mission. Contrairement à ce que je pensais (à savoir que les réponses convergeraient vers trois ou quatre solutions communes), tout le monde dans la classe avait une solution unique à la tâche.

Il s'ensuit que vous devriez lire un bon code.

C'est l'une des raisons pour lesquelles les modèles de conception sont devenus si populaires et pourquoi vous devriez les étudier. Les modèles de conception fournissent un vocabulaire commun avec lequel les programmeurs peuvent communiquer et régler votre esprit pour de "meilleures" façons de résoudre les problèmes informatiques.

Vous devez également étudier les algorithmes et les structures de données.

Corollaire: vous devez toujours vous efforcer d'écrire du code que les autres développeurs peuvent facilement comprendre.

C'est très important.

Une fois que vous aurez obtenu votre diplôme et que vous vous lancerez dans le monde, la plupart des projets sur lesquels vous travaillerez auront déjà du code fourni par d'autres. Lucky est le programmeur qui passe tout son temps sur des projets entièrement nouveaux!

C'est une compétence qui s'acquiert par la pratique et la patience, et dans de nombreux cas, c'est une compétence sur laquelle beaucoup de gens n'ont pas vraiment l'occasion de travailler avant d' avoir obtenu leur diplôme et d'obtenir ce premier emploi. Se détendre!

(bien que si votre école a un programme coopératif, cela vous donnerait une expérience de pré-diplôme pour travailler sur de grands projets qui sont principalement écrits par d'autres personnes ET cela vous donne des crédits académiques! Quelque chose à examiner, s'il est disponible)

C'est une compétence majeure , selon les spécificités de l'endroit où vous travaillez, elle pourrait même être plus importante que l'écriture de code elle-même.

Comme d'autres compétences, la pratique rend parfait! Essayez de lire le code d'un autre programmeur, de le déboguer et ce qui m'aide personnellement, c'est de refactoriser ou d'améliorer de petits morceaux de code et de les développer à partir de là.

Il existe des compétences distinctes en lecture et en écriture de code.

• L'un est la syntaxe. Savoir à quoi ressemble une déclaration de méthode.
• L'autre est l'intention. Savoir pourquoi la méthode existe et à quoi elle sert.

Quant à la lecture contre l'écriture. Oui, la lecture est essentielle.
Quelques maximes qui aident beaucoup d'entre nous à cela:

• Le code est lu 10 fois (au moins) pour chaque fois qu'il est écrit.
• La lecture du code par quelqu'un d'autre est souvent ... moi à l'avenir la lecture du code.
• Je ne défendrais pas mon style de code depuis plus d'un an, il s'est amélioré depuis.

D'ACCORD. C'est donc très bien. Passons maintenant à ce que vous vivez probablement.

omg, ce flippe énorme base de code avec des dizaines de milliers de lignes de code source et des classes qui sont plusieurs centaines de lignes avec dépendances folles et chaque fois que j'essaie de suivre quelque chose que je dois garder 10 niveaux dans ma tête, etc, etc.
Son familier ? Ouais. Profonde respiration. Se détendre. C'est normal. C'est de cela que sont faits les systèmes de production. Les gens survivent (et s'épanouissent) dans ces situations apparemment incompréhensibles parce que:

• des tests (espérons-le) existent et ils aident également à documenter le système.
• les programmeurs s'associent et cela apporte souvent plus du double du résultat.
• un bon programmeur sait bien dire qu'il ne comprend pas tant qu'il ne le fait pas.
• les modifications ne sont souvent qu'une ou plusieurs lignes de code permettant d'isoler les éléments à tester
• les bases de code prennent des mois et même des années pour se familiariser avec

La plupart de ces réponses se concentrent sur l'importance de la lecture de code pour l'auto-amélioration. Je suis entièrement d’accord avec et je l’approuve.

Il y a un autre angle dont il faut se méfier - même si vous étiez un prodige qui ne pouvait pas bénéficier de la lecture d'autres approches (impossible, mais pour les besoins de l'argumentation ...), vous auriez encore besoin de savoir lire le code à cause d'un concept qui n'existe pratiquement pas en milieu universitaire: la grande majorité des projets industriels sont des projets sur le terrain (c.-à-d. dans ou en intégrant une base de code préexistante).

Le besoin de lire le code juste pour comprendre la base de code et les processus existants est réel. Il est toujours possible de poser des questions à un autre développeur sur le code, mais cela ne vous prendra que si longtemps. Les gens partent, changent de projet ou le temps passe tout simplement. Les détails de bas niveau disparaissent de la mémoire et les programmeurs de maintenance appliquent des correctifs. À un moment donné, il n'y a pas de source unique de vérité, sauf le code lui-même.

Une bonne hygiène du code, des guides de style, des révisions de code et une aide à la documentation, mais à un moment donné, le code est la source de la vérité pour ce qui se passe et la seule façon de trouver la réponse sera d'aller le chercher vous-même. Mis à part ses utilisations dans l'auto-développement, la capacité de lire du code est une compétence distincte de l'écrire.

Comprendre le code d'autrui est quelque chose auquel vous ne pouvez pas échapper, car vous travaillerez très probablement en équipe même si vous ne le faites pas en équipe, vous rechercherez différentes choses sur Google et vous devrez comprendre un exemple de code. Alors oui c'est un must.

Ce que je ressens, c'est que tout le monde ressent ce sentiment peut-être moins que les autres spécialement au début, vous comprenez mieux votre code que les autres codes car vous passez beaucoup plus de temps avec votre propre code que le code de quelqu'un d'autre car non seulement vous lisez, mais vous écrivez et structurez dans votre esprit. Si vous commencez à passer plus de temps avec le code des autres et essayez d'abord de voir quel type de structure / flux est utilisé, cela vous fera certainement mieux comprendre le code.

Pour rendre mon argument encore plus convaincant si vous avez du code que vous avez écrit un an en arrière, essayez de le comprendre à nouveau et je peux dire avec certitude que vous prendrez plus de temps mais moins que le code des autres car vous avez une idée de la façon dont vous structurez votre code.

J'espère que cette aide, ne soyez pas déçu, c'est tout à fait normal. Passez plus de temps avec le code et vous finirez par l'obtenir.

Eh bien, je viens de recevoir un projet avec environ 100 000 lignes de code écrit par une équipe dans un autre pays, et je dois apporter des modifications très importantes à une copie de leur code au cours des prochains mois, tout en laissant autant de code en commun que possible.

Vous me dites comment je peux faire mon travail sans pouvoir lire le code des autres rapidement. Si vous ne pouvez pas lire le code des autres, vous êtes complètement, complètement coincé.