Est-il plus facile d'écrire un logiciel que de le lire et de le comprendre à partir de zéro? [fermé]

12

Un de mes amis et moi avons discuté hier des différences entre l'écriture d'un grand logiciel C ++ et sa compréhension en tant que nouvelle recrue.

Est-il possible qu'un logiciel se faisant ligne par ligne et que ce processus ressemble à la façon dont nous (les humains) apprenons des choses et construisons une chose au-dessus d'une autre, il est plus facile d'écrire un gros logiciel que de le lire et de comprendre ce qu'il fait (parcourir le code aide mais vous devez vous souvenir de plusieurs classes / fichiers source ensemble, vous ne savez même pas pour quoi ils ont été écrits, le code multithread ajoute des points de malus)?

Cela semble bizarre au début, mais après avoir réfléchi un peu, cela semblait raisonnable

Makane Elhay
la source
1
Brève explication de la clôture: Bien que ce soit une excellente question, c'est aussi une question à laquelle on ne peut tout simplement pas répondre, seulement discutée (de manière approfondie). Il y a trop de facteurs à considérer, la qualité et le style du code, les compétences d'apprentissage du lecteur et sa familiarité avec le projet et la langue, la taille du projet, etc. Si vous êtes intéressé à discuter davantage de la fermeture, il y a déjà une question à ce sujet sur notre site Meta.
yannis
Le livre "Modèles d'apprentissage" parle du voyage du novice au maître artisan. Il répond à de nombreuses questions des programmeurs débutants, apprentis, compagnons dans leur évolution de carrière. Il faut un certain temps pour utiliser de nombreux modèles, mais cela fait partie du voyage. L'un des modèles consiste à écrire des «jouets brisés» ou des «prototypes» qui aident à comprendre et à comparer avec les systèmes de production. Il existe de nombreux modèles plus utiles.
GuruM

Réponses:

41

Sur la base de mon expérience, je classerais les activités suivantes dans l'ordre, du plus facile au plus difficile.

  1. Lire un bon code
  2. Écrire un mauvais code
  3. Écrire un bon code
  4. Lecture d'un mauvais code

Le classement ci-dessus conduit à 2 conclusions

  1. Bien qu'il soit plus facile d'écrire du code que de lire du mauvais code, il est plus facile de lire du bon code que d'écrire votre propre code
  2. Écrire du mauvais code est plus facile que d'écrire du bon code, mais écrire du mauvais code vous prépare à lire du mauvais code, ce qui est le plus difficile de tous. D'autant plus qu'un mauvais code est lu plus qu'il n'est écrit.

Bien sûr, un bon code et un mauvais code sont de larges généralisations. Je recommande Code complet et code propre pour plus de détails sur le bon code.

Aaron Kurtzhals
la source
Beaucoup d'autres choses peuvent conduire à un "mauvais code" - manque de cohérence interne, vision unificatrice ou planification. Un manque général de planification ou de modularisation appropriée du code. J'ai vu un bon code qui était inutile car il n'utilisait pas de fonctionnalités de langage intégrées qui auraient tout aussi bien fonctionné.
Ben DeMott
Aussi, comment écrire du bon code: cdn.thenextweb.com/files/2011/01/65987_700b.jpg
CurtisHx
2
À mon échelle, lire un mauvais code reste plus facile que d'écrire du bon code. Au pire, vous pouvez lancer un débogueur sur un mauvais code que vous essayez de lire, ou le modifier avec un outil de refactoring.
mouviciel
2
Écrire du mauvais code n'est facile qu'au point où il doit s'intégrer et fonctionner, ou changer en fonction des exigences changeantes. Si vous "vous programmez dans un coin", ce n'est plus facile.
Kaz
@mouviciel La lecture de mauvais code écrit par des programmeurs très intelligents qui ne devraient pas écrire de mauvais code peut être difficile. La lecture de mauvais code écrit par des programmeurs naïfs est facile. Mettez simplement votre "chapeau naïf" et il deviendra évident ce que le code ne parvient pas à accomplir. :)
Kaz
13

Cette question fait appel à un faux consensus. http://en.wikipedia.org/wiki/False-consensus_effect

Différentes personnes apprennent et absorbent les informations différemment. Cela ressemble aux apprenants auditifs, aux apprenants visuels et aux apprenants kinesthésiques. Pour certains, la lecture de code est plus facile, pour d'autres, la création de code est plus facile. Pour moi, c'est ce dernier. Pour les autres membres de mon équipe, c'est le premier. Je ne pense pas qu'il soit utile de trouver un consensus ou une majorité. Il vaut mieux comprendre comment votre cerveau absorbe et apprend les informations et utiliser ces connaissances pour vous améliorer et apprendre à accepter d'autres personnes différentes.

mawcsco
la source
1
Il est certainement préférable de poser la question et de solliciter l'opinion que de simplement croire que cette hypothèse (ou toute autre) est automatiquement correcte. Reconnaître comment différentes personnes abordent le même problème peut souvent avoir un effet positif sur la performance des équipes et améliorer les interactions sociales.
Robbie Dee
7
Vous avez tout à fait raison. Demander est le début. Et, comprendre qu'il existe un faux consensus est bénéfique pour la compréhension. C'est pourquoi j'ai "répondu" à la question au lieu de simplement l'ignorer.
mawcsco
7

différences entre l'écriture d'un grand logiciel C ++ et sa compréhension en tant que nouvelle recrue

Ce n'est pas la même chose que la différence entre un logiciel de lecture et d'écriture. Lorsque vous êtes nouveau dans un projet (et surtout lorsque vous êtes nouveau dans une entreprise), vous avez beaucoup plus à apprendre que ce que fait le code. Pour comprendre pourquoi le code fait ce qu'il fait, il faut souvent comprendre comment fonctionne l'entreprise et comment le projet est lié au reste de l'organisation. En bref, la lecture de code sans bénéficier de connaissances de base est une tâche plus lente et plus difficile que la lecture de code lorsque vous comprenez parfaitement le contexte dans lequel le code fonctionne.

Il y a une différence entre écrire du nouveau code sur un projet entièrement nouveau et lire et modifier le code existant, mais je ne dirais pas que l'un est nécessairement plus facile que l'autre, juste différent. Lorsque vous créez quelque chose de nouveau, vous n'avez pas à vous soucier de la façon de faire fonctionner votre code avec ce qui existe déjà, mais vous devez vous soucier de rendre votre projet suffisamment extensible et adaptable pour qu'il reste utile à l'avenir . Lorsque vous travaillez sur un projet existant, vous pouvez souvent utiliser ce qui existe déjà comme guide, mais vous devez d'abord comprendre ce qui s'y trouve.

En tant que «nouvelle recrue», il est généralement préférable de travailler sur un projet existant en particulier parce qu'il vous aide à apprendre toutes les choses que vous ne savez pas: comment fonctionne l'entreprise, comment les différents projets fonctionnent ensemble, les normes et pratiques de codage, et même (en particulier) ce qui pourrait être amélioré.

Caleb
la source
Comprendre l'étendue / la profondeur du système et de l'API sous-jacente avec de l'expérience. Quels sont les composants logiques du système? Comment ces composants interagissent-ils entre eux? Quels mécanismes utilisent-ils des blocs de construction sous-jacents? Comment les blocs de construction sous-jacents se comportent-ils dans différents chemins? Quels sont les contraintes / objectifs du système? Pourquoi certaines voies ont-elles été choisies par rapport à d'autres candidats? Si vous devez ajouter un nouveau composant, que pourriez-vous réutiliser et que devez-vous ajouter à nouveau? Pouvez-vous voir de «l'intérieur du système»? Un super livre pour voir la pensée et l'apprentissage pragmatiques.
GuruM
Construire un «prototype» ou un «jouet cassé» (avec des déficiences connues et uniquement pour explorer des alternatives) aiderait à «se forcer» à réfléchir aux questions ci-dessus. L'ajout de composants et l'ajout de fonctionnalités suivis d'une refactorisation aideraient à se faire une idée des problèmes à résoudre et des solutions candidates (via la recherche sur le forum peut-être).
GuruM
4

C'est une question intéressante, mais j'aurais tendance à pencher vers le côté qui est plus facile à lire et à comprendre que pour le créer.

Si vous êtes un vétéran, un programmeur chevronné, alors vous êtes susceptible de lire le code et de dire "Ouais, bon choix, vérifiez, oh, j'aurais peut-être fait X au lieu de Y", etc. Vous pouvez modifier ou ajuster, mais ce serait gagner un temps immense sur l'écriture à partir de zéro (sauf s'il y a des raisons de le faire).

Si vous êtes un programmeur plus récent, alors "vous ne savez pas ce que vous ne savez pas", et donc vous allez devoir inventer / apprendre toutes les petites choses, et très probablement vous allez avoir des inefficacités dans le code. Cependant, vous développerez probablement une meilleure compréhension de la langue.

Mais dans ces deux cas, il sera plus facile de lire le code et de partir de là que de l'écrire complètement à partir de zéro.

JohnP
la source
2

La plupart des programmeurs trouvent plus facile de comprendre le code qu'ils ont écrit eux-mêmes par rapport au code écrit par d'autres personnes. Cela est dû à la fois à l'apprentissage ligne par ligne que vous avez mentionné, ainsi qu'à une question de style et de talent individuel. C'est pourquoi tant de réinventions de roues se produisent.

Cependant, c'est la vue des arbres. La vue de la forêt est qu'il est beaucoup plus facile de lire du code que de l'écrire à partir de zéro. Par exemple, est-il plus facile d'écrire un nouveau traitement de texte à partir de zéro, ou d'apprendre suffisamment une base de code existante pour apporter des améliorations?

Lorsque vous commencez à lire le code, vous pouvez penser à des milliards de façons de rendre le code plus facile à lire pour vous-même. Vous passez le premier tout en traçant le code, en essayant de comprendre la configuration du terrain, parfois dans une architecture complètement anathème à la façon dont vous aimeriez le faire. Mais même dans de très grandes bases de code, vous passerez peut-être 40 à 80 heures à faire tourner vos roues, par rapport aux centaines de milliers d'heures de travail déjà investies dans la création de cette application.

Karl Bielefeldt
la source
Pouvez-vous écrire du code sans le comprendre? Copiez peut-être.
JeffO
@JeffO Tout le temps - lol ...
Robbie Dee
1

La personne qui écrit le logiciel aura presque toujours la meilleure compréhension du programme simplement parce qu'elle connaît la logique et son processus de réflexion lors de son écriture.

Je ne pense pas que l'écriture de code puisse être comparée à la lecture de code en termes de facilité de compréhension. D'une part, la simple écriture d'un logiciel permet une meilleure compréhension de ce logiciel spécifique en raison de la connaissance du contexte associé à chaque section de code, bibliothèque utilisée, etc. Cependant, la lecture de code que d'autres ont écrit peut être difficile à comprendre en termes de le véritable logiciel, mais en termes de compréhension du langage, il peut fournir un aperçu des nouvelles façons de faire ou des utilisations d'une bibliothèque que vous n'auriez peut-être pas envisagé d'utiliser, ce qui peut vous faciliter la vie en écrivant du code.

En termes de construction de connaissances, je pense que la lecture de code et l'écriture de code sont très liées et à bien des égards s'appuient les unes sur les autres. L'expérience de l'écriture de code facilite la compréhension du code des autres, et la lecture du code vous permet d'avoir plus de facilité à écrire du code (grâce à de nouveaux concepts logiques, à l'utilisation de la bibliothèque, etc.).

StMotorSpark
la source
1

C'est quelque chose que j'ai personnellement ressenti comme allant de soi, mais je n'ai jamais été entièrement sûr que cela vaut pour la population de programmation dans son ensemble. Par exemple, j'ai connu des codeurs très talentueux qui, plutôt que de lire la documentation, peuvent volontiers parcourir le code des autres et le comprendre comme s'il était le leur.

Cela conduit à la question: est-ce important?

Si vous lisez le code, il est probable que vous apportiez un changement plutôt que de le réécrire. Même si vous le réécrivez, vous êtes susceptible de l'écrire dans une nouvelle langue / version et vous ne pouvez donc pas nécessairement créer le code de la même manière. Le point que je fais est qu'il n'est pas toujours nécessaire de comprendre tout le code tout le temps.

Tout cela étant vrai, les méthodologies de développement plus récentes, par exemple BDD , reconnaissent qu'il est important que la logique métier soit claire à partir du code plutôt que le code étant simplement un moyen de conduire la machine. Bien sûr, cela n'a rien de nouveau - le concept existe depuis le travail fondateur de Donald Knuth: Literate Programming .

Robbie Dee
la source
1

Je suis dans la réponse de StMotorSpark, ajoutant simplement:
Cela dépend de tant de facteurs que cela ne peut pas être une question oui ou non, par exemple:

  • Le code existant est-il bien documenté et bien écrit ou ressemble-t-il à un spaghetti sans aucun sens ni commentaire?
  • Est-ce une petite application avec des situations très rares qui vous coûte un temps infini pour trouver une solution, ou une application plus grande mais simple?
  • etc.
JoseTeixeira
la source
1
Très bons points; cependant, je dirais que cela dépend davantage de la personne. Par exemple, même s'il y a du code qui n'a presque pas de documentation, il peut toujours fournir des informations sous la forme "C'est bizarre, je me demande ce que c'est". Si quelqu'un veut vraiment apprendre, il trouvera quelque chose d'utile quelle que soit la taille du programme ou de la documentation. Dans cet esprit cependant, une bonne documentation et un code dont la taille n'est pas excessive aident considérablement.
StMotorSpark
1
Tout à fait d'accord, cela dépend aussi beaucoup de la personne. Notez simplement qu'en raison des exigences de notre travail, certains d'entre nous font beaucoup de développement à partir de zéro tandis que d'autres font beaucoup de maintenance. Cela perfectionnera inévitablement deux expertises différentes, peu importe si elles ont commencé toutes les deux avec la même façon de penser bien organisée, le même niveau de logique et de compréhension des spécificités linguistiques, ...
JoseTeixeira