it-swarm.dev

Pourquoi l'intelligence est-elle considérée comme nuisible dans la programmation par certaines personnes?

J'ai remarqué beaucoup de questions dernièrement concernant différentes techniques d'abstraction et des réponses disant que les techniques en question sont "trop intelligentes". Je pense qu'une partie de notre travail en tant que programmeurs consiste à déterminer les meilleures solutions aux problèmes que l'on nous demande de résoudre, et l'intelligence est utile pour ce faire.

Ma question est donc la suivante: les personnes qui pensent que certaines techniques d'abstraction sont trop intelligentes sont-elles opposées à l'intelligence en soi , ou y a-t-il une autre raison de l'objection?

EDIT: Ce combinateur d'analyseur est un exemple de ce que je considérerais comme du code intelligent. J'ai téléchargé ceci et l'ai regardé pendant environ une demi-heure. Puis j'ai franchi l'expansion macro sur papier et j'ai vu la lumière. Maintenant que je le comprends, il semble beaucoup plus élégant que le combinateur d'analyseur Haskell.

89
Larry Coleman

Les solutions simples sont meilleures pour la maintenance à long terme. Et ce n'est pas toujours une question de familiarité linguistique. Une ou plusieurs lignes complexes prennent du temps à comprendre même si vous êtes un expert dans la langue donnée. Vous ouvrez un fichier et commencez à lire: "ok, simple, simple, compris, oui, WTF?!" Votre cerveau s'immobilise et vous devez maintenant arrêter et déchiffrer une ligne compliquée. À moins qu'il n'y ait une raison mesurable et concrète à cette mise en œuvre, elle est "trop intelligente".

Comprendre ce qui se passe devient de plus en plus difficile à mesure que la complexité passe d'une méthode intelligente à une classe intelligente à un modèle intelligent. Outre les approches bien connues, vous devez comprendre le processus de réflexion qui a permis de créer une solution "intelligente", ce qui peut être assez difficile.

Cela dit, je déteste éviter un modèle (lorsque son utilisation est justifiée) simplement parce que quelqu'un pourrait ne pas le comprendre. C'est à nous, développeurs, de continuer à apprendre et si nous ne comprenons pas quelque chose, c'est une raison de l'apprendre, pas de l'éviter.

207
Adam Lear

Principe KISS

Restez simple, stupide. Les solutions intelligentes sont excellentes, mais souvent la solution simple la plus simple est la meilleure.

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

Brian Kernighan

102
Josh K

Les imbéciles ignorent la complexité; les pragmatistes en souffrent; les experts l'évitent; les génies l'enlèvent. - Alan Perlis

83
Martijn Verburg

La meilleure solution n'est pas toujours la solution la plus intelligente. Parfois, des solutions simples sont tout aussi bonnes.

Dans le logiciel, vous devez toujours penser en termes de maintenabilité. Si un morceau de code est trop intelligent pour quelqu'un qui va le maintenir, je dirais que l'intelligence n'en vaut pas la peine.

30
Geek

Pour citer Brian Kernighan:

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

26
peterchen

l'intelligence est un outil; en soi, il n'est pas nocif. Elle ne devient nuisible que dans un contexte où elle n'est pas nécessaire.

22
Steven A. Lowe

"Clever", lorsqu'il est appliqué au code, n'est presque toujours qu'un euphémisme pour "inutilement compliqué".

La lecture d'un code simple, clair et efficace est déjà assez difficile. Lire un code "intelligent", c'est comme recommencer la poésie latine.

La confusion vient du fait que "intelligent" en tant qu'attribut d'une personne a une signification complètement différente. Ce cas peut également être considéré comme un exemple de la raison pour laquelle la conception de logiciels pour de vraies personnes est difficile: parce qu'ils sont ambigus.

Et parce que certains programmeurs souffrent de comprendre les protocoles sociaux que la plupart des gens suivent, qui leur interdisent de dénoncer directement le code comme "inutilement compliqué", ils peuvent avoir du mal à différencier les deux significations du mot intelligent. Contrairement à ce que certains peuvent penser, je pense qu'en fin de compte, de meilleures "personnes personnes" (c'est-à-dire des personnes empathiques, introspectives et patientes) font de meilleurs développeurs. Parce qu'ils savent pour qui écrire.

16
fzwo

La plupart des gens se concentrent sur l'intelligence d'un aspect de "Le code nécessite trop de déchiffrement pour comprendre ce qu'il fait" et toutes les mauvaises choses qui vont avec, comme

  1. Personne d'autre ne peut le comprendre, encore moins le maintenir/le déboguer.
  2. La personne qui a écrit ne sait même pas ce qu'elle fait.
  3. Ce n'est peut-être pas si brillant au début
  4. etc....

Tous les bons points, mais il y a un autre aspect négatif de l'intelligence et c'est le vieux problème de l'ego. Cela provoque des problèmes dans le sens de

  1. Quelqu'un qui est trop "intelligent" pour utiliser les solutions de quelqu'un d'autre. Pourquoi chercher ce que les autres ont fait quand vous pouvez inventer votre propre façon d'écorcher le même chat?
  2. Quelqu'un qui pense avoir inventé la solution la plus cool à un problème refusera souvent de prendre la parole.
  3. Ne permettra à personne de modifier "leur" code même en cas de problèmes évidents ou si un changement trivial est nécessaire.
  4. À l'inverse, ils pensent qu'ils sont intelligents et doivent utiliser la "dernière" technique pour prouver à quel point ils sont intelligents, mais ne parviennent pas à le maîtriser dans des projets personnels ou dans un autre code de non-production avant de les intégrer dans les parties critiques de le système.

Nous sommes tous coupables de trop d'ego parfois, mais quand cela gêne l'équipe, c'est un problème.

9
MIA

Good Clever - rapport élevé entre les lignes de code intelligentes et les lignes de dans une alternative non intelligente. 20 lignes de code qui vous évitent d'écrire 20000 sont extrêmement bonnes. Good Clever consiste à vous épargner du travail.

Bad Clever - faible rapport entre les lignes de code écrites et les lignes de code enregistrées. Une ligne de code intelligent qui vous évite d'écrire cinq lignes de code est Bad Clever. Mauvais malin parle de "masturbation syntaxique".

Juste pour noter: Bad Clever n'est presque jamais appelé "Bad Clever"; il voyagera souvent sous les pseudonymes "beau", "élégant", "concis" ou "succinct".

8
user8865

Je dois m'interroger sur la définition de tout le monde de l'intelligent.

Personnellement, j'ai l'impression d'avoir été intelligent quand j'ai pris un problème dur et complexe et que je l'ai implémenté de manière très simple et directe, tout en maintenant un niveau d'efficacité acceptable.

tl; dr je me sens intelligent quand, lors d'une révision de code, mon critique dit "wow, c'était plus facile que je ne le pensais", contrairement à "wtf c'est tout ça .."

7
Avatar_Squadron

Parfois, j'ai été si intelligent que je me suis trompé.

6
John

Mis à part les réponses théoriques énumérées, cela est souvent utilisé dans un contexte trop intelligent pour tout le monde.

Passez entre une équipe à haut niveau de performance et une équipe de maintenance de niveau moyen pour voir les vraies différences dans ce qui est "trop ​​intelligent".

Laissant de côté les arguments théoriques, trop intelligent est souvent basé sur ce avec quoi les membres de l'équipe les moins qualifiés peuvent travailler raisonnablement, il est donc très relatif à l'environnement.

6
Bill

Performant, maintenable, rapide et bon marché sont les façons dont je mesure une solution. Je suppose que l'intelligence pourrait également faire partie d'une solution tant qu'elle n'affecte pas négativement ces qualités.

4
Heath Lilley

Si le code intelligent + le nombre de commentaires nécessaires pour le rendre compréhensible code <= code simple, alors je dis optez pour le code intelligent. À chaque fois.

Je pense que le problème se pose lorsque les personnes qui écrivent du "code intelligent" omettent délibérément de le commenter correctement, car ce n'est qu'en étant initialement incompréhensible que les générations futures qui le rencontreront devront passer du temps à "apprécier" à quel point il est intelligent.

3
thesunneversets

Je me souviens d'une citation que j'ai vue attribuée à de nombreuses personnes différentes, comme le sont souvent les bonnes citations.

Paraphraser:

Toute personne intelligente peut rendre le complexe simple, il faut du génie pour rendre le complexe simple.

Prendre une idée complexe et la simplifier pour qu'elle soit compréhensible montre l'habileté du constructeur, mais prendre une idée simple et la rendre complexe montre que le constructeur veut être considéré comme intelligent.

3
Pickle Pumper

À mon avis, l'intelligence en soi n'est pas un problème. Habituellement, nous pouvons faire des confusions sur le code "intelligent" (sans sarcasme) et "perspicace". Ce que je vois comme un problème, c'est le fait que généralement le code "intelligent" (avec sarcasme) contient des exigences implicites non visibles, ce qui rend plus difficile le débogage et la maintenance dans le temps.

Il existe plusieurs algorithmes connus qui sont intelligents. Quicksort en est un, OMI.

Le code "intelligent" (avec sarcasme) fait généralement des hypothèses sur les variables définies et les états du système qui sont virtuellement déconnectés du code "intelligent" (comme les fichiers ouverts précédemment, les connexions réseau, les bases de données, etc.).

La quantité de données que vous devez charger sur votre cerveau pour maintenir correctement un code "intelligent" est généralement trop importante pour avoir un bon rapport coût-bénéfice.

2
Machado

Si la solution "intelligente" est difficile à comprendre, elle ne doit pas être utilisée. Par exemple, si par des effets secondaires vous pouvez contracter un calcul complexe sur une seule ligne, c'est intelligent. Mais s'il faut une heure à quelqu'un d'autre pour comprendre ce que vous avez fait dans le monde, c'est trop intelligent.

2
Michael K

Je connais un gars; il est probablement la personne la plus brillante que j'aie jamais rencontrée. Il est certainement un codeur incroyable, probablement meilleur que je ne le serai jamais de toute ma vie en termes de côtelettes de programmation. Il écrit du code comme s'il tapait un document Word et peut inverser une liste liée comme vous ne le croiriez pas. Si vous voulez parler d'écrire du code sérieusement complexe, c'est votre homme et si je rencontre un problème incroyablement difficile, je me tourne toujours vers lui. Cependant, travailler sur un projet avec lui en équipe est atroce. Il est incapable de cibler directement le problème commercial et de lui apporter une solution logique, efficace et concise. Pour lui, une liste de code de 1000 lignes serait meilleure que 100. Au lieu d'utiliser les outils qui lui sont fournis via le IDE ou framework, il lancera son propre outil super-optimisé. C'est tout va bien, sauf lorsque d'autres membres de l'équipe l'attendent pour terminer quelque chose, ou nous avons un délai.

Bien que j'admire sa capacité à faire ces choses complexes, j'ai besoin de quelqu'un qui puisse résoudre le problème et passer à autre chose. Ce n'est pas génial de dire ou d'admettre, mais parfois dans un environnement professionnel, le temps est tout et vous devez simplement résoudre le problème et continuer votre vie, vous pouvez toujours y revenir plus tard et refaçonner l'enfer pour l'améliorer votre code. Il y a une fine ligne entre être intelligent et aussi être une douleur dans le cul. Ma devise pour mon équipe est toujours, quelle est la chose la plus simple possible qui fonctionnera dans cette situation et ensuite partira de là. Parfois plus simple n'est pas toujours la réponse, mais c'est un bon bon point de départ.

1
Nodey The Node Guy

"Intelligent" dans ce contexte signifie "trop intelligent pour son propre bien", c'est-à-dire quelque chose qui fonctionne maintenant mais qui sera un cauchemar à comprendre et à changer plus tard.

Surtout si c'est une astuce qui exploite une caractéristique obscure du langage de programmation, ou utilise des effets secondaires étranges, ou est une façon vraiment bizarre de résoudre le problème dans le langage cible.

1
Andres F.

Parce que ce qui ressemble à intelligence pour un développeur dans un élan de créativité peut simplement passer comme mess et être juste un illisible, non maintenable bloc de énigmes obscures pour les autres.

Pourtant, un bloc d'énigmes agréable, intelligent et performant, mais si vous avez l'expérience, vous vous rendrez souvent compte que cela coûtera beaucoup plus à votre entreprise (pas à vous, le développeur) de maintenir cette chose sur le moyen- ou à long terme. Vous préférez donc calmer l'ardeur de vos collègues développeurs lorsqu'ils se font porter.

Sauf, bien sûr, s'il y a une justification à l'intelligence. Et s'il y a une bonne documentation qui accompagne la chose obscurcie que vous venez d'écrire. Vous avez commenté ce morceau de code intelligent, non? Expliquez son intention, pourquoi elle doit ressembler et comment elle se comporte?

S'il n'y a aucune justification, il s'agit probablement d'une optimisation prématurée, d'une ingénierie excessive ou d'un problème de type YAGNI. S'il faut 15 niveaux d'indirection pour faire quelque chose de simple, il y a de fortes chances que vous tombiez également dans les catégories précédentes. Et si ce n'est pas documenté, c'est juste un problème.

Un bon code ne devrait pas obliger le responsable à être à 100% tout le temps pour le comprendre. Un bon code est intelligent. Un bon code peut être presque aussi efficace, mais meilleur à bien d'autres égards. Un bon code ne devrait pas nécessiter un IDE avec 15 vues pour suivre la conception de votre application.

Remarque: hé, j'ai écrit quelques trucs que je pensais être intelligents mais qui ont attiré WTF? De - sinon de mes co-développeurs - de la bouche de mon manager. Je dois le regarder de leur point de vue.

1
haylem

J'ai tendance à être intelligent, mais je m'efforce d'être élégant.

Développer du code maintenant que les autres n'essaieront pas d'éviter plus tard.

1
kevpie

Le "code intelligent" est tout code pour lequel le programmeur a dû réfléchir sérieusement ou utiliser des compétences avancées pour l'écrire. Le problème avec cela ne tient pas compte de la nécessité d'une certaine "marge d'intelligence", mieux exprimée par Brian W. Kernighan:

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

1
Alex

C'est ma compréhension du problème, basée sur mon expérience et les autres réponses:

  1. Un code qui a pris de l'écriture mais qui est lisible et maintenable n'est pas considéré comme nuisible. Cependant, la plupart des développeurs n'appelleraient pas ce type de code "intelligent"; ils peuvent utiliser un terme différent comme "élégant". Il peut y avoir ou non un débat sur l'existence d'un tel code.
  2. Le code de production qui nécessite beaucoup de temps et d'efforts pour être compris même par un développeur chevronné connaissant le langage est "intelligent" et considéré comme nuisible par tout le monde.
  3. Le code de production qui nécessite beaucoup de temps et d'efforts de la part de développeurs inexpérimentés est considéré comme nuisible par certains. J'ai vu des réponses de toute façon, et j'ai travaillé avec des développeurs qui ont dit explicitement qu'ils préféreraient garder tout "le plus petit dénominateur commun".
1
Larry Coleman

Habituellement, lorsque vous devez être "intelligent", vous pouvez contourner un problème de code. Si c'est une solution de contournement et pas très simple, vous obtiendrez beaucoup de visages confus ou d'autres effets secondaires étranges lorsque vous assumez certaines conditions (qui peuvent être correctes à 100% au moment de l'écriture du code)

Ainsi intelligent == déroutant == mauvais :( Mais c'est aussi génial car je les ai utilisés pour des solutions pratiques à des problèmes limités.

0
user2528

Je préfère les solutions simples, j'aime vraiment la manière Ruby. Lorsque vous voulez par exemple additionner les 2 premiers éléments de la liste. Vous coupez d'abord la liste pour qu'elle ait la taille = 2 et ensuite vous résumer.

Je me souviens qu'une fois j'ai utilisé 1 liste au lieu de 3 et créé une grande fonction qui était très difficile à maintenir/à modifier.

dans le monde d'aujourd'hui, nous n'avons pas à sacrifier la clarté du code pour les performances (sauf c ++, ils n'ont pas à le faire, mais ils le feront).

0
IAdapter

Nouvelle cotation pour le contexte et une compréhension plus facile:

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

Ce que Brian Kernighan a écrit ici se réfère évidemment à la convolution, et il a utilisé à tort le mot intelligent.

"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 alambiqué que possible, vous n'êtes, par définition, pas assez intelligent pour le déboguer."

Convolution:

A thing that is complex and difficult to follow.

Intelligent:

Showing intelligence or skill; ingenious

Les programmeurs avertis savent qu'un code simple est ingénieux. Un code aussi intelligent que possible devrait être simple par définition. Les programmeurs instruits éviteront également de travailler avec et d'écrire du code alambiqué comme la peste. Ils transformeront également le code alambiqué en code intelligent chaque fois qu'ils en auront l'occasion. Le code commence généralement alambiqué et s'approche de l'intelligence, car la connaissance du domaine et la compréhension des capacités cognitives humaines dans la programmation sont mieux comprises grâce à l'expérience et au partage des connaissances.

En raison de la popularité de cette citation et du fait que Brian Kernighan est très populaire dans l'industrie, cette mauvaise utilisation de la Parole a un impact social négatif et j'aimerais honnêtement que cela soit traité par l'homme lui-même. Avant d'écrire cet article, j'ai essayé de voir si je pouvais simplement lui envoyer un e-mail, mais je n'ai trouvé aucune information de contact par e-mail que j'ai comprise :(.

L'impact social négatif que j'ai vu est que d'autres programmeurs ostracisent leurs pairs les plus intelligents, car ils voient maintenant l'intelligence comme un problème. Le vrai problème, ce sont les pairs stupides qui pensent qu'ils sont intelligents en faisant les choses d'une nouvelle manière unidiomatique, et en inventant constamment de nouvelles choses quand il n'y a aucun avantage au lieu de gagner et de comprendre la communauté dans son ensemble et de réutiliser autant que possible des idées intelligentes.

Je dois cependant préciser que souvent il est plus difficile de comprendre que de créer le vôtre. En raison du problème commun dans l'industrie pour les délais irréalistes, inventer le vôtre pour votre problème de niche plus petit sera utilisé pour gagner du temps. Ceci est basé sur l'observation que les choses utiles et réutilisables ciblent généralement une niche plus grande, ou fournissent une abstraction utile pour l'invention. Il est également basé sur le fait que les gens ciblent de grandes niches pour gagner plus d'argent, alors que souvent cela rend l'outil extrêmement difficile à utiliser en raison de la complexité de rendre quelque chose utilisable pour un large domaine d'applications.

L'autre impact social négatif est qu'il empêche le progrès et le désir de comprendre parce que dans notre monde égocentrique, nous serons immédiatement dans le déni de notre propre manque de compréhension et nous écrirons le code comme étant alambiqué même si, une fois comprise, l'idée est réellement Plutot malin.

TODO J'aimerais citer quelques références mais j'aimerais aussi que le manque de références n'entrave pas ma capacité à partager des informations donc je vais rapidement citer ce dont je me souviens comme les sources de mes informations et peut-être trouverai-je les informations réelles jour (ou vous pouvez le trouver pour moi! :)

  • Le discours de Guido Van Rossum sur les boucles d'événements et comment il en est venu à les comprendre
  • Un employé de GitHub qui a déclaré qu'il évitait d'embaucher des gens intelligents sur Y-Combinator
  • Une grande partie de la discussion et de l'apprentissage qui se déroule dans la communauté Python. La communauté Python est particulièrement critique à l'égard des nouvelles idées, mais ne rejette pas les nouvelles idées qu'elles font). ne comprends pas d'emblée, et vous pouvez généralement voir des fonctionnalités qui étaient d'abord considérées comme alambiquées voir la lumière du jour comme une fonctionnalité/un package de langage de base.
  • Ma propre expérience et mon opinion professionnelle basées sur mes observations de 10000 pieds. Cependant, je ne vois pas vraiment les détails à éclairer de tout en haut :( J'espère que votre expérience et votre observation vous diront la même chose et que quelqu'un d'autre pourra commenter ci-dessous pour donner à cette réponse un certain mérite.

N'hésitez pas à ajouter vos propres citations! N'hésitez pas non plus à ajouter des virgules à mon texte. Je n'ai pas actualisé ma connaissance de l'utilisation des virgules en anglais depuis un certain temps ...

0
Derek Litz