Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Méthodes et classes statiques (ou partagées) : Une règle du pouce

Publié par Olivier Dugas le lundi 7 juillet 2014 à 09:00

Avez-vous déjà lu ou même écrit des méthodes statiques dans un projet pour votre entreprise? Certains l'ont sûrement fait, puisqu'il nous arrive fréquemment d'en voir lorsque nous plongeons dans le code d'entreprises que nous visitons. La question du jour est : Croyez-vous que c'est une bonne pratique?

Avant de répondre à cette question, précisons que les méthodes statiques et partagées sont la même chose. "Static" est le terme employé par Java et C#.Net, alors que VB.Net utilise plutôt le terme "Shared". Par conséquent, les deux doivent être considérés comme interchangeable dans cette publication.

Voici ce que MSDN a à dire à propos des méthodes et classes partagées :

Utilisez une classe statique comme une unité d'organisation pour les méthodes qui ne sont associées à aucun objet particulier. Par ailleurs, une classe statique peut simplifier et accélérer votre implémentation, car vous n'êtes pas obligé de créer un objet pour appeler ses méthodes.

 

Voici un résumé des avantages que les gens nous disent régulièrement à propos des méthodes partagées :

  • Elles sont de bonnes assistantes dans des classes utilitaires
  • Elles sont plus concises à utiliser que le code qui crée une instance sans utilité par la suite dans la classe appelante
  • Elles sont efficaces pour de petits projets sans besoins architecturaux et sans maintenance future envisagée.
  • Il n'y a pas de raison de créer d'instance lorsqu'une classe n'a besoin d'aucun état.

Il y a des avantages évidents, mais de façon générale, nous ne recommandons pas son utilisation car les désavantages représentens une dette ne valant pas les bénéfices.

Polymorphisme

Supposons que nous avons une méthode partagée dans un utilitaire quelconque qui vit nonchalamment dans son coin. Soudainement, nous devons altérer légèrement la fonctionnalité. La plus grande partie de la fonctionnalité est la même, mais nous devons néanmoins changer quelques petites parti La technique normalement employée dans une situation comme celle-ci est de faire de l’héritage, mais il n’est pas possible de procéder ainsi avec les méthodes statiques.  Il n’y a pas de manière élégante de procéder ici, ce qui nous contraindrait d’ajouter une branche conditionnelle (un if). Cela provoquera l’augmentation de la complexité du code et, par extension, l’accumulation de la dette technique.

Le choix des noms

Oh, regardez, une méthode partagée très utile. Oh, en voilà une autre qui joue un rôle semblable, à peu de choses près. Rassemblons-les en une seule classe statique. Comment nommer cette classe? Je ne sais pas trop quel nom lui donner, mais les deux méthodes font des choses en lien à la validation de chaîne de requêtes HTML, alors je vais l'appeler "ValidationHelper"!

Les classes statiques tendent à être difficiles à nommer et, pour cette raison, elles finissent inévitablement par recevoir un nom avec un préfixe générique (tel que Validation) joint à une terminaison horrible comme "Helper", "Manager" ou "Utils". Sentez-vous la fumée? Voici une vision de l'avenir : "Tiens, j'ai créé une nouvelle méthode statique qui valide l'état d'une valeur envoyée sur le réseau. Je me demande où je pourrais bien déposer cette méthode..."

Parce que les éléments partagés sont difficiles à nommer, ceux-ci risquent fort de recevoir un nom générique. De nouvelles fonctionnalités s'y grefferont avec le temps. Ultimement, ces classes deviendront des amalgames de méthodes non reliées, et les paramètres optionnels (ou des méthodes au nom identique mais des paramètres différents) vont commencer à ramper dans les méthodes statiques qui s'y logent. Rappelons au passage qu’un mauvais nom mène souvent à une violation du SRP (Single Responsibility Principle).

Tests unitaires

Il peut être complexe d'écrire et de maintenir des tests unitaires de classes qui utilise des éléments statiques. Bien entendu, nous excluons les classes statiques comme Math, puisque ce sont des outils standards des langages. Rien ne sert de s'isoler des outils statiques d'un langage de programmation. Également, il y a parfois des cas où l’utilisation de classes statiques pour faire de la composition peut être intéressant. Et dans le cas de la composition, nous atteignons souvent mieux l’objectif de “documentation” par nos tests lorsqu’ils ne sont pas parfaitement unitaires. Par contre, nous ne devrions pas dépendre de classes statiques que nous (ou quelqu'un d'autre) pourrait possiblement changer un jour.

Il n'y a aucune manière élégante d'isoler une classe des méthodes statiques dont celle-ci fait usage. Puisque nous ne pouvons faire d'interfaces implémentées par des classes statiques, vous ne pouvez pas les remplacer par des mocks. Également, imaginez que cette classe statique crée et utilise trois classes et appelle l'interface graphique ou la base de donnée. Un simple test unitaire ne pourra être rapide, ne sera pas unitaire et risque d'échouer aléatoirement en fonction de l'orientation du vent. Par la bande, nous vous invitons à lire l'article du blog de Martin Fowler au sujet des tests non-déterministes.

États globaux

Si vous devez absolument avoir des classes partagées dans vos projets (évitez cette situation autant que possible), assurez vous au moins de ne pas maintenir d'attributs partagés à l'intérieur de cette classe. Cela signifie que vous avez des variables globales, ce qui est un véritable cauchemar à déboguer. Et ne vous en faites pas, vous aurez à déboguer, puisque vous n'avez pas de filet de sécurité fait de tests unitaires mais aussi parce que la complexité augmente exponentiellement avec les états globaux. De surcroît, le couplage induit par cette situation tue votre architecture telle un coup de tronçonneuse dans la colonne vertébrale de votre projet. Et avez-vous déjà souhaités porter votre application dans un nuage (Cloud Computing)? Où même d'espérer une meilleure performance de votre système? Il serait bien plus simple de dépôser cette tâche dans la liste des choses-impossibles-à-faire, car les états globaux empêche carrément la parallélisation. 

Une règle du pouce

Maintenant que nous avons vu comment les éléments statiques sont souvent source de bien des maux, comment faire pour s'en débarasser dans cet énorme projet d'entreprise? La classe statique est déjà utilisée par plus de 9000 classes...

Une possibilité est d'utiliser un singleton, mais sous une variante unitairement testable.Nous savons que les singletons présentent les mêmes problèmes que les méthodes statiques. Malgré cela, s'il est impossible de faire la transition vers une classe régulière en une seule bouchée, le singleton testable est une option correcte. 

Une alternative que nous jugeons plus intéressante serait de créer une classe non-statique Adapter qui se charge de transférer les appels aux méthodes statiques. Progressivement, vous pouvez modifier les utilisateurs des méthodes statiques pour qu'ils utilisent plutôt cet Adapter. Il sera ainsi possible de créer un mock de ce dernier dans les tests pour les rendre unitaires. Ultimement, lorsque seule la classe Wrapper fera les appels vers les méthodes statiques, vous pourrez supprimer les méthodes statiques et les réimplémenter dans la classe Adapter.

La tâche peut être lourde. Pour éviter d'échouer ou de se sentir décourager par le travail à faire, il est préférable d'y aller par petites itérations. Ne faites pas la modification en un élan pour ensuite essayer de refaire passer tous les tests qui échoueront. D'autres ont fait cette erreur avant vous.

Le changement organisationnel [Partie 2 / 2]

Publié par Olivier Dugas le mardi 13 mai 2014 à 15:09

À la partie 1 de cet article, nous avons avancé qu'un changement organisationnel n'était pas nécessairement durable. La grande question est donc de savoir comment arriver à rendre un changement organisationnel durable.

L'une des pistes de réponses se trouve dans le type de motivation choisi pour mener le changement. En effet, il faut ajouter à la motivation extrinsèque du personnel affecté une motivation intrinsèque, c.-à-d. une motivation liée aux valeurs véhiculées par les personnes. La motivation extrinsèque mise sur les aspects techniques et structurels d'un changement, ce qui est généralement véhiculé par les gestionnaires, les experts de ce changement, les agents de changement et les champions. La motivation intrinsèque, elle, mise plutôt sur les croyances, l'intégration du changement dans les valeurs et dans les comportements, ainsi que sur le niveau d'engagement des personnes affectées par le changement. Bien que les motivations extrinsèques soient importantes, un changement a bien peu de chance d'être durable sans les motivations intrinsèques.

Selon la théorie d'autodétermination, il faut amener à faire en sorte que le choix de l'agilité soit fait par les personnes affectées sans influence ni interférence externe. Curieusement, cette théorie se rapproche formidablement d'une conférence de Dan Pink. Selon ces théories et à notre avis, les différents éléments à viser afin d'augmenter la motivation intrinsèque sont l'autonomie, la maîtrise et le but.

  • Autonomie : Le désir de se diriger soit même.
  • La maîtrise (ou la quête de la compétence) : Le sentiment d'urgence à devenir meilleur à quelque chose.
  • Le but (ou l'appartenance psychologique) : Le pourquoi de l'entreprise, le pourquoi du changement, la vision de l'agilité. Ce qui donne envie à tout employé de participer à quelque chose de grand, un projet commun.
  • La satisfaction personnelle : Le niveau de bien-être dans l'entreprise en lien avec les objectifs de vie d'un employé.

Petite parenthèse, certaines compagnies, comme Amazon, Zappos et Netflix, paient leurs employés s'ils démissionnent afin de conserver ceux qui sont réellement motivés par la mission de l'entreprise.

Il faudrait, en tant que consultant, trouver un ou des champions à travers les équipes. Il faudrait orienter les manières de voir et de discuter de l'agilité en visant les valeurs mentionnées ci-haut.

Il faudrait également trouver une manière de capitaliser sur la victoire afin de la soutenir et de souligner les bons coups de chacun. Les champions devraient aussi être capable de faire ce travail lorsque le consultant n'est plus là. Il faudrait utiliser les victoires (petites ou grandes) pour répandre la motivation à d'autres équipes, puis à d'autres départements de l'entreprise. Batement et David (2002) l'ont d'ailleurs suggéré dans leur modèle des niveaux de durabilité d'améliorations.

Improvementsteps

Le changement organisationnel [Partie 1 / 2]

Publié par Olivier Dugas le jeudi 8 mai 2014 à 16:00

Je commence cet article avec une question : croyez-vous qu'un changement organisationnel soit durable?

Des recherches sur la durabilité des changements en entreprises indiquent que malgré le succès des initiatives de changements, il y a une variation considérable quant au niveau de durabilité atteinte. Alors que quelques-uns parviennent à conserver les gains obtenus suite à un changement organisationnel, la grande majorité des gains se sont inexorablement évaporés après quelques semaines, quelques mois, ou même quelques années (Kotter, 1995).

Ainsi, il est dangereux de croire qu'il suffit d'engager un consultant pour jouer le rôle d'agent de changement pour ensuite espérer que son expertise permettra au changement de s'ancrer dans la culture de l'entreprise. Afin de parvenir au succès d'un changement, il faut de la volonté et un engagement face à celui-ci.

Tout changement organisationnel se fait en trois phases :

  1. La décristallisation : Cette phase consiste en une reconnaissance du problème et en un diagnostic de la situation. Pendant cette phase, l'agent de changement ou les personnes qui collaborent avec lui doivent s'affairer à convaincre les gens plus réticents des avantages et de la nécessité du changement. Cela mène à un éveil, une prise de conscience quant à la cause du changement à apporter. À l'aide d'un agent de changement, les personnes affectées vont acquérir une motivation extrinsèque qui les mène à participer activement au changement.
  2. La transition : Lors de cette phase importante, les personnes désintègrent leurs façons de faire afin de reconstruire de nouvelles habitudes. C'est une étape cruciale, où l'agent de changement occupe une place importante.
  3. La recristallisation : Il s'agit de l'étape où le changement est intégré à la culture de l'entreprise, mais aussi aux valeurs des personnes affectées par le changement. Il faut ancrer le changement dans les habitudes de ces dernières.

Du point de vue du consultant et à titre d'agents de changement, nous sommes confrontés à ce défi dans de multiples entreprises, principalement en ce qui concerne l'agilité. Nous contribuons à la décristallisation d'anciennes façons de faire pour ensuite participer activement à la transition d'équipes vers les méthodes agiles. Enfin, nous devons, du moins en partie, participer activement à la phase de recristallisation afin de nous assurer que l'agilité fasse partie intégrante du quotidien des personnes au long terme.

Malheureusement, deux effets jouent en notre défaveur :

Effet d'Hawthorne : Les chercheurs ont remarqué que les personnes ont tendance à changer leurs comportements lorsqu'ils savent qu'ils sont étudiés. Lors de l'introduction d'une nouvelle pratique, par exemple, tout le monde observe, et tout le monde se sait observé. Cela entraîne un haut niveau d'excitation, de discipline et de motivation. Puis, alors que la nouveauté s'estompe et que les gens cessent d'observer ce qui se passe, le changement glisse et les gens retournent inexorablement vers les anciennes manières de faire.

Effet de la nouveauté : Les gens ont tendance à avoir un gain de motivation lors de l'acquisition de nouvelles techniques ou de nouveaux outils. Cependant, avec le temps, cette motivation tend à disparaître.

Batemen et David (2002) ont étudié le niveau de durabilité du changement en entreprise. Bien que leurs recherches indiquent que les interventions dans des cellules de travail mènent à des améliorations significatives, lorsque l'intervention se termine, il y a des variations considérables quant au niveau de durabilité du changement apporté. Certaines cellules parviennent à transformer le changement en un nouveau standard, alors que d'autres voient leurs gains évaporés très rapidement. D'ailleurs, selon Kotter (1995), 20% des changements tendent à disparaître complètement à l'intérieur de seulement deux années.

Improvementbyclass

Classesdescription

La grande question est donc de savoir comment arriver à rendre un changement organisationnel durable.

La suite à la partie 2!

  • Plus récents
  • 1
  • Plus anciens

Archive