J'ai récemment remarqué beaucoup de questions concernant différentes techniques d'abstraction, et des réponses disant en gros que les techniques en question sont "trop ​​intelligentes". Je penserais qu'une partie de notre travail en tant que programmeurs consiste à déterminer les meilleures solutions aux problèmes qui nous sont confiés, et l'intelligence est utile pour le faire.

Ma question est donc la suivante: les personnes qui pensent que certaines techniques d’abstraction sont-elles trop intelligentes s’opposent-elles à l’habileté en soi , ou y at-il une autre raison à l’objection?

EDIT: Ce combinateur d’analyseur est un exemple de ce que je considérerais comme du code intelligent. Je l'ai téléchargé et l'ai examiné pendant environ une demi-heure. Ensuite, j’ai traversé 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.

Les solutions simples conviennent mieux pour la maintenance à long terme. Et ce n’est pas toujours une question de familiarité linguistique. Une ligne complexe (ou des lignes) prend 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'arrête brutalement et vous devez maintenant vous arrêter et déchiffrer une ligne compliquée. À moins d’une raison concrète et mesurable pour cette mise en œuvre, celle-ci est "trop ​​intelligente".

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

Cela dit, je déteste éviter un schéma (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 pour l'apprendre, et non pour l'éviter.

Principe du baiser

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

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

Brian Kernighan

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

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 le maintiendra, je dirais que l'intelligence n'en vaut pas la peine.

Pour citer Brian Kernighan:

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

l'intelligence est un outil; En soi, ce n'est pas dangereux. Cela ne devient nuisible que dans un contexte où cela n'est pas nécessaire.

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

Bien lire, du code clair et simple est déjà assez difficile. Lire du code "intelligent" revient à étudier de nouveau la poésie latine.

La confusion survient parce que "intelligent" en tant qu'attribut d'une personne a une signification complètement différente. Ce cas peut également être vu comme un exemple de la raison pour laquelle concevoir un logiciel pour des personnes réelles est difficile: parce qu’ils sont ambigus.

Et parce que certains programmeurs ont du mal à comprendre les protocoles sociaux suivis par la plupart des gens, qui leur interdisent de dénoncer directement le code comme "inutilement compliqué", ils peuvent avoir du mal à faire la différence entre les deux sens du mot intelligent . Contrairement à ce que certains pourraient penser, je pense qu’en fin de compte, de meilleurs "personnes, des personnes" (signifiant: des personnes qui ont de l’empathie, de l’introspection et de la patience) font de meilleurs développeurs. Parce qu'ils savent pour qui écrire.

La plupart des gens se concentrent sur l’intelligence du point de vue "Le code nécessite trop de déchiffrement pour comprendre ce qu’il fait" et toutes les choses négatives qui s’y rattachent, telles que

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 que ça 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'ingéniosité 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 de dépouiller le même chat?
2. Quelqu'un qui pense avoir inventé la solution la plus cool à un problème refusera souvent de prendre des entrées.
3. Ne laissez personne modifier le "code" même s'il y a des problèmes évidents ou qu'un changement anodin est nécessaire.
4. À l'inverse, ils pensent être intelligents et doivent utiliser la "dernière" technique pour prouver leur intelligence, mais ne parviennent pas à bien le gérer, que ce soit dans des projets personnels ou dans un code non productif, avant de l'intégrer à des parties critiques de le système.

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

Good Clever - ratio é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, c'est extrêmement bien. Good Clever consiste à vous sauver du travail.

Mauvais malin - faible ratio entre les lignes de code écrites en écriture par rapport aux lignes de code sauvegardées. Bad Clever est une ligne de code intelligente qui vous évite d'écrire cinq lignes de code. 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".

Je me pose des questions sur la définition de malin de chacun.

Personnellement, j’ai l’impression d’être habile lorsque j’ai pris un problème difficile et complexe et que je l’ai mis en œuvre de manière très simple et directe, tout en maintenant un niveau d’efficacité acceptable.

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

En plus des réponses théoriques énumérées, cela est souvent utilisé dans un contexte trop intelligent pour tous les autres.

Passez d’une équipe de maintenance de niveau intermédiaire à une équipe de maintenance de niveau intermédiaire pour voir les différences réelles de ce qui est "trop ​​intelligent".

En 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, donc il est très relatif à l'environnement.

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

Je mesure une solution de manière performante, maintenable, rapide et économique. Je suppose que malin pourrait également faire partie d'une solution, à condition que cela n'affecte pas négativement ces qualités.

Si le code intelligent + la quantité de commentaires requis pour le rendre compréhensible <= code simple, alors je dis aller pour le code intelligent. À chaque fois.

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

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

Paraphraser:

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

Prendre une idée complexe et la simplifier pour la rendre compréhensible montre l’intelligence du constructeur, mais prendre une idée simple et la rendre complexe montre que le constructeur veut être perçu comme intelligent.

Si la solution «intelligente» est difficile à déterminer, elle ne devrait pas être utilisée. Par exemple, si, à travers les effets secondaires, vous pouvez sous-traiter un calcul complexe à une ligne, c'est malin. Mais s'il faut une heure à quelqu'un pour comprendre ce que vous avez fait dans le monde, c'est trop intelligent.

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

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

Le code "intelligent" (avec sarcasme) suppose généralement que les variables en cours de définition et les états du système sont virtuellement déconnectés du code "intelligent" (fichiers ouverts précédemment, connexions réseau, bases de données, etc.).

La quantité de données que vous devez charger dans votre cerveau pour conserver correctement un code "intelligent" est généralement trop importante pour obtenir un bon rapport coûts / avantages.

"Code intelligent" désigne tout code pour lequel le programmeur doit réfléchir très sérieusement ou utiliser des compétences avancées pour l'écrire. Le problème avec cela, c'est qu'il ignore la nécessité d'une certaine "marge d'ingéniosité", que Brian W. Kernighan a bien exprimé:

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

Parce que ce qui semble être une intelligence pour un développeur dans un élan de créativité peut simplement passer pour un gâchis et être simplement un bloc illisible et incontrôlable d’ énigmes obscures pour les autres.

Malgré tout, c'est un bloc d'énigmes agréable, intelligent et performant, mais si vous avez de l'expérience, vous vous rendrez souvent compte que cela coûtera beaucoup plus cher à votre entreprise (pas à vous, le développeur) de la maintenir sur le même support. ou à long terme. Vous préférez donc calmer l'ardeur de vos collègues développeurs lorsqu'ils sont portés.

Sauf, bien sûr, s'il existe une justification pour l'ingéniosité. Et s’il ya une bonne documentation qui accompagne ce que vous venez d’écrire de manière obscurcie. Vous avez commenté cet astucieux code, n'est-ce pas? Expliquez son intention, pourquoi cela doit être, et comment il se comporte?

S'il n'y a aucune justification, c'est probablement simplement une optimisation prématurée, une sur-ingénierie ou un problème du type YAGNI. S'il faut 15 niveaux d'indirection pour faire quelque chose de simple, alors il est fort probable que vous tombiez également dans les catégories précédentes. Et si ce n'est pas documenté, alors ce ne sont que des ennuis.

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 dans de nombreux autres aspects. Un bon code ne devrait pas nécessiter un IDE avec 15 vues pour suivre la conception de votre application.

Note: hé, j'ai écrit quelques trucs que je pensais intelligents mais qui ont attiré WTF? sur - si pas mes co-développeurs '- la bouche de mon manager. Avoir à le regarder de leur point de vue.

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 .

C’est ce que je comprends du problème, sur la base de mon expérience et des autres réponses:

1. Un code qui prenait l'habitude d'écrire, mais qui en sort lisible et maintenable n'est pas considéré comme nuisible. Cependant, la plupart des développeurs n’appelleraient pas ce type de code "malin"; ils peuvent utiliser un terme différent comme "élégant". Il peut y avoir ou non un débat quant à savoir si un tel code existe.
2. Un code de production qui nécessite beaucoup de temps et d’efforts pour être compris même par un développeur expérimenté et familiarisé avec 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 néfaste. J'ai vu des réponses dans les deux cas, et j'ai travaillé avec des développeurs qui ont explicitement déclaré qu'ils préféreraient conserver le "plus petit commun dénominateur".

Je connais un mec; il est probablement la personne la plus brillante que j'ai jamais rencontrée. Il est sans aucun doute un codeur incroyable, probablement meilleur que je ne le serai de toute ma vie en termes de programmation. Il écrit du code comme s'il tapait un document Word et peut inverser une liste chaînée comme vous ne le croyez pas. Si vous voulez parler d'écrire un code très 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 une tâche pénible. Il est incapable de cibler directement le problème de l'entreprise et de lui fournir une solution logique, efficace et concise. Pour lui, une liste de codes de 1000 lignes serait mieux que 100. Au lieu d'utiliser les outils qui lui sont fournis via l'IDE ou le framework, il va lancer son propre outil super optimisé.

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 le dire ou de l’admettre, mais parfois, dans une entreprise, le temps est compté et vous devez simplement résoudre le problème et poursuivre votre vie, vous pouvez toujours y revenir plus tard et le remanier pour vous améliorer. votre code. Il y a une ligne de démarcation entre être intelligent et être pénible. Ma devise pour mon équipe est toujours, quelle est la chose la plus simple possible qui fonctionnera dans cette situation et partira de là. Parfois, la solution n'est pas toujours simple, mais c'est un sacré bon point de départ.

"Clever" 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 s'il s'agit d'une astuce qui exploite une fonction obscure du langage de programmation, utilise des effets secondaires étranges, ou constitue un moyen vraiment bizarre de résoudre le problème dans la langue cible.

Je préfère les solutions simples, j'aime beaucoup le style rubis. Lorsque vous voulez par exemple additionner les 2 premiers éléments de la liste. Tout d’abord, vous coupez la liste pour qu’elle ait la taille = 2, puis vous l’ajoutez.

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

Dans le monde actuel, il n'est pas nécessaire de sacrifier la clarté du code pour la performance (sauf en c ++, ce n'est pas obligatoire, mais ce sera le cas).

Habituellement, lorsque vous devez être "intelligent", vous devez résoudre un problème de code. Si c'est une solution de contournement et pas très simple, alors vous aurez beaucoup de visages confus ou d’autres effets secondaires étranges lorsqu’on suppose certaines conditions (ce qui peut être correct à 100% au moment de la rédaction du code).

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

Re-citer pour le contexte et et la compréhension plus facile:

"Le débogage est deux fois plus difficile que l'écriture du code. Par conséquent, si vous écrivez le code aussi intelligemment que possible, vous n'êtes pas assez intelligent, par définition, 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 l'écriture du code. Par conséquent, si vous écrivez le code aussi [convolué] 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 instruits savent que le 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 compliqué comme la peste. Ils transformeront également le code compliqué en code intelligent chaque fois qu'ils en auront l'occasion. Le code commence généralement de manière compliquée et aborde l'habileté à mesure que la connaissance du domaine et la compréhension de la capacité cognitive humaine dans la programmation sont mieux comprises à travers l'expérience et les connaissances partagées.

En raison de la popularité de cette citation et de la popularité assez répandue de Brian Kernighan dans l'industrie, cet emploi abusif du mot a un impact social négatif et j'aimerais sincèrement que l'homme lui-même s'en saisisse. Avant d’écrire cet article, j’ai essayé de voir si je pouvais simplement lui envoyer un courrier électronique, mais j’ai été incapable de trouver des informations de contact par courrier électronique que j’ai comprises :(.

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 être intelligents en faisant les choses d'une manière nouvelle et non inventive, et en inventant constamment de nouvelles choses quand il n'y a aucun avantage, au lieu d'acquérir et de comprendre la communauté en général et de réutiliser les idées intelligentes autant que possible.

J'ai besoin de préciser, cependant, qu'il est souvent plus difficile de comprendre que d'inventer la vôtre. En raison du problème courant rencontré par l'industrie en matière de délais irréalistes, inventer le vôtre pour résoudre votre petit problème de niche servira à gagner du temps. Ceci est basé sur l'observation que les objets 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 les grandes niches pour gagner plus d'argent, ce qui rend souvent l'outil extrêmement difficile à utiliser en raison de la complexité inhérente à la création d'un élément utilisable pour un large domaine d'applications.

L’autre impact social négatif est que cela empêche le progrès et le désir de comprendre parce que, dans notre monde égocentrique, nous allons immédiatement nier notre propre manque de compréhension et rayer le code de «compliqué» même si, une fois comprise, l’idée est en réalité Plutot malin.

TODO Je voudrais citer quelques références, mais je voudrais aussi le manque de références afin de ne pas entraver ma capacité à partager des informations. Je vais donc rapidement citer ce dont je me souviens en tant que sources de mes informations et peut-être trouver des informations jour (ou vous pouvez le trouver pour moi! :)

• Le discours de Guido Van Rossum sur les boucles d'événement et comment il en est venu à les comprendre
• Un employé de GitHub qui a déclaré qu'il évitait d'embaucher des personnes intelligentes sur Y-Combinator
• Une grande partie de la discussion et de l'apprentissage qui se passe dans la communauté Python. La communauté Python est particulièrement critique vis-à-vis des nouvelles idées, mais ne rejette pas les nouvelles idées qu’elles ne comprennent pas incidemment, et vous pouvez généralement voir des fonctionnalités considérées à l’origine comme alambiquées comme une caractéristique / un package linguistique principal.
• Ma propre expérience et mon opinion professionnelle basées sur mes observations de 10000 pieds. Cependant, je ne vois pas les détails pour éclairer de haut en bas :( J'espère que votre expérience et vos observations vous diront la même chose et que quelqu'un d'autre peut commenter ci-dessous pour donner un peu de mérite à cette réponse.

N'hésitez pas à ajouter vos propres citations! Aussi, n'hésitez pas à ajouter des virgules à mon texte. Je n'ai pas rafraîchi mes connaissances sur l'utilisation des virgules en anglais depuis un certain temps ...

Parce que souvent les gens ne connaissent pas une langue, des idiomes et des modèles. Ils pourraient prendre un livre et l'apprendre, mais ils ne le font pas. Et à cause de ces personnes, vous devriez écrire un code simple.

Ce n'est pas une intelligence. C'est une connaissance.

Je ne pouvais pas trouver le mot discipline mentionné nulle part ici, alors je vais donner mon avis. Je ne veux pas poster la réponse, mais je voudrais partager un aperçu différent sur le sujet, peut-être un que la question initiale n'avait pas en tête .

Un développeur intelligent est une bonne chose.

Cependant, avant l'habileté viennent d'autres traits. Comme vous l'avez peut-être compris, je parlerai de discipline . Un développeur intelligent et indiscipliné peut être très dommageable pour la maintenabilité à long terme du système.

Supposons qu'un bogue survienne ou qu'une nouvelle exigence entre en jeu. Un développeur intelligent pourrait bientôt se rendre compte que quelques correctifs locaux permettront d'accomplir le travail en 2 minutes. Si ce développeur est discipliné, il s'abstiendra d'appliquer ces correctifs au code source et trouvera à la place un moyen significatif de composer le comportement souhaité pour le système. Ainsi, lors de la prochaine modification des éléments de code, le responsable de la maintenance disposera de suffisamment de temps pour comprendre le code et implémenter les nouvelles modifications sans rien perdre. Sinon, vous obtenez l'image.