Conseils pour diffuser des pratiques orientées objet [fermé]

Je travaille pour une moyenne entreprise qui compte environ 250 développeurs. Malheureusement, beaucoup d'entre eux sont bloqués dans une manière de penser procédurale et certaines équipes fournissent constamment de grandes applications de script transactionnel , alors qu'en fait, l'application contient une logique riche. Ils ne parviennent pas non plus à gérer les dépendances de conception et se retrouvent avec des services qui dépendent d'un autre grand nombre de services (un bon exemple de Big Ball of Mud ).

Ma question est: pouvez-vous suggérer comment diffuser ce type de connaissances?

Je sais que la surface du problème est que ces applications ont une architecture et une conception médiocres. Un autre problème est que certains développeurs sont contre l'écriture de tout type de test.

Quelques choses que je fais pour changer cela (mais j'échoue ou le changement est trop petit)

• Présentations sur les principes de conception (SOLID, code propre, etc.).
• Ateliers sur TDD et BDD.
• Coaching d'équipes (cela inclut l'utilisation de sonar, findbugs, jdepend et d'autres outils).
• Conférences IDE & Refactoring.

Quelques choses que je pense faire à l'avenir (mais je crains qu'elles ne soient pas bonnes)

• Formez une équipe d'évangélistes OO, qui diffusent une façon de penser OO dans différentes équipes (ces personnes devraient changer d'équipe tous les quelques mois).
• Exécution de sessions de révision de conception, pour critiquer la conception et suggérer des améliorations (même si les améliorations ne sont pas effectuées en raison de contraintes de temps, je pense que cela pourrait être utile)

.

Quelque chose que j'ai trouvé avec les équipes que j'entraîne, c'est que dès que je les quitte, elles reviennent aux anciennes pratiques. Je sais que je ne passe pas beaucoup de temps avec eux, généralement juste un mois. Donc quoi que je fasse, ça ne colle pas.

Je suis désolé que cette question soit éclaboussée de frustration, mais l'alternative pour l'écrire était de me frapper la tête contre le mur jusqu'à ce que je m'évanouisse.

N'essayez pas de pousser la POO, cela ne fera qu'empirer les choses. Pas parce que la POO est une mauvaise idée en général: ce n'est pas le cas. Mais parce qu'il semble que celui qui est responsable de ce code de boule de poils n'a pas seulement les outils pour éviter ces problèmes, mais aussi l'expérience et, plus important encore, la motivation.

Les personnes qui souhaitent écrire du code propre le feront dans n'importe quel paradigme, que ce soit la POO, la procédure, la fonctionnalité, etc. Mais tous les programmeurs ne sont pas comme ça, et si vous poussez un outil de code propre sur des personnes qui ne le font pas comprendre le besoin, vous vous retrouverez avec ces outils abusés tout comme les outils qui sont déjà là. Vous verrez des méthodes non liées regroupées dans une classe, des classes héritant de classes non liées, une visibilité des méthodes basée sur le débogage par essais et erreurs plutôt que sur une conception consciente, des méthodes statiques qui ne devraient pas être des méthodes statiques et non statiques qui devraient, en bref , vous perdrez votre temps.

Au lieu de cela, voyez si vous pouvez investir dans la prise de conscience pour la maintenabilité et l'élégance. Après tout, les objectifs principaux de la POO ne sont pas différents de toute autre stratégie de gestion de la complexité (c'est à cela que servent vraiment les paradigmes de programmation): encapsulation, modulation, couplage lâche, faible degré d'interdépendance, maintien de l'état mutable et de sa portée pour un minimum, etc. etc. La POO n'est certainement pas le seul paradigme qui vous donne les outils dont vous avez besoin pour y parvenir.

Ce qui m'amène au dernier point: la POO est une excellente idée, et elle fonctionne bien pour certains types de problèmes, mais (et je parle à la fois de ma propre expérience et en paraphrasant l'opinion de certains grands esprits ici) pour de nombreux types de problèmes, il est totalement inadapté. Lorsque vous êtes nouveau dans la POO et que le code spaghetti semi-procédural est la seule alternative que vous connaissez, la POO apparaît naturellement comme un cadeau du ciel (et d'une manière relative, c'est le cas), et vous êtes susceptible d'approcher tous les problèmes comme des clous pour votre marteau OOP. C'est tout à fait naturel, et conduire OOP à (et au-delà) ses limites un bon moyen de développer vos compétences OOP, donc ce n'est pas tout négatif. Mais peut-être (juste peut-être) cette base de code particulière n'a pas besoin de POO après tout. Peut-être qu'il bénéficierait beaucoup plus d'une architecture procédurale,

TL; DR: Si vous voulez évangéliser quoi que ce soit, que ce soit de bonnes pratiques de codage (indépendantes de la plate-forme), pas un paradigme ou une méthodologie particulière.

Vous ne pouvez faire changer personne qui ne veut pas déjà changer. C'est pourquoi les équipes que vous avez coachées sont revenues à leurs anciennes habitudes.

Alors vraiment, votre question devrait être "comment puis-je donner envie aux développeurs de passer aux approches OO?"

Commencez simplement, commencez petit, laissez les choses se construire à partir de là. Montrez les avantages au développeur individuel au lieu des avantages abstraits ou philosophiques au code, aux autres développeurs ou à l'entreprise.

Montrez comment les différentes techniques OO conduiront à moins code à écrire ainsi que des temps de développement plus rapides. Presque tous les développeurs écouteront une proposition qui leur facilitera la tâche.

Commencez ensuite à montrer comment les techniques OO conduiront à un code plus facile à gérer. Tout le monde dans ce type d'environnement vit dans la peur de faire " le changement " qui efface un tiers de la demande de production. L'encapsulation est la clé pour éviter ce risque et permet à chaque couche (future) de l'application de maintenir son contrat avec les autres couches.

Je voudrais voir comment les données sont transmises. Si c'est une longue liste de variables à chaque fois, envisagez d'envelopper certaines dans une structure (ou haleter! Une classe !!!) comme étape préliminaire. Envelopper simplement les données dans un objet est le début des contrats entre les couches.

À un niveau plus large - envisagez d'obtenir l'adhésion de la direction à cet effort si vous ne l'avez pas déjà fait. La direction doit voir les avantages concrets d'une diminution des défauts et des risques de modifications. Finalement, le processus de refactoring devrait conduire à des temps de développement plus rapides, mais c'est un avantage à long terme.

Vos idées d'équipes de révision et d'évangélistes OO sont bonnes. Il faut que ce soit plus que vous qui poussiez ce programme.

Mon expérience est que le passage d'un état d'esprit procédural à un état d'esprit OO est un gros obstacle. Cela nécessite de la persévérance que de nombreux développeurs ne parviennent pas à supporter. Ceci est principalement dû au fait que les fondamentaux d'OO sont passés en revue.

Formez une équipe d'évangélistes OO, qui diffusent une façon de penser OO dans différentes équipes (ces personnes devraient changer d'équipe tous les quelques mois).

est une bonne idée. Cela devrait être approfondi et OO devrait être discuté de fond en comble. Quand j'apprenais les anecdotes historiques OO, cela m'a beaucoup aidé.

Je suggérerais également,

• Puisque la motivation est la clé, motivez-les en détaillant comment OO peut améliorer leur travail, en particulier la maintenabilité du code.
• Examinez le code et montrez comment refactoriser l'application de la composition, de l'héritage, du polymorphisme et des motifs.
• Introduisez un bon processus comme SCRUM et engagez-y les développeurs.
• Rendre les livres de lecture comme «Refactoring» et «Refactoring to Patterns» obligatoires.

Je suis d'accord avec Shuvo Naser. C'est un gros obstacle, alors traitez-le plutôt comme une montée. Apprendre à concevoir une application entière à l'aide de la POO va prendre du temps.

1. Identifiez ceux qui comprennent la POO et rapprochez-les des chefs d'équipe, des formateurs, des concepteurs, des réviseurs de code, etc.
2. Utilisez un projet existant comme référence de formation. Peut-être que ceux en # 1 faisaient partie de cette équipe.
3. Refonte de certains projets existants. Cela peut aider certaines personnes à établir un pont entre leur code procédural et le code OO. Commencez par les bases. Ils doivent voir quand, où et pourquoi vous utilisez ces principes.
4. Faites-les participer à des séances de conception avec des gens qui savent ce qu'ils font.
5. Mettez-les dans des équipes de développement avec quelqu'un qui peut fournir des conseils de conception et assurez-vous que le projet respecte les principes d'OO (en supposant que la raison pour laquelle vous voulez le faire en premier lieu est parce que cela améliorera le développement.).

L'adoption précède rarement les avantages. Nous parlons de conception complexe et n'utilisons pas de feuilles de couverture de rapport TPS .

Vous avez déjà de bonnes idées

Les idées que vous décrivez dans votre question semblent excellentes. C'est une grande surprise que vous ne trouviez pas de succès. Nous sommes en 2012 et la révolution orientée objet est depuis longtemps passée de l'état de l'art à l'état de la pratique. Il semble qu'à moins d'avoir un taux de rotation très faible et très peu d'embauche, vous auriez du mal à ne pas obtenir plusieurs dizaines, voire une centaine de bons programmeurs orientés objets solides.

Agile ou orienté objet?

Vous mentionnez certaines technologies agiles comme TDD et certains concepts plus récents, alors ne soyez pas trop sévère avec les gens pour ne pas embrasser quelque chose qui est toujours activement combattu par certaines équipes de gestion. Certains prétendent embrasser Agile, mais quand ils en parlent, cela signifie ce qu'ils disent que cela signifie. L'organisation n'est pas caractérisée par des équipes qui prennent des décisions et s'adaptent, mais plutôt par un contrôle hiérarchique de type contrat fort.

Mais revenons à l'objet orienté. Vous ne mentionnez pas l'analyse ou la conception orientée objet, et je ne sais pas trop quel langage de programmation cède la place à quel langage de programmation orienté objet. Je sais que UML a des problèmes de popularité parmi de nombreux programmeurs orientés objet. Ayant une formation approfondie en OOAD, je pense que cela peut être comme apprendre la culture et l'histoire d'un pays dont vous voulez apprendre la langue naturelle. Par exemple, si je voulais apprendre le grec, je pourrais apprendre l'alphabet, le vocabulaire et la grammaire, mais si j'ignorais la riche histoire et la culture, je manquerais beaucoup. En tout cas, si vous apprenez tout sur un langage de programmation orienté objet, mais rien sur OOAD, je pense qu'une opportunité importante a été perdue.

Des problèmes à surmonter?

Pont trop loin? Si vous demandez aux gens d'apprendre une petite chose par semaine, en un an, parmi les gens qui participent, il y aura beaucoup de changements. Si vous leur demandez de changer tout ce qu'ils savent, cela sera bien accueilli par quelques-uns, difficile pour beaucoup et impossible pour d'autres. Certains changements comme le contrôle de code source sont localisés. Vous transitions de ne pas le faire avant, vous avez eu une formation qui ne mettait pas l'accent sur les limites de la mémoire, quelqu'un vous a guidé la première fois, puis le quotidien était assez facile.

D'autres changements sont omniprésents. Par exemple, le dumping de C et le passage à Java nécessitent une formation, une configuration et des changements importants dans la vie de tous les jours pour adopter un nouvel IDE, un nouveau compilateur, un nouveau langage, une nouvelle API, un nouveau modèle de déploiement, etc. des choses qui se produisent le plus souvent en conjonction avec un programme pilote ou une restructuration d’entreprise.

Mener une révolution? Si les personnes qui effectuent actuellement le travail ont des antécédents de récompense et que l'entreprise ne semble pas menacée d'échec, quelle est leur motivation pour le changement? Si vous semblez être un étranger qui veut indiquer la direction et les laisser responsables des résultats qu'ils ne peuvent pas prévoir, cela peut sembler être un risque, aucune récompense.

Positionner le leadership ou le leadership d'idées? De nombreuses organisations fonctionnent sur la base du pouvoir de position. Si vous manquez d'un soutien visible de la part des gestionnaires, des chefs de section, des directeurs et des vice-présidents, vous n'êtes qu'un leader d'idées. Certaines personnes sont dans la position dangereuse d'avoir une idée et de ne pas pouvoir en retenir une seconde. Si vous pouvez leur montrer au lieu de leur dire, cela fera beaucoup pour calmer les sceptiques et intéresser des alliés talentueux.

Base de support trop petite? Faites un tri parmi ces 250 personnes et triez-les en trois catégories: prêt à embrasser, disposé à apprendre et peu disposé à apprendre. Vous avez de bonnes raisons d'être frustré par certaines des personnes qui n'ont aucun intérêt à faire un changement. Vous pourriez aussi bien pousser sur une corde. C'est un effort inutile. Si vous savez qui soutient le changement, vous pouvez découvrir ce qui les intéresse.

Contrairement à un triage médical où le choix éthique et pratique est d'aider le groupe intermédiaire qui peut le faire avec de l'aide, vous pouvez investir votre énergie et votre temps en fonction de votre jugement et de vos préférences. Pour votre réussite, pourquoi ne pas cultiver le groupe qui est prêt à embrasser de nouvelles idées? Ils peuvent être peu nombreux en premier, mais comme une boule de neige, votre visibilité et votre crédibilité en tant que défenseur grandiront. Bientôt, les gens vous demanderont quand aura lieu la prochaine formation.

Dans le long terme? Jusqu'à ce que vous cultiviez un champion pour porter les choses après vous, vous devriez vous attendre à investir du temps dans l'établissement de relations. Vous devrez peut-être rester avec les équipes que vous entraînez pendant plus d'un mois. Jusqu'à ce que l'équipe possède des pratiques améliorées pour elle-même, vous n'êtes qu'un flic en technologie ou en méthodologie. Le mentorat est un processus qui peut prendre des années. Il y a beaucoup de choses que vos développeurs ne veulent pas faire que vous jugez importantes (vous avez spécifiquement mentionné les tests unitaires, je pense). Cela peut prendre un certain temps pour construire une vision partagée de la valeur que cela apporte. Je le sais par expérience, car j'ai déjà plaidé pour un outil de couverture de code dans une entreprise du Fortune 500 qui avait une grande réputation de qualité, mais les gestionnaires et les pairs se méfiaient de s'y engager.

Expert ou populaire? Bien plus rapidement que le mentorat, il s'agirait de favoriser le soutien local qui vient de chaque membre de l'équipe. En commençant par une équipe de dix spécialistes des logiciels, si j'avais le choix d'avoir une personne travaillant sur le processus tout le temps ou dix personnes travaillant sur le processus dix pour cent du temps, je choisirais la seconde. Le processus de base permet aux défenseurs de ressentir l'impact de l'approche et d'adapter l'approche pour résoudre au mieux les problèmes de l'équipe propriétaire du travail.

Voyez-vous la Freedom Line? Une partie de l'introduction des «meilleures pratiques» consiste à amener les gens à renoncer à une certaine liberté de faire les choses d'une manière commune. Renoncer à la discrétion du programmeur sera plus acceptable si vous recherchez des opportunités pour laisser de nombreux choix aux développeurs. Ce qu'ils choisissent est délimité de ce qui est mandaté par une partition que nous pouvons appeler la ligne de liberté. Il peut être nécessaire de créer des divisions similaires et bien justifiées concernant les pratiques organisationnelles, régionales / spécifiques au site, d'équipe et personnelles.

Cela aurait dû être un commentaire, mais comme je ne suis apparemment pas encore en mesure de commenter les choses, cela pourrait tout aussi bien être une réponse.

La chose la plus importante jamais réalisée dans ce genre de percées (que ce soit la POO ou tout autre changement de paradigme, par exemple, la programmation fonctionnelle ou tout ce qui sortira l'année prochaine) est FAIRE DES REVUES DE CODE ET UNE PROGRAMMATION PAR LES PAIRS . Accompagnez-les, initiez les équipes à une manière différente de faire des choses qui les aideront.

Mon chemin personnel vers la programmation orientée objet a commencé lorsque certains tests aléatoires de code m'ont châtié de faire des choses de manière modulaire et de conserver l'état sans aller complètement C ++ OO; pensez au code comme

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(notez que clients_total peut être entièrement redondant, étant un exemple particulièrement mal planifié)

Et j'ai fini par le faire seulement quand un collègue plus âgé vient de pointer mon écran et dit "regardez, si vous écrivez la même chose plus d'une fois, utilisez une procédure ou une fonction et appelez-la encore et encore".

Les discussions, les réunions et les pratiques optionnelles ne leur feront pas changer de paradigme ni introduire une nouvelle pratique, car il n'y a pas vraiment de motivation pour le faire en dehors de la pure curiosité. D'un autre côté, faire en sorte de ne pas le faire est une mauvaise chose ou tout simplement mal vu augmente le taux d'adoption très bien.

Soyez prêt pour le développement pleurnichard et axé sur la classe qui s'ensuivra jusqu'à ce qu'ils incorporent une conception appropriée dans ce qu'ils font. Vous verrez beaucoup de choses qui vous feront mourir un peu à l'intérieur, mais c'est à ça que ressemble le chemin vers l'apprentissage.