Est-il normal qu'un programmeur n'ait pas parfois une clarté à 100% sur son propre code? [fermé]

Je ne suis pas un programmeur expert, c'est peut-être la raison, mais j'ai remarqué que chaque fois que je crée du code complexe (comme un jeu d'échecs que j'ai fait récemment), je suis capable d'écrire le bon code pour faire fonctionner le programme, bien que je trouve cela plus tard - ou même quelques secondes après! - Je dois souvent faire une pause et réfléchir, comment cela fonctionne-t-il?

Non seulement cela, mais j'ai également tendance à ne pas penser au code, et au lieu de cela, je tape simplement. Par exemple, dans mon jeu d'échecs, j'ai décidé d'utiliser un tableau à cinq dimensions pour traiter les mouvements, et j'ai trouvé que je pouvais le faire sans trop réfléchir. Cependant, lorsque je me suis arrêté et l'ai relu, j'ai trouvé difficile de me familiariser avec tout le concept à cinq dimensions, et cela m'a pris quelques minutes pour bien comprendre ce que j'ai fait et comment le code lui-même fonctionne.

Est-il normal que les programmeurs qui écrivent du code complexe ne comprennent pas ce qu'ils font la moitié du temps?

Non, ce n'est pas normal ¹ . Au moins, ce n'est pas normal pour de bons programmeurs. Il est probablement normal que quelqu'un apprenne à programmer.

L'écriture de logiciels ne consiste pas seulement à regrouper des lignes de code jusqu'à ce qu'elles fonctionnent. Vous devez consciemment travailler à rendre le code facile à comprendre. Un programmeur que je respecte énormément m'a dit "le code est lu beaucoup plus de fois qu'il n'est écrit" . Bien que cela devrait être complètement évident, c'était un fait que je n'avais pas connu jusqu'à ce qu'il me le dise. Une grande partie de votre code n'est écrit qu'une seule fois, peut-être réécrit une ou deux fois de plus, mais vous finirez par lire le code souvent pendant la durée de vie du logiciel.

Si vous trouvez le code difficile à comprendre quelques minutes après l'avoir écrit, c'est un signal que votre code est trop complexe. Arrêtez d'ajouter du code et trouvez une meilleure façon. Par exemple, un tableau à cinq dimensions n'est presque jamais une bonne idée. Même les programmeurs vraiment très intelligents ont du mal à comprendre une structure de données aussi complexe.

Le même programmeur qui m'a parlé de la lisibilité du code a également dit "montrez-moi vos structures de données et je peux vous dire comment fonctionne votre code" . Cela signifie qu'un bon code commence par des structures de données propres et compréhensibles. Si vous concevez correctement vos données, le code est presque une préoccupation secondaire. Certes, cette affirmation est un peu hyperbole car le logiciel est évidemment plus que des données, mais il commence par des données. Donc, travaillez sur la création de structures de données propres et faciles à saisir et le code sera considérablement plus facile à comprendre.

¹ Il existe certainement du code très complexe et difficile à comprendre même par les programmeurs les plus intelligents. Certains problèmes sont intrinsèquement complexes. Cependant, j'oserais dire que la grande majorité du code écrit par la grande majorité des programmeurs n'est pas ce type de code.

Il y a deux sortes de ceci: 1.) confusion 2.) ignorance béat

Le premier est mauvais et peut disparaître avec le temps et l'expérience.

La seconde est bonne si les projets deviennent plus grands: si vous devez vous souvenir de chaque détail d'implémentation juste pour pouvoir travailler avec votre code, il y a quelque chose qui ne va pas (voir "masquage des informations").

Chaque développeur va oublier comment le code fonctionnait, alors il l'écrit de manière à ce qu'un autre nouveau développeur le comprenne et puisse le maintenir sans casser d'autres parties du programme qui lui sont également inconnues.

Donc «ne pas savoir» est en fait une constante dans le développement de logiciels - c'est juste comment ou si vous le gérez.

Je dirais que c'est plus courant que les gens ne veulent l'admettre. Même Brian Kernighan y a fait allusion:

Le débogage est deux fois plus difficile que d'écrire le code en premier lieu. Par conséquent, si vous écrivez le code aussi intelligemment que possible, vous n'êtes, par définition, pas assez intelligent pour le déboguer.

Lorsque nous conduisons au magasin, nous effectuons une séquence de réglages détaillés de la position des pédales et du volant. C'est très facile pour le moment. Maintenant, imaginez si vous avez enregistré ces ajustements sur du papier et les avez donnés à un ami qui avait besoin d'un itinéraire vers le magasin.

De même, nous aimons écrire du code à un niveau d'abstraction, mais nous aimons le lire dans plusieurs couches d'abstraction supérieures. Notre manière préférée d'écrire et de lire du code est donc en conflit. Cela signifie que rendre le code facile à lire est généralement une étape distincte et consciente, avec un ensemble différent de compétences.

Ce qui fait un bon programmeur, c'est quand ils ont du mal à lire ce qu'ils viennent d'écrire, ils créent une abstraction à ce point. Un meilleur programmeur fait cela plusieurs fois, devenant plus difficile à chaque fois. Finalement, les programmeurs expérimentés commencent plus loin dans le processus, mais ils peuvent souvent encore voir des améliorations à faire après avoir lu ce qu'ils viennent d'écrire.

Je pense que c'est quelque chose qui disparaîtra avec l'expérience.

Si vous écrivez des systèmes complexes, vous devez avoir la capacité d'écrire du code propre et maintenable que vous-même à l'avenir, et quelqu'un d'autre à l'avenir, pouvez comprendre. Donc, en substance, la chose que vous faites maintenant n'est pas évolutive.

Vous aurez beaucoup de moments où vous regardez du code que vous avez écrit il y a 6 mois et pensez "qu'est-ce qui se passe ici?", Mais si cela se produit un jour après avoir écrit le code, vous devez penser 'propre' code 'plus.

Source: jamais utilisé de tableau à 5 dimensions :)

"Normal" est très subjectif, donc je dis: c'est très courant, mais il faut éviter.

L'une des caractéristiques du «bon code» (j'ai entendu dire qu'une telle chose existe) est la clarté: elle devrait être aussi claire que les problèmes sous-jacents le permettent. Si le problème est complexe, le code serait également complexe, mais c'est une complexité inhérente , par opposition à une complexité accidentelle (j'ai entendu parler de cette distinction pour la première fois dans le discours de Rich Hickey ) introduite en utilisant ou en n'utilisant pas les bons outils, modèles, techniques et les pratiques.

Il y a des cas où le manque de clarté est acceptable même lorsque le problème n'est pas très complexe, par exemple si vous écrivez un site promotionnel dont vous savez qu'il durera aussi longtemps que la campagne de marketing se poursuivra. C'est un code jetable qui ne doit pas être maintenable. Pour d'autres (et la plupart des) cas, cela n'est pas acceptable, car le maintien d'un tel code coûtera cher. Pourtant, c'est courant.

En relation:

• Quand comprendre signifie réécrire - article sur le problème de la compréhension du code.
• ML efficace - une longue discussion sur, parmi ML / OCaml, comment écrire le code pour les "lecteurs" (c'est-à-dire les mainteneurs): "Privilégiez les lecteurs aux écrivains." Je recommande de regarder cela, peu importe la langue que vous utilisez.

Je ne pense pas que ce soit normal, mais pour des programmes très complexes, comme le programme d'échecs que vous mentionnez, je pense que c'est certainement possible.

Il y a de nombreuses années, alors que je venais juste de terminer mes études (donc j'étais encore relativement inexpérimenté pour écrire de gros programmes), j'ai écrit mon premier vrai compilateur. L'analyse a été simple, mais j'ai ensuite dû la cibler pour quatre jeux d'instructions de microprocesseur différents. J'avais l'intention d'écrire le compilateur dans son propre langage, j'ai donc d'abord utilisé uniquement les fonctionnalités du langage dont j'avais absolument besoin, j'ai écrit le premier générateur de code en langage assembleur et j'ai testé qu'il générait le code correct pour le sous-ensemble du langage. J'ai ensuite pu utiliser le compilateur pour se compiler à partir de là, et ajouter les fonctionnalités restantes et les utiliser également dans le compilateur lui-même

J'ai ensuite écrit les générateurs de code backend pour chaque microprocesseur et testé qu'ils généraient tous du code correct, mais bien que ce ne soit pas très optimal. J'ai donc commencé à écrire des optimiseurs pour chaque générateur de code.

Lorsque je testais la sortie des générateurs de code après avoir ajouté toute l'optimisation, j'ai été souvent surpris par le code généré par le compilateur. Ce n'était souvent pas la façon dont j'aurais écrit le code à la main, mais c'était correct et assez concis.

Quand il n'était pas évident pour moi comment le générateur de code a produit une partie du code qu'il a fait, j'ai essayé de suivre la logique à la main, mais il y avait des moments où je venais de renoncer. Si j'avais ajouté beaucoup de sortie de trace, j'aurais pu la suivre, mais je n'ai pas pris la peine car le code généré était satisfaisant et j'avais besoin de passer à d'autres projets.

Il y a beaucoup de réponses décentes ici.

J'ai quelques points de vue à ce sujet.

La première est que si vous ne comprenez pas pourquoi votre code semble fonctionner, alors a) il ne le fait probablement pas (il semble que cela ne fonctionne que probablement ), et b) soit vous n'avez pas assez bien compris le domaine problématique lorsque vous a commencé à coder ou n'a pas divisé le domaine problématique en unités plus petites et simplifiées avant de commencer.

Mon autre point de vue est que la vraie clé est d'utiliser des modèles et des conventions de bon sens dans votre code. C'est un sujet beaucoup plus vaste qu'un petit article ne peut aborder. Mais recherchez de la bonne littérature sur le sujet, y compris certains des anciens standbys comme les livres "Code Complete" et "Writing Solid Code".

Les détails de la mise en œuvre changent. La seule vraie constante est l'objectif fonctionnel du code. Si vous écrivez plus d'une fonction, vous allez oublier des détails d'implémentation précis et granulaires au fil du temps. Mais vous devez certainement comprendre comment les pièces fonctionnent lorsque vous les construisez, et vous devriez pouvoir dessiner un diagramme de l'ensemble et comprendre comment les pièces fonctionnent ensemble.

Si vous utilisez des modèles et suivez les conventions de bon sens, il sera beaucoup plus facile de sauvegarder les détails d'implémentation spécifiques lorsque vous examinerez à nouveau le code. Ou quand quelqu'un qui n'a jamais vu le code le regarde pour la première fois. En outre, le respect de ces conventions et modèles au fil du temps signifie que les détails d'implémentation se démarqueront des conventions et des modèles eux-mêmes, ce qui est un autre facteur qui rendra le code plus facile à comprendre.

La plupart des problèmes que nous abordons avec les logiciels sont par nature complexes. La conception de logiciels est un exercice de gestion de la complexité.

Je ne dirais pas que c'est normal , mais cela peut certainement arriver. Si cela vous arrive peu de temps après avoir écrit le morceau de code en question, je suppose que soit votre code est inutilement complexe et devrait être simplifié, soit vous êtes simplement facilement distrait. :)

Mais si vous rangez votre code, vous concentrez sur d'autres projets et y revenez après des semaines, des mois ou même des années, ce n'est pas vraiment une surprise que vous deviez tout comprendre à nouveau.

Mais vous pouvez faire quelque chose à ce sujet. D'après ce que vous dites, il semble que vous ne pensiez pas assez à votre code pendant que vous l'écrivez, et donc vous empêchez votre futur de comprendre ce qui se passe. Utilisez ces connaissances à votre avantage: c'est la meilleure motivation pour produire du code bien structuré, bien documenté et compréhensible. Vous savez par expérience directe ce qui se passe lorsque vous ne vous souciez pas de la qualité de votre code. Le savoir devrait faire de vous un meilleur programmeur à long terme. Lorsque vous collaborez sur des projets logiciels, vos collègues vous remercieront d'avoir produit un code compréhensible. Et le taux de défauts de votre code s'améliorera également.