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

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

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.

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.

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

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.

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.

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

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 .

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.