Peut-on utiliser la méta-programmation même si tous mes collègues ne le comprennent pas?

102

J'utilise beaucoup de méta-programmation pour éviter les tâches répétitives et créer des abstractions plus sûres.

J'ai récemment changé de poste et je travaille dans une équipe plus nombreuse, ce qui inquiète certains de mes collègues car ils ne le comprennent pas.

J'essaie toujours d'exploiter tout le potentiel de la langue, mais certains de mes collègues (pas tous) y voient un risque (certains se félicitent de l'approche).

Je conviens que l'écriture de code que personne d'autre sur l'équipe ne peut comprendre est un problème. D'autre part, nous sommes tous des développeurs C ++ professionnels et je pense que nous devrions aspirer à un standard plus élevé que l'écriture de C avec des classes.

Ma question est la suivante: qui a raison, que dois-je faire?

Précision: Essayer d'exploiter tout le potentiel du langage ne signifie pas que je jette TMP sur tous les problèmes. C ++ est une boîte à outils et pour moi, la compétence C ++ consiste à pouvoir utiliser tous les outils de la boîte et à choisir le bon pour un travail particulier.

kamikaze
la source
38
Ceci est finalement basé sur l'opinion. Personnellement, j’ai pour règle de ne pas utiliser des fonctionnalités si complexes qu’elles soient accidentellement complètes - telles que la métaprogrammation de modèles C ++.
Kilian Foth
24
Les modèles @KilianFoth ne sont pas "accidentellement" complets. Ils ont toujours été destinés à être de puissants outils d'abstraction
Caleth
73
Un code que personne ne peut comprendre n'est pas un standard plus élevé.
Gburton
37
@ Caleth Herb Sutter les appelle accidentellement Turing-complete . Bien sûr, elles étaient censées être de puissantes fonctionnalités d'abstraction, mais je ne pense pas qu'elles aient été conçues pour permettre des constructions aussi obscures que possible, comme le permet la complétude de Turing. Et certainement, leur syntaxe n'était pas conçue pour rendre une telle métaprogrammation moins transparente que nécessaire.
gauche vers
26
Fausse dichotomie. Vous pouvez programmer à un "niveau supérieur" et laisser le C avec des classes, embrasser le C ++ moderne, utiliser des modèles (par exemple, la STL) ainsi que const, pas de transtypage (), pas d'arithmétique de pointeur, sémantique de valeur, plein de bonté, sans en-tête ibnto TMP. Si vous ne voyez pas de jour entre C-with-classes et TMP, vous vous trompez.
Kate Gregory

Réponses:

185

La métaprogrammation est OK. Ce que vous essayez de faire n’est pas correct.

J'utilise la métaprogrammation tout le temps dans mon travail. C'est un outil puissant qui peut être utilisé pour faire beaucoup de choses de manière plus lisible et plus facile à gérer. C'est aussi l'un des plus difficiles à comprendre les styles de programmation, donc il doit vraiment gagner sa vie. J'aime ça quand je peux réduire 1000 lignes de code à 50, mais j'essaie de le limiter comme tel.

Le problème n'est pas la métaprogrammation, mais ceci:

D'autre part, nous sommes tous des développeurs C ++ professionnels et je pense que nous devrions aspirer à un standard plus élevé que l'écriture de C avec des classes.

C'est là que vous avez des problèmes. Vous avez une opinion C'est bien de penser que la métaprogrammation est bonne. C'est bien de penser que nous devrions tous aspirer à être de meilleurs développeurs C ++.

Il n’est pas convenable d’obliger vos collègues et vos futurs employés à conserver le code que vous avez écrit pour s’associer à votre opinion. C'est le travail de votre patron. Votre patron est celui qui devrait veiller à ce que votre code soit maintenable à long terme. Ils ont (espérons-le) plus d'expérience de travail, car croyez-moi quand je dis que c'est une décision professionnelle, pas une décision idéologique.

C'est bien de vouloir métaprogrammer. C'est bien de vouloir apprendre aux autres les métaprogrammes. Mais comprenez que c'est bien aussi que les autres choisissent de ne pas apprendre le métaprogramme, et ce sera vrai jusqu'à ce que vous soyez en position de pouvoir. (Et, en tant que secret de l'industrie: quand vous êtes enfin développeur principal, en position de pouvoir, vous n'êtes plus du tout en position de pouvoir. Il y a quelqu'un qui contrôle les poursuites qui est au pouvoir).

Si vous voulez les encourager à accepter la métaprogrammation, commencez petit . Commencez par un seul enable_ifqui facilite la lecture de l'API. Puis commentez les lumières du jour . Trouvez ensuite un cas où une métafonction de modèle transforme 10 grandes classes répétitives en 1 classe avec 10 petits assistants. Commenter le diable. Avoir un retour. Trouvez ce que les gens en pensent. Ça va si on vous dit de ne pas le faire. Trouvez un créneau où la métaprogrammation gagne tellement en profondeur que tous vos collègues sont d'accord (à contrecoeur) pour dire que c'était le bon outil pour le poste.

En bref, j’ai écrit une belle bibliothèque une fois, en utilisant une métaprogrammation poussée. Il a fait exactement ce dont nous avions besoin à l'époque, alors qu'aucune autre approche ne pouvait être rapprochée à distance. En fait, cela a changé l'orientation de l'application dans laquelle j'écrivais. Mais c'était de la métaprogrammation. Seules une ou deux personnes dans toute mon entreprise pouvaient le lire.

Plus tard, mon collègue s’est attaqué de nouveau au problème. Au lieu de tirer parti de la métaprogrammation pour faire précisément ce qui était nécessaire, il a travaillé avec les dirigeants pour assouplir les contraintes qui avaient été imposées au problème, de sorte que la métaprogrammation n'était pas nécessaire. Peut-être plus précisément, la métaprogrammation était moins nécessaire. Il était capable de s'en tenir à ce que la métaprogrammation fait de mieux.

La bibliothèque résultante est maintenant en mesure d’être utilisée sur un marché remarquablement vaste, ce qui est certainement dû en grande partie au fait que le nouveau code peut être maintenu par un plus grand nombre de développeurs. Je suis fier d'avoir ouvert la voie à la métaprogrammation, mais c'est le code de mon collègue qui va toucher un public plus large, et il y a de bonnes raisons à cela.

Cort Ammon
la source
72
Remplacez «métaprogrammation» par un autre style, technique, technologie, bibliothèque et la réponse est toujours bonne!
Andrejs
4
Votre patron est celui qui devrait veiller à ce que votre code soit maintenable à long terme. La plupart des patrons ne savent même pas ce qu'est la maintenabilité du code. Ils n'ont pratiquement aucune connaissance technique, je ne ferais donc pas confiance à leurs décisions qui ont plutôt un caractère politique.
t3chb0t
4
@ t3chb0t: Un patron expérimenté sait combien d'argent devrait être consacré au service client ( résolution de bugs et nouvelles fonctionnalités) et à la réduction de ce coût. La facilité de maintenance est l'outil le plus puissant à cette fin. Ce patron peut ne pas connaître les détails techniques, mais devrait être capable de constituer une équipe sur laquelle on peut faire confiance.
mouviciel
25
@DDrmmr J'ai donné le ton à quelqu'un qui pense que les programmeurs devraient utiliser la métaprogrammation pour relever le niveau. Je ne pense pas qu'il faille s'attendre à ce que les membres de l'équipe les moins qualifiés puissent le faire. Il devrait être indiqué aux endroits où l’ équipe peut la maintenir, et peut-être même plus fort, il devrait être utilisé aux endroits où l’équipe peut la maintenir sans vous . Sinon, on écrit soi-même un travail.
Cort Ammon
15
@ Joshua Ce que j'ai trouvé, c'est qu'il n'existe pas de "code qui n'a pas besoin de maintenance".
Cort Ammon
39

D'abord et avant tout, c'est le problème de l'équipe et vous devez le résoudre avec l'équipe. Si vous avez une sauvegarde de l'équipe pour la programmation utilisant certains éléments et certaines constructions, faites-le. sinon, discutez-en avec eux et si vous ne pouvez pas les convaincre et leur expliquer pourquoi "votre approche" est clairement préférable, vous feriez mieux de ne pas l'utiliser.

Notez que l'utilisation de la méta-programmation de modèles en C ++ est toujours un compromis: bien sûr, cela peut parfois aider à concevoir certaines parties d'une application plus sèches, et c'est certainement utile pour créer des bibliothèques hautement efficaces et hautement réutilisables.

D'un autre côté, ces avantages ont un coût: le code devient plus abstrait, souvent beaucoup plus difficile à lire, beaucoup plus difficile à déboguer et beaucoup plus difficile à maintenir. Cela rend souvent douteuse l’utilité de la méta-programmation dans la programmation d’applications. Donc, en supposant que vous ne créiez pas la prochaine STL, chaque fois que vous êtes tenté d’utiliser la méta-programmation, demandez-vous si ces inconvénients en valent vraiment la peine. Et si vous n'êtes pas sûr, discutez-en avec votre relecteur lors de la révision du code.

Doc Brown
la source
Je suis d'accord, mais en discuter avec QA avant de le mettre dans le code. Aucun sens dans la création de quelque chose qui sera rejeté.
Shawnhcorey
8
Que diriez-vous de: "Je suis d'accord. Mais ..." Le changer en "en" change complètement le sens. Il faut toujours discuter de quelque chose d'inhabituel avec l'AQ avant de passer du temps dessus. Vous avez déclaré que cette discussion devrait avoir lieu lors de la révision du code, une fois le temps écoulé.
Shawnhcorey
@shawnhcorey: bien sûr, si le "QA" de votre organisation est responsable des normes de codage. Cependant, il s’agit à mon humble avis d’un rôle d’assurance qualité - dans la plupart des organisations que je connais, le terme «assurance qualité» fait référence à un groupe de personnes qui assurent l’assurance qualité d’une manière opaque, ne sont pas responsables du choix des éléments d’un langage de programmation. être utilisé et qui pas. Ces personnes sont rarement suffisamment qualifiées en programmation pour discuter de tels détails.
Doc Brown
2
@shawnhcorey: c'est exactement ce que je veux dire, le rôle d'assurance qualité varie énormément d'une organisation à l'autre. Dans de nombreuses organisations, les responsables de l'assurance qualité n'ont aucune idée de la programmation. Ils ne sont donc probablement pas les mieux placés pour discuter d'un tel sujet.
Doc Brown
2
@shawnhcorey: eh bien, vous avez écrit "L'assurance de la qualité est un terme générique", mais vous avez un rôle et une responsabilité très spécifiques en matière d'assurance de la qualité. Cela me semble un peu contradictoire.
Doc Brown
18

Mon avis général: si vous avez le choix, comme c'est souvent le cas, entre les trois options suivantes:

  • Tapez de nombreuses structures de code non triviales répétitives à la main;
  • Utilisez la métaprogrammation de modèles C ++ pour automatiser la génération de code;
  • Utilisez un autre mécanisme de génération de code, tel que des macros ou un autre langage de programmation pour générer des fichiers source C ++

La métaprogrammation des modèles, effectuée correctement, sera probablement la plus lisible et la plus facile à gérer des trois. C'est l'argument que je présenterais à l'équipe si j'étais à votre place. Des exemples avec du code réel aideraient à les convaincre.

Lorsque vous utilisez la méta-programmation de modèle ( TMP ) pour éviter les répétitions, vous devez l'utiliser pour créer des abstractions bien documentées et soigneusement testées qui localisent la complexité dans le code TMP, facilitant ainsi l'écriture du code client correct. C'est la conception de la bibliothèque standard C ++.

Je ne pense pas que nous puissions déterminer qui a raison ou tort, sans voir un exemple du type de code que vous essayez d'écrire.

Brian
la source
2
Vous pouvez également utiliser copier + coller au lieu de le taper à la main ;-)
Paŭlo Ebermann
4
@ PaŭloEbermann: Zut non!
Josué
2
@ PaŭloEbermann, un magasin où je me trouvais a appelé cette approche, "bogue-marque-bogue, bogue-marque-fin, bogue de copie, bogue de copie, bogue de copie".
Kelly S. French
12

Les développeurs de logiciels doivent aspirer à écrire un code qui fonctionne, qui fonctionne évidemment, qui peut être testé, qui peut être révisé, qui peut être débogué et qui peut être adapté lorsque des modifications sont nécessaires. Si écrire «C avec classes» y parvient, alors tout va bien.

Et ce sont les normes avec lesquelles vous devriez mesurer votre code. En particulier: cela fonctionne-t-il évidemment, peut-il être testé, peut-il être revu, peut-il être débogué et peut-il être adapté en cas de besoin?

gnasher729
la source
9

Un argument de compassion:

Votre travail vous donne-t-il du temps libre pour apprendre ou, au lieu de cela, pouvez-vous convaincre vos chefs d’attribuer quelques heures à l’apprentissage de ces fonctionnalités linguistiques?

Dans le cas contraire, leur utilisation leur confère essentiellement un travail supplémentaire non rémunéré. Vous pensez peut-être qu'un programmeur C ++ devrait connaître tout le langage, ou quelque chose du genre, mais un point académique ne soulage pas le fardeau que vous allez leur imposer. Vos collègues ont des enfants, des parents malades, des conjoints malades - ou un enfer - une vie sociale raisonnable ne nécessitant pas l’apprentissage de C ++. Les adversaires les plus virulents de votre proposition peuvent être des fainéants - ou bien passer à la vitesse supérieure et ne pas avoir besoin de plus de merde dans leur vie pour le moment.

André Paramés
la source
8

Le code doit être écrit en premier lieu pour que les humains puissent le lire et, accessoirement, pour que le compilateur le parse.

Ce qu’il faut retenir du TMP non trivial, c’est que vous limitez le nombre de personnes capables de lire ce code. Cela peut être un compromis valable, mais j’arguerais que c’est beaucoup plus un compromis raisonnable entre bibliothèques et petite équipe d'experts spécialisés alors c'est dans une plus grande application.

Lorsque vous tirez toutes les ficelles du livre, vous imposez des coûts à tous les autres, car ils doivent maintenant comprendre la langue, y compris tous les cas concernant les avocats que vous avez exploités, vous imposez également un coût à l'embauche pour avoir relevé la barre. pour travailler sur l'application de manière utile, maintenant peut-être que ça en vaut la peine, mais il faut surveiller les coûts ...

Pour moi, un peu plus de dactylographie, peut-être même un peu de duplication de code, mais que je puisse mettre devant M. "C avec les classes plus STL" lorsqu'il est nécessaire de la modifier est beaucoup plus utile qu'un élément de TMP incroyablement élégant que je suis le seul à pouvoir maintenir (Et sera donc maintenir pour toujours). N'oubliez pas également que le type C avec classes est peut-être l'expert en la matière et que cette expertise est généralement beaucoup plus utile que d'être un juriste spécialiste des langues.

J'oublie qui a dit cela, mais "Tout le monde sait que le débogage est plus difficile que de l'écrire en premier lieu, donc si vous le programmez aussi habilement que possible, comment allez-vous le déboguer?".

Même si je peux écrire vraiment en C ++ moderne, je préfère ne pas le faire, cela veut dire que je dois faire moins de programmation de maintenance.

Dan Mills
la source
7

Non tu ne devrais pas. Vous êtes employé pour produire du code qui satisfait à une spécification. Ce code doit être maintenable et non un voyage égoïste. Vous pourriez être écrasé par un bus demain, alors quelqu'un doit pouvoir récupérer votre code et faire avancer la tâche à accomplir. Cependant, il est positif d'essayer de convaincre vos employeurs d'intégrer de nouvelles techniques à leurs normes de programmation.

Darryl SCOTT
la source
3
Vous êtes employé pour produire du code qui satisfait à une spécification. oui, mais vous oubliez cela aussi au meilleur de la connaissance .
t3chb0t
2

La seule façon de répondre à cette question dans son contexte est d'examiner les problèmes spécifiques et la manière spécifique de les résoudre avec la méta-programmation. Si vous ne postez pas le code ici, nous ne pouvons pas savoir si vous vous êtes livré à une complication inutile qui n’est amusant que pour vous seul à "résoudre" un problème inexistant; ou si vous avez utilisé toute la puissance de la langue pour écrire une solution simple et élégante, non disponible par d'autres moyens.

Si c'est ce dernier cas, je vous encourage à continuer à le faire avec votre équipe.Toute bonne équipe doit procéder à des révisions constructives du code, qui abordent non seulement les problèmes de style, mais également si la solution du programme utilise la meilleure approche, utilise les fonctionnalités de langage appropriées, est maintenable et testable, etc. Votre solution de méta-programmation doit remplir l'une de ces sessions, probablement une toute l'après-midi. Les programmeurs qui rejettent votre approche doivent présenter des alternatives (telles que la génération de code avec perl, la duplication de code, etc.) et montrer comment cela fonctionne par rapport aux critères mentionnés, par rapport à votre solution. Votre travail, en tant que leur "adversaire" amical dans la discussion, consiste à montrer que c’est un moyen d’accomplir le travail rapidement, que la maintenance est facile, que les tests sont simples et que le code est en fait lisible une fois que vous avez dépassé l’obstacle. analyser la grammaire drôle.

La plupart des programmeurs sont paresseux et apprécient les solutions élégantes et petites. Si le vôtre en est un, il y a de fortes chances que vous puissiez le convaincre, surtout si les solutions de rechange présentées sont insuffisantes.

Peter A. Schneider
la source
0

Il n'y a pas une seule réponse correcte à cette question.

Parce que la première chose que vous devriez vous poser est la suivante: dans quelle situation vous situez-vous? Certaines personnes sont effectivement employées comme des singes de code pour coder des spécifications, d’autres comme des joueurs d’équipe, d’autres comme des experts ou des travailleurs du savoir.

Le seul résultat final est que vous devez l'examiner du point de vue de votre employeur, car cela signifie essentiellement être un employé. Parfois, il est dans l'intérêt de votre employeur d'encourager vos collègues à devenir meilleurs et à maîtriser des techniques avancées. Cependant, dans une situation différente, vous risquez de créer beaucoup de problèmes et de responsabilités et de compromettre le succès des projets dans lesquels vous êtes impliqué.

Ichthyo
la source
-4

La question n'est pas vraiment de savoir si la méta-programmation est correcte ou non, mais plutôt de savoir s'il est correct d'être meilleur que les autres membres de l'équipe. Voici donc quelques points controversés sur la façon dont je le vois ...


J'ai récemment déménagé dans un nouvel emploi où je travaille dans une équipe plus grande et cette [méta-programmation] inquiète certains de mes collègues, car ils ne le comprennent pas.

Ils craignent que vous soyez mieux qu'eux. C'est bon. Vous allez être le nouvel expert. Vous venez de détruire leur monde de statu quo.


J'essaie toujours d'exploiter tout le potentiel de la langue, mais certains de mes collègues (pas tous) y voient un risque (certains se félicitent de l'approche).

Bien sûr, personne n'aime être aussi qualifié que quiconque et essaie donc de vous empêcher d'utiliser des techniques trop complexes pour eux. Ils ne peuvent pas le comprendre ou ne vont pas le faire, car ils se sentent en sécurité maintenant.


Je conviens que l'écriture de code que personne d'autre sur l'équipe ne peut comprendre est un problème.

Je ne. Je pense que cela montre votre expertise.


Ma question est la suivante: qui a raison, que dois-je faire?

Vous devriez utiliser toutes vos compétences pour écrire le meilleur code que vous puissiez écrire et ne pas regarder en arrière vers ceux qui ne le comprennent pas. Sinon, vous resterez coincé à leur niveau et ne serez qu'un codeur ordinaire. C'est une bonne chose d'être meilleur que les autres et s'efforcer d'être meilleur qu'eux. Vous ne gagnerez jamais de nouvelle expérience si vous n'essayez pas d'utiliser quelque chose de nouveau ou de faire les choses différemment.


Je sais que je vais avoir un vote négatif, mais voici à quoi ça ressemble. Ce n’est pas un crime d’être meilleur que les autres membres de l’équipe, ni d’utiliser ses compétences. C'est juste que tout le monde a peur de l'admettre ... parce qu'ils sont du côté des non-qualifiés et détestent le fait que le nouveau type puisse soudainement faire quelque chose qu'ils ne peuvent pas. S'ils étaient intelligents, ils vous demanderaient de l'aide et des conseils et ne critiqueraient pas votre code pour son incompréhensible.


MODIFIER

Il semble y avoir beaucoup de confusion sur cette question. Comme les commentaires le montrent, de nombreuses personnes pensent qu'il s'agit d'une lisibilité générale du code. Non ce n'est pas. Il s'agit de savoir si certaines fonctionnalités / constructions de langage doivent être interdites ou évitées car certains membres de l'équipe ne les comprennent pas.

Ma réponse est non . Ils ne devraient pas être interdits. Si vous voulez interdire quelque chose, comment feriez-vous cela? Vous devrez préparer une sorte de questionnaire pour savoir ce que les membres de votre équipe peuvent ou ne peuvent pas - ou plutôt ne veulent pas apprendre, car je pense que toutes les fonctionnalités de la langue sont utiles quelque part, il est donc toujours utile de les connaître et de les utiliser. Bien et plus vous en savez, meilleur est le code que vous pouvez écrire. Vous aurez également besoin d'une échelle pour définir les fonctionnalités débutantes, intermédiaires et avancées.

Pour montrer à quel point ces restrictions sont stupides, prenons un exemple très simple: vous allez être embauché en tant qu’ingénieur logiciel mais votre futur patron vous dit que vous ne serez pas autorisé à utiliser des do/whileboucles car il y a plusieurs l’équipe qui ne les a jamais utilisées auparavant et n’y va pas parce qu’elle a toujours utilisé des forboucles pour tout, donc elle trouve les do/whileboucles confuses.

Maintenant, vous pensez que c'est stupide et fou, n'est-ce pas? Mais il en va de même pour d'autres fonctionnalités. Certains peuvent les utiliser et d'autres ne veulent pas les apprendre.

Pourquoi devriez-vous produire du code pire si vous savez qu'il y a quelque chose qui vous permet de faire la même chose avec beaucoup moins d'effort tout en ayant pour résultat un code beaucoup plus lisible et robuste?

Et peu importe que vous utilisiez uniquement des fonctionnalités langagières de base ou avancées, vous pouvez utiliser l’une ou l’autre pour produire un code tout aussi incompréhensible et non maintenable, c’est donc un sujet totalement différent.

t3chb0t
la source
10
Cette réponse est horrible. La méta-programmation n'implique pas la suprématie et vice versa
polfosol
9
D'après mon expérience, tous ceux qui estiment avoir un niveau d'expertise nettement supérieur à celui du reste de leur équipe ont été victimes de l'effet Dunning-Kruger. Cela ne veut pas dire que certaines personnes ne sont pas beaucoup plus qualifiées que d'autres, ou que dans ce cas , le reste de l'équipe n'est pas incompétent en fait ... mais un véritable expert se concentrera toujours sur le code simple et la vue d'ensemble ingénierie (y compris la comptabilisation des effets d'équipe au fil du temps) plutôt que de simplement programmer des points de style.
Daniel Pryden
3
Écrire du code que les autres ne peuvent pas lire ne prouve pas que vous êtes meilleur qu'eux. Cela prouve que vous ne pouvez pas écrire de code lisible.
Stig Hemmer
3
@ StigHemmer, apparemment, vous n'avez pas compris la question et vous changez de sujet. Il ne s'agit pas de code non lisible, mais de code incompréhensible pour d'autres en raison de leur manque de connaissances.
t3chb0t
4
@ t3chb0t Mon point de vue était que ces deux sont la même chose.
Stig Hemmer