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.
la source
Réponses:
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.
la source
if FuncX() then return true, else return false
et ne voudront jamais que vous écriviezreturn FuncX()
. Je ne plaisante pas, j'ai littéralement eu cette conversation. Parce que les gens veulent quelque part accrocher leurs points d'arrêt, ou quelque chose du genre. :-)Principe du baiser
Restez simple, stupide. Les solutions intelligentes sont excellentes, mais souvent la solution la plus simple et directe est la meilleure.
Brian Kernighan
la source
Les imbéciles ignorent la complexité; les pragmatiques en souffrent; les experts l'évitent; les génies l'enlèvent. - Alan Perlis
la source
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.
la source
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. ”
la source
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.
la source
"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 source
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
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
Nous sommes tous coupables de trop d'ego parfois, mais quand ça gêne l'équipe, c'est un problème.
la source
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".
la source
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 ..."
la source
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.
la source
Parfois, j'ai été si intelligent que je me suis trompé.
la source
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.
la source
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.
la source
Je me souviens d'une citation que j'ai vue attribuée à de nombreuses personnes, comme le sont souvent les bonnes citations.
Paraphraser:
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.
la source
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.
la source
À 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.
la source
"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."
la source
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.
la source
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 .
la source
C’est ce que je comprends du problème, sur la base de mon expérience et des autres réponses:
la source
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.
la source
"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.
la source
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).
la source
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.
la source
Re-citer pour le contexte et et la compréhension plus facile:
Ce que Brian Kernighan a écrit ici se réfère évidemment à la convolution, et il a utilisé à tort le mot intelligent.
Convolution:
Intelligent:
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! :)
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 ...
la source
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.
la source
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.
la source