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.
Réponses:
Pourquoi ne développez-vous pas une courte formation aux principes SOLID et ne leur donnez-vous pas cette formation? Cela semble avoir très bien fonctionné pour moi dans mon organisation actuelle et je trouve que donner des formations courtes est vraiment amusant (pour toutes les personnes impliquées).
Quand j'ai donné ma formation, j'ai pris un peu de temps pour rechercher des "mauvais" exemples pathologiques dans le code existant (de divers projets), et les refactoriser dans la présentation, pas à pas, en utilisant les principes. Cela a démontré que
la source
Sur un projet, nous avons fait des revues de conception.
15 minutes. Au tableau blanc. Parlez de la conception avant de coder.
La partie la plus importante consiste à planifier l'examen de la conception avant tout travail de mise en œuvre.
Nous avons également eu des «critiques de conception», qui étaient un gros problème en sueur. Ils impliquaient de nombreux documents et une longue présentation. Ils étaient difficiles à planifier et étaient presque toujours repoussés jusqu'à ce que le codage ait commencé, réduisant leur valeur à zéro.
Des revues de conception informelles - avant le codage - aucune pression - aucune documentation - permettent de mieux discuter de la façon dont les responsabilités sont attribuées et de la façon dont les objets vont collaborer.
la source
Je suppose que vous êtes plus jeune que certains développeurs, mais plus haut dans la chaîne alimentaire.
Au risque d'être enterré dans les votes descendants, il se pourrait que les `` ingénieurs expérimentés '' fassent en fait la bonne chose - ou puisqu'il s'agit d'un produit mature qui peut exister depuis des décennies, ce qui était autrefois la bonne chose.
Le code plus ancien a généralement été optimisé pour s'exécuter rapidement sur le matériel de l'époque; cela signifie entre autres réduire les niveaux d'héritage et éviter les appels de fonction / méthode pour des opérations triviales.
Les compilateurs sont devenus beaucoup plus intelligents au fil des ans, donc tout ce qui était autrefois vrai ne l'est plus - par exemple, un compilateur peut choisir d'inclure une petite fonction.
Une voie à suivre serait peut-être d'adopter une approche différente - demandez aux développeurs d'expliquer comment / pourquoi leur méthode est meilleure que la théorie qui vous a été enseignée - et soyez sincère à ce sujet.
la source
Pousser pour des tests unitaires avec une couverture de 100% des branches de chaque méthode nouvelle / modifiée ne conduirait pas à minimiser le couplage entre les méthodes.
la source
Vous voudrez peut-être prendre le livre "Design Patterns" du Gang of Four. Ce n'est pas spécifique au C ++, donc vous ne critiquez pas ouvertement les connaissances C ++ de vos collègues lorsque vous vous y référez. Pourtant, en même temps, il aborde des sujets que vous jugez pertinents. En outre, le livre est largement accepté comme pertinent, de sorte qu'ils ne peuvent pas facilement le rejeter comme théorique ou peu pratique.
D'un autre côté, considérons que le C ++ n'est pas un pur langage OO, ni dans la conception ni dans la pratique. Toute l'histoire du constructeur / memset semble que vous devriez introduire RAII, qui n'est pas du tout une technique OO mais spécifique au C ++ (malheureusement - IDNet de .Net montre ce qui se passe lorsque RAII est une réflexion après coup). Les livres pertinents ici sont (Plus) C ++ efficace et (Plus) C ++ exceptionnel.
la source
But every time I bring up OOP, everyone always nods and makes it seem like they know exactly what I'm talking aboutetMy teammates are not new to OO languages, mais je peux voir à quel point c'est un peu vague, car ils peuvent simplement mentir au sujet de la connaissance de la POO lorsque OP leur en parle.