Je cherche un moyen efficace, qui ne se présente pas non plus comme une insulte, d'introduire des concepts de POO aux membres de l'équipe existants? Mes coéquipiers ne sont pas nouveaux dans les langues OO. Nous faisons du C ++ / C # depuis longtemps, donc la technologie elle-même est familière.
Cependant, je regarde autour de moi et sans effort majeur (principalement sous forme de revues de code), il semble que ce que nous produisons soit du code C qui se trouve à l'intérieur des classes. Il n'y a presque pas d'utilisation du principe de responsabilité unique, des abstractions ou des tentatives pour minimiser le couplage, pour n'en nommer que quelques-uns. J'ai vu des classes qui n'ont pas de constructeur mais qui mettent le memset à 0 chaque fois qu'elles sont instanciées.
Mais chaque fois que j'évoque la POO, tout le monde hoche toujours la tête et donne l'impression de savoir exactement de quoi je parle. Connaître les concepts est une bonne chose, mais nous (certains plus que d'autres) semblons avoir beaucoup de mal à les appliquer lorsqu'il s'agit de fournir un travail réel.
Les revues de code ont été très utiles, mais le problème avec les revues de code est qu'elles ne surviennent qu'après coup, donc pour certains, il semble que nous finissions par réécrire (c'est principalement une refactorisation, mais cela prend encore beaucoup de temps) du code qui vient d'être écrit. De plus, les revues de code ne donnent de feedback qu'à un ingénieur individuel, pas à toute l'équipe.
Je suis en train de jouer avec l'idée de faire une présentation (ou une série) et d'essayer de faire apparaître OOP à nouveau avec quelques exemples de code existant qui auraient pu être mieux écrits et pourraient être refactorisés. Je pourrais utiliser des projets vraiment anciens que personne ne possède plus, donc au moins cette partie ne devrait pas être un problème sensible. Cependant, cela fonctionnera-t-il? Comme je l'ai dit, la plupart des gens ont fait du C ++ depuis longtemps, donc je suppose que a) ils resteront là à penser pourquoi je leur dis des choses qu'ils connaissent déjà ou b) ils pourraient en fait le prendre comme une insulte parce que je suis leur dire qu'ils ne savent pas comment faire le travail qu'ils font depuis des années, voire des décennies.
Existe-t-il une autre approche qui toucherait un public plus large que ne le ferait une revue de code, mais en même temps ne se sentirait pas comme une conférence de punition?
Je ne suis pas un nouveau venu de l'université qui a des idéaux utopiques de code parfaitement conçu et je n'attends cela de personne. La raison pour laquelle j'écris ceci est parce que je viens de faire une revue d'une personne qui avait en fait un design de haut niveau décent sur papier. Cependant, si vous imaginez des classes: A -> B -> C -> D, dans le code B, C et D implémentent presque la même interface publique et B / C ont une fonction de ligne de sorte que la classe A la plus performante se comporte absolument tout le travail (jusqu'à la gestion de la mémoire, l'analyse des chaînes, les négociations de configuration ...) principalement en 4 méthodes mongo et, à toutes fins utiles, appelle presque directement en D.
Mise à jour: Je suis un responsable technique (6 mois dans ce rôle) et j'ai le soutien total du chef de groupe. Nous travaillons sur un produit très mature et les coûts de maintenance se font définitivement connaître.