Je suis sûr que maintenant vous avez vu mes commentaires et mon autre post, je ne vais donc pas prétendre connaître la réponse. Le mieux que je puisse offrir est un résumé de ce que j'ai entendu / lu des autres et ajouter une partie de ma propre expérience au mélange.
Tout d'abord, je tiens à dire qu'il y a quelque temps, je suis tombé sur un blog qui appartient à l'un de nos propres membres Programmers SE, Martin Blore et IMO, ce seul article spécifique sur l' auto-actualisation TDD est très précis. TDD est le dernier niveau le plus élevé qui relie tout, mais sans les niveaux précédents, en particulier le plus grand, les principes et les pratiques de production de code clair et lisible, il sera très difficile, voire impossible, de faire fonctionner TDD.
Dans mon entreprise, Agile et TDD nous ont été imposés par la direction, et au début nous les avons simplement fait parce qu'on nous l'avait dit (ce qui est l'opposé de l'agile). Nous avons essayé TDD deux fois et bien que je sois un grand partisan des tests automatisés, j'ai personnellement rejeté tous ceux que l'équipe a giflés ensemble dans la dernière version. Ils étaient fragiles, gigantesques, copiaient / collaient le wazoo et criblés de phrases de sommeil qui les faisaient courir très lentement et de façon imprévisible. Mon conseil pour votre équipe: NE PAS FAIRE TDD ... pour le moment.
Je ne sais pas quelle est votre situation parce que vous avez mentionné que vous travaillez pour l'entreprise depuis seulement 6 mois et que vous êtes un entrepreneur. Vos objectifs à long terme sont-ils de rester avec cette entreprise ou le contrat va-t-il expirer? Je demande parce que même si vous faites quelque chose, cela pourrait prendre un certain temps pour voir les résultats.
De plus, lorsque vous vous joignez à une équipe, il faut généralement du temps avant d'obtenir suffisamment de crédibilité et de respect de votre équipe où elle (les développeurs et la direction) considérerait même tout ce que vous proposez. D'après mon expérience, cela aide si vous éteignez quelques feux et démontrez que vous avez des compétences et des connaissances sur lesquelles les autres peuvent compter. Je ne sais pas si 6 mois suffisent. Très souvent, une nouvelle personne ambitieuse se joindrait à l'équipe, puis ferait un post ici demandant comment ils peuvent changer le monde. La triste réalité est qu'ils ne peuvent tout simplement pas.
En supposant que vous ayez le respect et l'attention de votre équipe. Maintenant quoi?
Tout d'abord, la direction et les développeurs doivent être conscients qu'il y a un problème. La direction mesure les résultats en termes de travail livré. S'ils sont satisfaits de la quantité et de la qualité actuelles des fonctionnalités, alors la triste réalité est qu'ils n'écouteront pas. Comme d'autres l'ont souligné, sans le soutien de la direction, il sera extrêmement difficile d'introduire tout type de changement.
Une fois que vous obtenez un support de gestion, l'étape suivante consiste à creuser profondément et à identifier les causes profondes de la raison pour laquelle l'équipe fonctionne comme elle le fait. Ce sujet suivant est quelque chose qui est une de mes recherches personnelles depuis un petit moment maintenant. Jusqu'à présent, cela a été mon voyage:
- Une fois que vous avez le soutien de la direction. Vous pouvez commencer à introduire un grand nombre de pratiques / processus dictés centralement que MainMa a suggéré en réponse à ma question . Nous en avons fait beaucoup (sauf pour la programmation en binôme) et vous voyez certainement des avantages. Les revues de code ont particulièrement aidé à standardiser le style, la documentation et nous ont également permis de partager les connaissances / techniques au sein de l'équipe. Même si les révisions de code ont été dictées, l'équipe les aime et nous examinons chaque fonctionnalité qui est archivée. Cependant ...
- Vous remarquez que le code généralement écrit est encore trop couplé, que la conception est mauvaise ou complètement absente. Les revues de code en attrapent une partie, mais il n'y a que beaucoup de choses que vous pouvez réécrire. Pourquoi le design est-il mauvais en premier lieu? - Beaucoup de développeurs n'ont jamais été initiés aux bonnes pratiques et n'ont jamais été formellement initiés à l'OOD. Beaucoup de gens "ont simplement codé" quelle que soit la tâche qui leur a été confiée.
- Avec le soutien de la direction, vous pouvez introduire plus de processus, comme discuter de la conception avant tout codage. Mais vous n'êtes qu'une seule personne et il semble que dès que vous ne faites pas attention, l'équipe revient à ce qu'elle a toujours fait. Pourquoi?
- Peut-on introduire et enseigner de meilleures pratiques ou habitudes afin de ne pas avoir à surveiller constamment? - Il s'avère que cette partie n'est pas si facile.
- Pourquoi les autres membres de l'équipe sont-ils réticents à apprendre et à choisir de nouvelles pratiques et pourquoi sont-ils si résistants à SOLID ou DRY alors que cela est tellement écrit dans la littérature sur la méthodologie logicielle moderne? Avec tous les changements positifs que nous avons eu dans mon équipe, il y a 2 semaines, j'ai eu un argument si j'ai refactorisé 2 fonctions qui avaient 15 lignes de code identiques et le critique l'a appelé héroïque, effort inutile car il n'y a rien de mal à copier / coller de seulement 15 lignes. Je suis fortement en désaccord avec ces points de vue, mais pour l'instant nous avons décidé d'accepter d'être en désaccord. -- Et maintenant? Nous avons maintenant atteint le sujet de mon autre article .
- Comme maple_shaft et nikie l'ont souligné dans leurs réponses (désolé, MainMa , vous avez obtenu le plus de votes, mais vous avez tellement 5 pas de retard :)), vous avez atteint un stade où "processus" ne peut plus vous aider ni aider personne sur ce forum peut vous dire quel est le "correctif". La prochaine étape consiste à approcher des individus, peut-être en tête-à-tête, peut-être en équipe, probablement à la fois à un moment ou à un autre et leur parler. Demandez-leur ce qui fonctionne et ce qui ne fonctionne pas. La seule façon d'identifier la cause profonde de ce qui les motive est maintenant de leur parler individuellement et de le découvrir. Dans le cadre de cette étape, j'ai récemment rencontré un problème d'équipe complètement différent, mais je pense que la réponse de Joel ici, qui est très détaillé et perspicace, s'appliquerait également à cette affaire. En résumé, bien que l'utilisation de la gestion comme "laisse courte" soit une approche possible pour à peu près n'importe quoi, nous devons nous rappeler que nous avons affaire à des humains, donc pour vraiment comprendre les motivations, nous devons passer plus de la psychanalyse à la gestion pure ou au leadership technique.
- Alors maintenant, vous parlez à vos coéquipiers? Que leur demandez-vous? Je ne suis pas sûr de cette prochaine partie car je ne suis jamais venu ici. Voici un scénario possible: Q: Comment se fait-il qu'aucun SOLID? R: Je n'en ai pas besoin. Q: Cela pourrait aider. R: Je vais bien tel quel. - d'une manière ou d'une autre, vous devez générer une série de sons qui sortiraient de votre bouche et amèneraient l'auditeur à reconnaître que les choses pourraient être meilleures s'ils donnaient une chance à ce que vous colportiez. Si vous échouez ici, ils ne seront jamais convaincus que quel que soit le «processus» qui les fait faire, cela a réellement une valeur. D'un autre côté, si vous avez dépassé ce point, vous constaterez probablement que vous n'avez même plus besoin du "processus".
- À la racine de l'OMI, vos coéquipiers n'apprendront pas s'ils ne voient rien de mal à leurs habitudes / pratiques actuelles. Alors peut-être que la prochaine étape dans tout cela est de trouver un moyen d'illustrer, de souligner les problèmes et de les rendre évidents. Après tout, nous n'écrivons pas de code lisible, n'utilisons pas les principes SOLID / DRY ou ne maintenons pas de documentation simplement parce que cela nous donne une sensation chaleureuse et floue. Nous le faisons parce qu'il produit un code de meilleure qualité et nous rend franchement plus rapides. Cela peut-il être mesuré? C'est peut-être là que les métriques logicielles entrent en jeu?
- Voici une idée folle et je n'ai aucune idée si cela fonctionnerait réellement (ce pourrait être une pratique standard de l'industrie, ou peut-être complètement invalide. Je viens de l'inventer au cours des dernières 24 heures), mais je suis très tenté de l'apporter à la table dès le début de l'année prochaine:
- Contre les opinions de beaucoup d'autres , introduisez l'idée d'auteur / propriétaire pour tous les fichiers source. Comme le suggère le programmeur pragmatique, cela donnera un sentiment d'appartenance et de responsabilité à une seule personne qui sera responsable d'un morceau de code source. Cela ne signifie pas que d'autres personnes ne peuvent pas modifier le code, nous travaillons tous en équipe, mais à la fin de la journée, la personne qui possède le code est responsable de l'examen des modifications.
- Créez un déclencheur de référentiel source qui surveille tous les enregistrements et recherche spécifiquement ceux qui sont des corrections de bogues. Faites-en un processus pour que chaque correction de bogue ait un identifiant de référence directement dans la description de l'enregistrement. Maintenant, écrivez un script qui analyserait une liste de fichiers qui ont été modifiés et supprimez "Author" du bloc de commentaires d'en-tête de fichier. Créez une base de données SQL qui permettrait de suivre le nombre de défauts enregistrés par fichier / par projet / par auteur.
- Une fois que vous avez suffisamment de statistiques, nous espérons que vous remarquerez que votre code présente moins de défauts / modifications que certains autres codes. Ce sont des données matérielles que vous pouvez utiliser. Si un seul projet présente un taux de défauts nettement supérieur à la moyenne, présentez-le en tant que candidat pour le prochain effort de nettoyage / refactoring afin de rembourser une partie de la dette technique.
- Si un projet ou un fichier présente un taux de défauts nettement supérieur à la moyenne et qu'il a un propriétaire, parlez en tête-à-tête avec cette personne. Demandez-leur, très poliment, sans confrontation ce qu'ils peuvent faire pour y remédier. Puisqu'ils sont le propriétaire, ils devraient conduire le changement, mais offrir toute l'aide de votre côté. Espérons que le propriétaire trouvera de nombreuses causes à son propre code de spaghetti et dès qu'il demandera de l'aide, c'est à ce moment-là que vous passerez à l'action et que vous fixerez du SOLID.