Quels sont les obstacles à l'adoption des meilleures pratiques? Comment les surmonter? [fermé]

Nous avons tous vu (et la plupart d'entre nous ont écrit) beaucoup de code mal écrit. Pourquoi? Qu'est-ce qui nous fait adopter de mauvaises pratiques plutôt que de bonnes?

La réponse la plus évidente (pour moi) est "l'ignorance", mais je suis sûr que ce n'est pas la seule raison. Quels autres sont là? Que pouvons-nous faire pour surmonter la tentation d'écrire du mauvais code?

Résistance au changement.

C'est le principal moteur de l'ignorance, de la mauvaise gestion, etc.

Le chapitre 30 de Peopleware 2nd Edition est consacré à ce sujet. Et il cite un livre d'un autre consultant assez bien connu, écrit un peu plus tôt:

Et il faut considérer que rien n'est plus difficile à gérer, plus douteux de succès, ni plus dangereux à gérer, alors se mettre à la tête de l'introduction de nouvelles commandes. Car l'introducteur a tous ceux qui bénéficient des anciens ordres comme ennemis, et il a des défenseurs tièdes dans tous ceux qui pourraient bénéficier des nouveaux ordres.

Niccolo Machiavelli: Le Prince (1513)

DeMarco et Lister continuent à énoncer le mantra à garder à l'esprit avant de demander aux gens de changer:

La réponse fondamentale au changement n'est pas logique, mais émotionnelle.

Le processus de changement est rarement un passage direct et sans heurt des conditions sous-optimales actuelles au nouveau monde amélioré. Pour tout changement non trivial, il y a toujours une période de confusion et de chaos avant d'arriver au nouveau statu quo . Apprendre de nouveaux outils, processus et modes de pensée est difficile et prend du temps. Pendant cette période de transition, la productivité baisse, le moral souffre, les gens peuvent se plaindre et souhaiter si seulement il était possible de revenir aux bonnes vieilles façons de faire. Très souvent, ils le font, même avec tous les problèmes, car ils estiment que les bons vieux problèmes connus sont meilleurs que les nouveaux problèmes inconnus, frustrants et embarrassants. C'est la résistance qui doit être tactiquement et doucement, mais résolument vaincue pour réussir.

Avec patience et persévérance, l'équipe arrive finalement du Chaos à l'étape suivante, la pratique et l'intégration. Les gens, même s'ils ne sont pas complètement à l'aise avec les nouveaux outils / processus, commencent à s'y habituer. Il peut y avoir des expériences positives "Aha". Et progressivement, l'équipe atteint un nouveau statu quo.

Il est vraiment important de réaliser que le chaos fait partie intégrante et inévitable du processus de changement . Sans cette connaissance - et sa préparation -, on peut paniquer en franchissant la phase du Chaos et la confondre avec le nouveau statu quo. Par la suite, le processus de changement est abandonné et l'équipe revient à son état misérable précédent, mais avec encore moins d'espoir de toujours améliorer quoi que ce soit ...

Pour référence, les phases décrites ci-dessus ont été définies à l'origine dans le modèle de changement de Satir (nommé d'après Virginia Satir ).

Péter Török a raison, mais a omis un point important et optimiste:

• les gens peuvent aimer le changement auquel ils participent, mais ils n'aiment presque jamais le changement qui leur «arrive»

alors impliquez-les, laissez-les apporter des idées, laissez-les créer un enjeu, et ce ne sera pas si douloureux

Remarque: ceci est pertinent pour la programmation dans la mesure où de nombreux projets logiciels techniquement réussis échouent parce que les utilisateurs les rejettent .

Le temps semble être un grand moment où je travaille.

Par exemple, pourquoi adopter les tests unitaires lorsque vous devez écrire plus de code, et que cela prend donc plus de temps pour obtenir un produit libérable? Le client x le veut maintenant! Codez plus vite!

(Ce n'est évidemment pas bien fini)

Cela est également le résultat d'une mauvaise gestion et d'une mauvaise économie, ne facturant pas suffisamment aux clients pour se permettre de passer du temps à bien faire les choses.

Malgré les preuves massives du contraire, les gens sont généralement des créatures très rationnelles. La raison pour laquelle les gens n'adoptent pas les meilleures pratiques, comme TDD par exemple, c'est qu'ils ne pensent pas que cela en vaudra la peine. Soit ils pensent que les pratiques ne sont pas, en fait, les meilleures; et que cela leur coûtera en fait plus que cela ne les sauvera. Ou ils pensent que l'avantage est si marginal que le coût du changement l'emportera sur le petit avantage. L'essentiel est que le problème des meilleures pratiques est un problème de résultat.

Si vous voulez être un agent de changement, votre tâche consiste à démontrer que leur perception du résultat net est erronée. Vous devez montrer que la meilleure pratique est vraiment la meilleure. Que les avantages soient immédiats et importants . Vous devez montrer que la courbe d'apprentissage est suffisamment petite pour durer et qu'au moins certains des avantages commencent immédiatement.

Comment montrez-vous cela? En adoptant vous-même les meilleures pratiques! Rien ne sert à convaincre les autres mieux que votre propre comportement. Si vous suivez la meilleure pratique, et que vous en parlez , d'autres verront que vous avez fait l'analyse économique et pris la décision inverse. Cela les obligera à reconsidérer leur décision. Ils le feront en privé et ne l'admettront jamais au début. Mais tous ceux qui vous voient utiliser cette meilleure pratique réexamineront leur position.

C'est le mieux que vous puissiez espérer. Si la meilleure pratique est une meilleure pratique, le reste suivra automatiquement. Oh, ce ne sera pas rapide, et il y aura beaucoup de retards. La transition sera lente et inégale; et vous éprouverez de nombreuses déceptions. Mais la transition sera également inexorable et inévitable. Cela peut prendre une génération, mais la meilleure pratique l' emportera.

Pour preuve, demandez-vous quand vous avez vu quelqu'un pour la dernière fois utiliser goto.

C'est le résultat de ne pas savoir ou de penser que l'on connaît la méthode idéale. Les gens choisissent mal d'écrire du code; il s'agit plutôt de ne pas savoir mieux. « Naïveté », par opposition à « ignorance » serait un meilleur mot.

Le moyen le plus simple de se conformer aux bonnes pratiques consiste à reconnaître qu'il existe (très probablement) une meilleure façon d'écrire le code que vous venez d'écrire, puis à aspirer à apprendre ce qu'est cette `` meilleure façon ''.

Deux causes

• Ignorance.

• Arrogance.

Comment les surmonter?

• Des incitations.

Jusqu'à ce que les gestionnaires (c'est-à-dire les personnes achetant les compétences du développeur) aient besoin des meilleures pratiques dans le cadre de la livraison de logiciels, rien ne peut changer. De nombreuses organisations sont clairement schizophrènes: elles éduquent les développeurs dans diverses technologies et exigent ensuite des logiciels non testés ou une conception non testable. Ou pire.

La meilleure pratique pour moi est un logiciel écrit par une équipe de 8 personnes. Nous n'avions pas d'exigences écrites, de revues de code, de tests unitaires, de documents de version de format. Aucun test utilisateur final, rien de ce que tous les livres disent que nous aurions dû faire. Le code a été précipité, bogué et tout simplement impossible à maintenir. Il a été jeté 3 ans après sa sortie, c'était tellement mauvais. Alors, qu'est-ce qui était si génial Deux ans après la première libération, le propriétaire de l'entreprise (qui avait financé le développement d'une hypothèque sur sa propre maison) est reparti avec 30 à 40 millions de dollars dans sa poche arrière.

Nous perdons souvent de vue le fait que nous sommes (le plus souvent) ici pour créer des logiciels qui font de l'argent pour l'entreprise. Les entreprises n'existent pas pour nous donner l'occasion de développer des logiciels en utilisant les "meilleures pratiques", elles existent pour gagner de l'argent.

La plupart des pratiques de «meilleures pratiques» n'améliorent pas les bénéfices. Celles qui le sont, devraient et sont largement adoptées. C'est pourquoi la "meilleure pratique" n'est pas pratiquée.

Risque acceptable

Vous n'avez jamais pris de risque et joué sur quelque chose? Il y a un resserrement du temps, donc vous le faites fonctionner avec l'intention de le refactoriser plus tard (par opposition à le refactoriser plus tôt). C'est en fait considéré comme une bonne pratique pour certaines personnes.

Finalement, vous vous brûlez suffisamment de fois et vous changez de façon. Pensez à toutes les «meilleures pratiques» qui existent. Pouvez-vous tous les suivre tout le temps? Y en a-t-il qui se contredisent? Vous ne voulez pas perdre de temps à gérer chaque valeur aberrante.

Si j'écris du mauvais code qui fonctionne et que personne ne le regarde à nouveau, est-il toujours considéré comme mauvais? (S'il vous plaît, ne ruinons pas le débat philosophique en argumentant sur ce qu'est un «mauvais code».)

IME c'est une combinaison de ce que d'autres ont dit. Ignorance ("Je n'ai utilisé que des DataSets, pourquoi s'embêter avec ce truc LINQ?", Manque de temps ("Le Boss veut que ce soit fait le plus tôt possible, nous ne pouvons pas y consacrer beaucoup de temps"), manque de compréhension ("Qu'est-ce qui ne va pas avec l'écriture de tout mon code dans le code?") tous contribuent.

L'ironie que je vois est qu'une fois que vous commencez dans cette voie, vous vous embourbez plus profondément. Si vous coupez les coins ronds maintenant et jetez tout le code d'une application dans les fichiers ASPX, vous ne pourrez jamais y remédier plus tard; de nouvelles choses continueront à vous être lancées, ce qui signifie que vous devez les faire rapidement, ce qui signifie que vous devez simplement jeter tout le code dans le fichier ASPX (en jurant que vous le réparerez un jour), etc. etc. -en spirale car vous ne pouvez plus arrêter le développement et dire que les choses doivent être corrigées en premier.

Souvent, les développeurs n'ont tout simplement pas vu la meilleure pratique ou, plus important encore, les avantages de l'utilisation d'une meilleure pratique (je commence à cesser d'utiliser le terme «meilleures pratiques» pour diverses raisons).

Il existe une théorie selon laquelle les développeurs sont «délibérément paresseux». En d'autres termes, ils auront tendance à choisir la voie de moindre résistance.

Une fois que vous leur montrez rapidement les avantages d'une meilleure pratique (comme TDD, ou dites, en suivant les principes SOLIDES) et que cela leur permet en fait d'être un meilleur développeur (mais toujours `` paresseux ''), alors vous avez tendance à constater que la résistance fond une façon.

C'est une question d'éducation :)

(Manque de) Connaissances et compétences + Temps d'investissement

Je suis surpris que personne d'autre n'ait sorti celui-ci, mais c'est peut-être évident pour moi parce qu'une grande partie de mon travail a été en tant que programmeur singleton, sans personne (autre que la pile) à qui aller quand je lutte sur quelque chose. Je connais «de» meilleures techniques - telles que le TDD - mais trop souvent je ne les comprends pas assez bien pour les utiliser et j'ai du mal à trouver de bonnes informations pour m'aider à commencer à les utiliser. Encore une fois, en utilisant TDD comme exemple, je comprends sa signification de base - construire des tests qui affirment que votre code génère un résultat spécifique - mais l'implémenter?

Mis à part le fait que XCode a intégré des tests unitaires ces jours-ci, je ne sais pas par où commencer. Dois-je affirmer que la vue comporte des boutons X après avoir exécuté une routine pour les créer? Que diriez-vous d'affirmer que mes UIViews ont été réorganisées correctement après avoir appelé la balise de rotation?

Heck, comment puis-je même écrire un test unitaire dans XCode? C'est autre chose dont j'ai besoin pour passer du temps à apprendre.

@Zues et @Joshua Smith

Oui, je suis d'accord parfois le temps et le budget sont des contraintes qui ne vous permettent pas de mettre chaque principe de «meilleure programmation» que vous connaissez dans un programme.

Vous savez que la tâche en cours peut être effectuée de manière beaucoup plus robuste si seulement vous aviez plus de temps. Mais très peu de clients (surtout s'ils obtiennent leur première application iPhone ou leur premier logiciel d'intelligence d'affaires sur mesure) comprennent quand vous dites que vous réimplémentez quelque chose déjà fait parce que vous avez trouvé une meilleure façon de le faire.

Idem pour les tests unitaires. Malheureusement, je n'ai pas encore rencontré un client qui est prêt à allouer un budget pour ceux-ci. La réponse typique est comme «Test de régression automatisé OK Je comprends mais des tests unitaires? Nous n'avons pas le temps pour ça! Nous devons arriver rapidement sur le marché! »

Deux parties dans la plupart de mon expérience:

• temps
• obtenir suffisamment de personnes pour convenir des meilleures pratiques dans la situation actuelle

Les «meilleures pratiques» sont TRÈS subjectives dans de nombreuses situations réelles. Si une moitié de l'équipe essaie de faire un tas de SOLID & TDD tandis que l'autre moitié travaille 60 heures par semaine pour réduire les secondes de durée de course ici et là par tous les moyens nécessaires parce que vous avez dépassé le point où il est trop tard pour repenser quelque chose qui ne fonctionne pas à temps pour votre prochaine version, vous n'irez pas très loin.

Même si vous ne rencontrez pas trop de désaccords au sein de l'équipe, il faut beaucoup d'efforts pour obtenir un accord formel, de la documentation et une formation sur la politique que vous décidez de suivre. C'est un gros bloc de temps non productif du point de vue commercial que vous allez devoir justifier soigneusement.

Parfois, vous constaterez que l' habitude est également un contributeur majeur à l'écriture de code horrible.

Vous pourriez être un programmeur très expérimenté et vous pourriez tout savoir sur les meilleures pratiques actuelles de l'industrie. Enfer, vous pourriez même être l' expert de ces choses. L'expérience me dit que de telles personnes n'écrivent pas souvent de code horrible, et pourtant il peut être facile de se replier sur de vieilles habitudes et de faire quelque chose qui, selon vous, enfreindra les règles, tout simplement parce qu'il se sent en sécurité et pratique. Dans de tels cas, l'ignorance et l'arrogance et tous les autres adjectifs pointant du doigt que vous pourriez imaginer n'ont pas vraiment d'importance. Ce n'est pas nécessairement que ces programmeurs sont spécifiquement mauvais dans ce qu'ils font (bien que ce soit plus souvent le cas), ni même qu'ils veulent créer un désordre horrible.

Il est malheureux d'avoir personnellement vu cela se produire plus de fois que je ne le souhaiterais, où certaines personnes vraiment talentueuses ont produit des ordures parce que leurs doigts et leur cerveau fonctionnaient sur l'automobile depuis quelques mois. Le plus souvent, c'est là que vous voyez des signes d'épuisement professionnel, de chagrin et de stress s'accumulant. Parfois, c'est vraiment une habitude aveugle qui les porte à travers les mouvements quotidiens. C'est quelque chose que j'ai appris à surveiller attentivement afin d'éviter de risquer d'étiqueter inutilement les personnes vulnérables.

Juste un peu de réflexion pour ceux d'entre nous qui trouvent plus facile de sauter simplement à la conclusion négative ... même si malheureusement vous aurez raison le plus souvent.

Personne ne montre d'intérêt à payer pour un projet intitulé quelque chose avec refactoring. Il doit contenir des mots qui font appel aux intérêts des «entreprises». Des mots tels que la refonte, la revigoration, le remake total, la mise à niveau du cycle de vie, etc. fonctionnent sur mon lieu de travail. Presque tous ont le refactoring comme partie principale du projet.

Malheureusement, grâce au tueur à gages économique, le travail ne se produit que lorsqu'il y a un salaire. Même si le travail n'est que pour sauver la fortune de l'entreprise à long terme.