meilleure façon de "introduire" OOP / Ood à l'équipe d'ingénieurs expérimentés C ++
Je cherche une manière efficace, cela ne se détache pas comme une insulte, d'introduire OOP concepts aux membres de l'équipe existants? Mes coéquipiers ne sont pas nouveaux à OO Langues. Nous avons fait C++/C # pendant une longue période, la technologie elle-même est familière.
Cependant, je regarde autour de moi et sans perfusion majeure d'efforts (principalement sous forme de critiques), il semble que nous produisons est C code qui se trouve être dans des classes. Il n'ya presque aucune utilité de principe de responsabilité unique, d'abstractions ou de tentatives de minimisation de couplage, juste pour en nommer quelques-uns. J'ai vu des cours qui n'ont pas de constructeur, mais obtiennent un memset à 0 chaque fois qu'ils sont instanciés.
Mais chaque fois que j'apporte OOP, tout le monde hoche la tête et le fait semblant de savoir exactement de quoi je parle. Connaître les concepts est bon, mais nous (un peu plus que d'autres) semblent avoir beaucoup de temps en les appliquer lorsqu'il s'agit de fournir des travaux réels.
Les critiques de code ont été très utiles, mais le problème des critiques de code est qu'ils ne se produisent qu'après le fait qu'à certains, il semble que nous finissions par réécrire (il se refactore surtout, mais prend encore beaucoup de temps) le code qui a été écrit. Aussi les commentaires des codes ne donnent que des commentaires à un ingénieur individuel, pas de l'ensemble de l'équipe.
Je joue avec l'idée de faire une présentation (ou une série) et j'essaie d'apporter OOP à nouveau avec quelques exemples de code existant qui aurait pu être écrit mieux et pourraient être refouts. Je pourrais utiliser des projets vraiment anciens que personne ne possède plus au moins cette partie ne devrait pas être une question sensible. Cependant, cela fonctionnera-t-il? Comme je l'ai dit que la plupart des gens ont fait C++ pendant longtemps, alors je suppose que ma devin ils vont rester assis là pensant pourquoi je leur dis des choses qu'ils savent déjà ou b) ils pourraient en faire une insulte comme une insulte parce que je leur dis qu'ils ne savent pas comment faire le travail qu'ils ont fait depuis des années sinon décennies.
Existe-t-il une autre approche qui atteindrait un auditoire plus large qu'un examen du code, mais en même temps ne se sentirait pas comme une conférence de punition?
Je ne suis pas un enfant frais hors du collège qui a des idéaux utopiques de code parfaitement conçu et je ne m'attends pas à cela de quelqu'un. La raison pour laquelle j'écris c'est parce que je viens de faire un examen d'une personne qui avait en réalité une conception de haut niveau décente sur papier. Toutefois, si vous photographiez des cours: A -> B -> C -> D, dans le code B, C et D Tout mettre en œuvre La même interface publique et B/C ont une fonction de doublure de sorte que la classe A se termine absolument Tout le travail (à la hauteur de la mémoire, analyse des chaînes, négociations de configuration ...) principalement dans 4 méthodes Mongo et, à toutes fins utiles, appelle presque directement dans D.
Mise à jour : Je suis un chef de technologie (6 mois dans ce rôle) et dispose d'un soutien total du gestionnaire de groupe. Nous travaillons sur des coûts de produits et de maintenance très matures sont définitivement laissés à être connus.
Pourquoi ne développez-vous pas une formation courte dans le [~ # ~ # ~] [~ # ~] Principes et donnez-leur cette formation? Il semble avoir très bien fonctionné pour moi dans mon organisation actuelle et je trouve que donner de courtes formations est en fait amusant (pour toutes les personnes impliquées).
Lorsque j'ai donné à ma formation, j'ai pris du temps pour rechercher des "mauvais" exemples pathologiques dans le code existant (de divers projets) et les ai refoutées dans la présentation, étape par étape, en utilisant les principes. Cela a démontré que
- Ce n'est pas si difficile de faire ces refactorings
- Ça ne prend pas longtemps
- Le résultat final (soigneusement choisi ;-)) est clairement meilleur que le code d'origine.
Les critiques ont été très utiles, mais le problème des critiques de code est qu'ils ne se produisent qu'après le fait.
Sur un projet, nous avons conçu des critiques.
15 minutes. Au tableau blanc. Parlez à travers la conception avant le codage.
La partie la plus importante est la programmation de la revue de conception avant à tout travail de mise en œuvre.
Nous avons également eu des "critiques critiques" qui étaient une grande affaire en sueur. Ils ont impliqué de nombreux documents et une longue présentation. Ils étaient difficiles à programmer et ont presque toujours été poussés jusqu'à ce que le codage ait commencé, réduisant sa valeur à zéro.
Critiques de conception informelle - Avant le codage - Aucune pression - aucune documentation - permet une meilleure discussion sur la manière dont les responsabilités sont assignées et comment les objets collaboreront.
Je suppose que vous êtes plus jeune que certains des développeurs, mais plus haut dans la chaîne alimentaire.
Au risque de se poursuivre dans les bowvotes, il se pourrait que les "ingénieurs expérimentés" font en réalité la bonne chose - ou comme il s'agit d'un produit mature qui pourrait être autour depuis des décennies, quelle était la bonne chose.
Le code plus ancien a tendance à avoir été optimisé pour fonctionner rapidement sur le matériel de l'époque; Entre autres choses, cela signifie réduire les niveaux d'héritage et éviter les appels de fonctions/méthodes à des opérations triviales.
Les compilateurs ont beaucoup plus intelligent au fil des ans, donc tout ce qui était une fois vrai maintenant est - par exemple, un compilateur peut choisir de faire connaître une petite fonction.
Un itinéraire 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 que vous avez apprise - et soyez sincère à ce sujet.
Entraînerait des tests d'unités avec une couverture de la branche à 100% de chaque neuf/modifiée la méthode ne permet pas de minimiser le couplage entre les méthodes.
Vous voudrez peut-être récupérer les "modèles de conception" du livre de quatre. Ce n'est pas spécifique à C++, de sorte que vous ne critiquez pas ouvertement vos connaissances de collègues C++ lorsque vous vous y référez. Pourtant, il s'agit en même temps que les sujets que vous considérez pertinents. En outre, le livre est largement accepté comme pertinent, afin qu'ils ne puissent pas le renvoyer facilement comme théorique ou impraticable.
D'autre part, considérons que c ++ n'est pas pur OO Langue, ni dans la conception ni en pratique. L'ensemble du constructeur/Memset Story sonne vous devriez introduire Raii, ce qui n'est pas un = OO Technique du tout mais spécifique à C++ (malheureusement -'s Idispose montre que ce qui se passe quand Raii est une réflexion après coup). Les livres pertinents ici sont (plus) C++ et (plus) exceptionnel C++.