Au bout de ma corde [fermé]

Je suis entrepreneur d'une grande entreprise. Actuellement, il y a trois développeurs sur le projet, moi y compris.

Le problème est que les 2 autres développeurs ne comprennent pas vraiment. Par "ça", je veux dire ce qui suit:

• Ils ne comprennent pas les meilleures pratiques pour la technologie que nous utilisons. Après 6 mois de moi et d'autres qui leur ont donné des exemples, de terribles anti-schémas sont utilisés.
• Ce sont des programmeurs "copier-coller" qui produisent principalement du code spaghetti.
• Ils cassent constamment les choses, mettent en œuvre des changements mais ne font pas un test de fumée de base pour voir si tout va bien
• Ils refusent / rarement de demander des revues de code.
• Ils refusent / font rarement des choses de base comme le formatage du code.
• Aucune documentation sur les classes (jsdocs)
• Peur de supprimer du code qui ne fait rien
• Laissez des blocs de code commentés partout même si nous avons un contrôle de version.

Je me sens de plus en plus frustré lorsque je formate d'autres codes, corrige des bogues, découvre des fonctionnalités qui sont cassées et crée des abstractions pour supprimer les spaghettis.

Je ne sais vraiment pas quoi faire. J'essaie de ne pas être frustré, mais c'est juste un gâchis. J'aime ces personnes en tant que personnes, mais j'ai l'impression que la situation de codage est si mauvaise que je pourrais aller plus vite si elles naviguaient simplement sur le Web toute la journée.

Serait-il hors de propos de demander à notre responsable d'examiner les autres accès de validation svn; les commits ne peuvent être effectués qu'après un examen par une personne qui connaît bien ce que nous faisons? En tant qu'entrepreneur, je ne sais pas si c'est le meilleur choix.

Existe-t-il une manière subtile / pas si subtile de préciser combien de choses je corrige?

J'ai quelque chose comme ça dans mon équipe. J'ai fait de gros efforts pour amener les gens à faire la bonne chose et cela n'a pas fonctionné comme prévu, j'ai donc opté pour une solution différente.

Tout d'abord, je suis allé voir mon responsable et nous avons conclu un accord, aucun code ne rentre dans le contrôle de code source sauf s'il est couvert par des tests unitaires. Si le code entre sans tests unitaires, j'ai un droit de veto pour annuler immédiatement la validation et envoyer un ping à la personne responsable pour qu'ils puissent travailler sur les tests, puis pousser le code.

Avec cette règle en place, j'exécute régulièrement des outils de couverture de code (dans ce cas, jacoco dans notre build sbt ) pour m'assurer que les morceaux sont correctement couverts et je fais également des refactorings et des revues de code en permanence dans tout code poussé par eux. Comme il s'agit d'un projet Java et Scala , j'ai beaucoup d'outils pour m'aider à attraper des choses qui ne devraient pas être là ou qui ne fonctionnent pas comme nous le pensons, je ne sais pas comment vous pouvez faire la même chose avec JavaScript mais peut-être qu'il y a une solution.

La principale chose que je crois est de m'aider à suivre le rythme est que j'ai une vision claire de ce que j'attends du projet et de son architecture principale, donc chaque fois que je vois quelque chose qui ne reflète pas cette vue, je peux y aller et répare le. Vous devez faire de même, définir votre point de vue, les modèles à utiliser, la façon dont le code doit être écrit et vous tenir au courant, en les laissant toujours (et votre direction) savoir ce qui se passe et ce qui empêche le projet d'avancer. plus rapide.

Il y aura sûrement un moment où soit ils abandonneront et agiront correctement, soit la direction recevra le message et les supprimera du projet.

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:

1. 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 ...
2. 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.
3. 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?
4. 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.
5. 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 .
6. 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.
7. 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".
8. À 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?
9. 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.

Je vous suggère de parler à votre responsable de la question, mais il ne voudra certainement pas revoir chaque enregistrement.

Au lieu de cela, je suggère que vous suggériez une suite de tests unitaires / de régression, à raccorder à SVN et à exécuter pour chaque enregistrement. Cela vous aidera au moins à éviter les versions cassées. Vous pouvez progressivement proposer d'autres bonnes pratiques.

S'il se révèle totalement non réceptif, vous devriez peut-être passer par-dessus sa tête. Si vous décidez de le faire, vous devrez apporter votre meilleur jeu. Si vous le faites, vous proposerez essentiellement à la direction d'être embauché à un niveau supérieur.