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

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.

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.

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.

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.

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?

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.

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.

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.

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.

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

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.