Est-il acceptable d'utiliser la méta-programmation même si tous mes collègues ne la 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 à utiliser.
J'ai récemment déménagé à un nouvel emploi où je travaille dans une équipe plus grande et cela 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 (pas tous) de mes collègues perçoivent cela comme un risque (certains apprécient l'approche).
Je suis d'accord que c'est un problème d'écrire du code que personne d'autre dans l'équipe ne peut comprendre. D'un autre côté, nous sommes tous des développeurs C++ professionnels et je pense que nous devrions aspirer à un standard plus élevé que d'écrire du C avec des classes.
Ma question est, qui a raison, que dois-je faire?
Clarification: Essayer d'exploiter le plein potentiel du langage ne signifie pas que je lance TMP à chaque problème. C++ est une boîte à outils et pour moi, la compétence en 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 OK.
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 d'une manière plus lisible et maintenable. C'est aussi l'un des styles de programmation les plus difficiles à comprendre, il a donc vraiment besoin de gagner sa vie. Je l'aime quand je peux réduire 1000 lignes de code à 50, mais j'essaie de le limiter en tant que tel.
Le problème n'est pas la métaprogrammation, mais ceci:
D'un autre côté, nous sommes tous des développeurs C++ professionnels et je pense que nous devrions aspirer à un standard plus élevé que d'écrire du C avec des classes.
C'est là que vous avez des ennuis. Vous avez une opinion. C'est bien d'avoir une opinion que la métaprogrammation est bonne. C'est bien d'avoir une opinion que nous devrions tous aspirer à être de meilleurs développeurs C++.
Ce n'est pas bien d'obliger vos collègues et futurs employés qui devront maintenir le code que vous avez écrit pour être d'accord avec votre opinion. C'est le travail de ton patron. Votre patron est celui qui devrait se soucier de s'assurer que votre code est maintenable à long terme. Ils (espérons-le) ont beaucoup plus d'expérience en affaires, car croyez-moi quand je dis que c'est une décision commerciale, pas une décision idéologique.
C'est bien de vouloir métaprogrammer. C'est bien de vouloir apprendre aux autres à métaprogrammer. Mais comprenez qu'il est également bien que d'autres choisissent de ne pas apprendre à métaprogrammer, et cela sera vrai jusqu'à ce que vous soyez en position de pouvoir. (et, comme secret de l'industrie: lorsque vous êtes enfin développeur principal, en position de pouvoir, vous n'êtes pas du tout en position de pouvoir. Il y a quelqu'un qui contrôle les chaînes de poursuite qui est au pouvoir).
Si vous voulez les encourager à accepter la métaprogrammation, commencez petit. Commencez avec un seul enable_if qui facilite la lecture de l'API. Commentez ensuite la lumière du jour . Ensuite, trouvez peut-être un cas où une métafonction de modèle transforme 10 grandes classes répétitives en 1 classe avec 10 petits assistants. Commentez le diable hors de lui. Avoir un retour. Trouvez ce que les gens en pensent. Soyez bien s'ils vous disent de ne pas le faire. Trouvez un créneau où la métaprogrammation gagne si bien que vos collègues tous (à contrecœur) conviennent que c'était le bon outil pour le travail.
Pour résumer, j'ai écrit une belle bibliothèque une fois, en utilisant une métaprogrammation étendue. Il a fait exactement ce dont nous avions besoin à l'époque, alors qu'aucune autre approche ne pouvait se rapprocher à distance. Cela a en fait changé la direction de l'application dans laquelle j'écrivais. Mais c'était de la métaprogrammation. Seule une ou deux autres personnes dans toute mon entreprise pouvaient le lire.
Plus tard, mon collègue a essayé de nouveau le problème. Au lieu de tirer parti de la métaprogrammation pour précisément faire ce qui était nécessaire, il a travaillé avec le leadership 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 a pu le limiter à ce que la métaprogrammation fait le mieux.
La bibliothèque résultante est maintenant en mesure d'être utilisée sur un marché remarquablement large, et c'est certainement en grande partie dû au fait que le nouveau code peut être maintenu par un éventail beaucoup plus large 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 en utilisant certains éléments et constructions, faites-le; sinon, discutez-en avec eux et si vous ne pouvez pas les convaincre et montrez clairement pourquoi "votre approche" est clairement meilleure, vous ferez mieux de ne pas l'utiliser.
Notez que l'utilisation de la méta-programmation de modèle en C++ est toujours un compromis: bien sûr, cela peut parfois aider à concevoir certaines parties d'une application plus DRY, et il est certainement utile pour créer des bibliothèques très efficaces et hautement réutilisables.
D'un autre côté, ces avantages ont un certain coût: le code devient plus abstrait, souvent beaucoup plus difficile à lire, beaucoup plus difficile à déboguer et beaucoup plus difficile à entretenir. Cela rend l'utilité de la méta-programmation dans la programmation d'applications souvent discutable. Donc, en supposant que vous n'allez pas créer 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 réviseur pendant 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 plusieurs structures de code non triviales à la main;
- Utilisez la métaprogrammation du modèle 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 du modèle, effectuée correctement, sera probablement la plus lisible et la plus maintenable des trois options. C'est l'argument que je ferais à 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èles ( TMP ) pour éviter la répétition, vous devez l'utiliser pour construire des abstractions bien documentées et soigneusement testées qui localisent la complexité dans le Code TMP, facilitant l'écriture du code client correct. Il s'agit de la conception de la bibliothèque standard C++.
Je ne pense pas que nous puissions juger qui a raison ou tort sans voir un exemple du type de code que vous essayez d'écrire.
Les développeurs de logiciels devraient aspirer à écrire du 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 changements sont nécessaires. Si écrire "C avec des classes" y parvient, c'est très bien.
Et ce sont les normes par rapport auxquelles vous devez mesurer votre code. Surtout: 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?
n argument de compassion:
Votre travail donne-t-il du temps libre pour apprendre, ou en alternative, pouvez-vous convaincre vos patrons d'allouer quelques heures pour apprendre ces fonctionnalités linguistiques?
Sinon, leur utilisation leur donne essentiellement du travail non rémunéré supplémentaire. Vous pouvez penser qu'un programmeur C++ devrait connaître tout le langage, ou quelque chose comme ça, mais un point académique ne soulage pas le fardeau que vous leur imposerez. Vos collègues ont des enfants, des parents malades, des conjoints malades - ou l'enfer, juste une vie sociale raisonnable qui n'implique pas l'apprentissage du C++. L'adversaire le plus vocal de votre proposition peut être paresseux - ou il peut être minutieux et n'a pas besoin de merde supplémentaire dans sa vie pour le moment.
Le code doit être écrit en premier lieu pour être lu par les humains, et seulement accessoirement pour être analysé par le compilateur.
Maintenant, la chose à retenir à propos du TMP non trivial est que vous limitez le nombre de personnes qui peuvent lire ce code, cela peut être un compromis valide, mais je dirais que c'est beaucoup plus un compromis raisonnable dans les bibliothèques et tel où vous avez un petite équipe spécialisée d'experts alors c'est dans une plus grande application.
Lorsque vous retirez toutes les astuces du livre, vous imposez des coûts à tous les autres, car ils doivent maintenant comprendre la langue, y compris tous les cas juridiques que vous avez exploités, vous imposez également un coût d'embauche dans la mesure où vous avez élevé la barre de travailler sur l'application de manière utile, maintenant peut-être que ça vaut le coup, mais faites attention aux coûts ....
Pour moi, un peu plus de frappe, peut-être même une duplication de code, mais que je peux mettre devant Mr "C avec des classes plus STL" quand il a besoin de modification est beaucoup plus utile que quelque chose de TMP incroyablement élégant que moi seul peux maintenir (Et sera donc toujours à jour). Rappelez-vous également que le C avec des cours peut être l'expert en la matière, et que l'expertise est généralement beaucoup plus précieuse qu'être un avocat spécialisé en langues.
J'oublie qui l'a dit 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 intelligemment que possible, comment allez-vous le déboguer?".
Même si je peux vraiment écrire en C++ moderne, je préfère généralement ne pas le faire, cela signifie 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 d'ego. Vous pourriez être écrasé par un bus demain, donc quelqu'un doit pouvoir récupérer votre code et faire avancer la tâche en cours. Cependant, il est positif d'essayer de convaincre vos employeurs d'incorporer de nouvelles techniques dans 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 dont vous les avez résolus avec la méta-programmation. À moins que vous ne publiez du code ici, nous ne pouvons pas savoir si vous vous êtes livré à une complication inutile qui est amusante 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 le dernier, je vous encourage à continuer de le faire avec votre équipe. Toute bonne équipe doit faire des révisions de code significatives qui discutent non seulement des problèmes de style mais aussi de savoir si la solution du programmeur utilise la meilleure approche , utilise les fonctionnalités de langage appropriées, est maintenable et testable, etc. Votre solution de méta-programmation devrait remplir une telle session de révision, probablement tout un après-midi. Les programmeurs qui rejettent votre approche doivent présenter des alternatives (comme la génération de code avec Perl, la duplication de code, etc.) et montrer comment elle fonctionne par rapport aux critères mentionnés, par rapport à votre solution. Votre travail, en tant que leur "adversaire" amical dans l'argument, est de montrer que c'est un moyen de faire le travail rapidement, que la maintenance est facile, que les tests sont faciles et que le code est en fait lisible une fois passé l'obstacle de analyser la grammaire drôle. (Si vous êtes stratégique, vous pouvez le montrer à un ami au bureau à l'avance et le convaincre que c'est vraiment cool; cela vous aidera dans la discussion car vous ne serez pas seul.)
La plupart des programmeurs sont paresseux et apprécient les petites solutions élégantes. Si la vôtre en est une, il y a de fortes chances que vous puissiez les convaincre, surtout si les alternatives démontrées ne sont pas à la hauteur.
Il n'y a pas une seule bonne réponse à cette question.
Parce que la première chose que vous devez vous demander est: dans quelle situation êtes-vous placé par votre emploi? Certaines personnes sont en effet employées comme singes codeurs pour coder les spécifications, d'autres sont employées comme joueurs d'équipe, d'autres sont employées comme travailleurs du savoir ou experts.
Le seul résultat net constant est que vous devez le considérer du point de vue de votre employeur, car cela signifie essentiellement être un employé. Parfois, il est dans le meilleur intérêt de votre employeur d'encourager vos collègues à devenir meilleurs et à maîtriser les techniques avancées. Pourtant, dans une situation différente, vous pourriez simplement créer de nombreux problèmes et responsabilités et mettre en péril le succès des projets dans lesquels vous êtes impliqué.