Comment convertir un programmeur copier / coller / spaghetti pour voir la lumière?

Cette question a été inspirée par celle-ci . Bien que cette autre question ait été jugée localisée, je pense que le problème sous-jacent est extrêmement répandu dans notre secteur. Je sais qu'il y a des développeurs qui liront ceci et penseront que je fabrique ça, puis ils pourront répondre à quel point tout le monde s'intéresse à leur travail et veut apprendre, mais il suffit de regarder d'autres publications de Programmers SE ( exemple ), Je sais que ce n'est pas universellement vrai.

Supposons donc que votre équipe (ou peut-être la majorité) ait pour procédure d'opération standard le copier / coller et estime que tout peut être résolu si vous ajoutez seulement suffisamment d'appels de fonction et de variables. Cette personne n'a jamais entendu parler de TDD, DRY ou SOLID et, en dehors des 40 heures de travail au travail, elle n'a jamais lu un seul livre de méthodologie / pratiques / conception.

Dans le passé, j'ai demandé (avec d’autres) comment enseigner à l’OOD . Mais maintenant, je pense que ce n'est pas la bonne question. La vraie question est de savoir comment approcher une telle personne / équipe et les rendre curieux de savoir comment mieux faire les choses. Comment les incitez-vous à apprendre? Sans cela, il semble que tous les enseignements, réunions, conférences, discussions soient inutiles s'ils sont parfaitement heureux de retourner à leur bureau et de faire ce qu'ils ont toujours fait.

Je travaille avec un tas de gens comme ça. Ce sont en fait des individus très brillants, mais je déteste quand j'entends: "J'ai fini de coder, il suffit de refactoriser et de scinder en plusieurs classes pour rendre DXM heureux". Ils ne refactorisent pas le code pour qu'il soit plus propre, lisible et maintenable, mais uniquement parce qu'autrement, ils seront grondés. Je sais qu'ils sont capables d'apprendre, il semble qu'il y ait un manque général de motivation.

Quand je livre un travail, il y a généralement beaucoup moins de bugs et le travail que je possédais ne devint jamais une monstruosité de 5000 lignes d'une classe. Les autres font des commentaires du type "ton code est beaucoup plus propre et lisible que nos fichiers", ils voient donc la différence. Mais en même temps, j'ai l'impression qu'ils pensent être payés pendant 40 heures, peu importe ce qu'ils font. Ils ne voient donc pas d'inconvénient à ce qu'ils passent trois jours complets en assurance qualité à la recherche d'un bug qui n'aurait pas dû être introduit dans la première place. Ou qu'ils prennent une semaine pour modifier une classe parce qu'il y a tellement de dépendances qu'ils finissent par toucher. Cependant, "peut-être que cette classe aurait dû être écrite différemment" ne semble jamais apparaître.

Peut-on faire quelque chose dans ces situations? Quelqu'un at-il réussi? Ou est-il préférable d'isoler cet état d'esprit des parties non critiques du projet et de minimiser les dommages?

NOTE: Quand je dis "manque de motivation". Je ne pense pas que ce soit un manque de motivation pour travailler ou faire un bon travail parce qu'ils ont simplement cessé de s'occuper. La plupart de notre équipe est en fait tout le contraire. Ils se soucient vraiment du produit. Nous avons des gars qui vont travailler la nuit et le week-end. Ce que j'essaie de faire, c'est d'améliorer les habitudes et les compétences, ils n'auraient pas à travailler autant. J'imagine que "40 heures" a rendu ce billet un peu trop négatif.

Vous avez trouvé vous-même la raison: "Je sais qu'ils sont capables d'apprendre, il semblerait qu'il y ait un manque général de motivation."

Il y a des gens qui sont passionnés par leur travail. Et il y en a d'autres qui, parfois suffisamment compétents, travaillent uniquement pour de l'argent . Ils connaissent leur métier, mais n'apprécient pas leur travail. Ils ne consacreront pas plus de temps à la refactorisation supplémentaire afin de rendre le code lisible ou à la résolution d'un problème intrigant lorsqu'un piratage rapide et laide peut faire l'affaire.

Ce phénomène existe dans tous les emplois. C'est juste que certains emplois ne sont pas très excitants (avez-vous vu un comptable qui aime son travail et qui en rêvait déjà quand il était enfant?), Mais dans la programmation, il y a beaucoup de gens qui aiment vraiment ce qu'ils font (sinon Programmers.SE sera plutôt vide). Cela signifie qu'en tant que développeurs passionnés, parlant quotidiennement à d'autres développeurs passionnés, nous avons plus de chances d'être surpris de voir une personne qui programme uniquement pour de l'argent.

Que pouvons-nous faire? Pas trop. Dans tous les cas, ce n’est pas à vous, mais aux ressources humaines de choisir des personnes vraiment motivées¹. Et congédiez les gens qui ne le sont pas.

Vous pouvez essayer de motiver vous-même vos collègues, mais c'est extrêmement difficile. Si vous leur donnez des livres à lire, ils les renverront non ouvertes quelques semaines plus tard. Si vous leur donnez un conseil, ils n'écouteront pas car ils s'en moquent².

Vous pouvez:

• Convaincre votre employeur de définir un certain nombre de règles strictes dans votre entreprise: règles de style , etc. Cela ne les incitera pas à faire un meilleur travail, mais au moins, ils ne pourront pas engager de code source non conforme aux exigences. .

• Travailler sur les exigences, en particulier les exigences non fonctionnelles . Qu'en est-il d'une exigence qui indique qu'un projet spécifique doit contenir moins de 5 000 lignes de code IL (non, je ne parle pas du LOC sans signification ) ³? Qu'en est-il de la nécessité d'obtenir des résultats spécifiques à la complexité cyclomatique ou au couplage de classe ?

• Augmentez le nombre d'heures que vous passez dans votre entreprise à la révision de codes . Spécifiez ce qui est examiné: si vous avez une liste de contrôle, ajoutez les points relatifs au refactoring, à la lisibilité, aux commentaires propres et utiles, etc. Si vous n'avez pas de liste de contrôle, vous devez le faire.

• Utilisez [plus] la programmation par paires . Cela peut aider à améliorer la qualité du code et à motiver les collègues moins motivés.

• Utilisez le système de compensation similaire à celui utilisé à Fog Creek.

^{¹ C’est le sens des entretiens: avant de vous engager, les ressources humaines doivent être un atout non seulement pour votre niveau technique, mais également pour votre motivation . Malheureusement, certaines entreprises ont oublié cette deuxième partie de l’entrevue et ont embauché des personnes qui n’apprécient pas trop la programmation. Heureusement, dans la plupart des cas, le travail dans ces entreprises n’est jamais agréable, et Joel test dépasse rarement 2.}

^{² Ils s'en moquent vraiment , même s'ils gagnent moins d'argent. Je suis assez proche d'un de mes clients (je suis un pigiste) qui pense que son travail consiste à développer des sites Web pour ses propres clients. Il a aussi un designer. Je leur ai souvent expliqué comment augmenter leur productivité de deux ou plus. S'ils venaient d'embaucher quelqu'un de compétent, ils augmenteraient leurs revenus d'au moins 3 €. Mais ils ont assez d'argent et ne se soucient pas de la qualité ni du coût qu'ils coûtent aux clients ignorants, comparés à quelqu'un de productif.}

^{³ Ce que je veux dire, c’est le nombre de lignes de code IL que vous voyez dans Code Metrics dans Visual Studio , la métrique qui signifie réellement quelque chose. Le vrai LOC n'a pas d'importance et vous n'avez pas à le mesurer; c'est l'une des métriques les plus stupides de tous les temps. L'application de lignes de code IL signifie que les développeurs seront forcés de refactoriser le code, et pas seulement de réduire dix lignes de code en une seule ligne illisible.}

"J'ai fini de coder, il suffit de refactoriser et de diviser en plusieurs classes pour rendre DXM heureux".

Cette ligne de pensée: il y a un cancer dans n'importe quelle équipe et tuera la motivation de toute l'équipe si on ne s'en occupe pas immédiatement. Je fais bien sûr allusion au fait que par ancienneté et / ou mérite, vous occupez un poste de responsable technique, ce qui vous donne le pouvoir d’influencer et d’apporter de bonnes pratiques dans votre équipe.

C'est très bien, mais si votre équipe était clairement vendue sur ces processus, elle ne vous exclurait pas dans des déclarations comme celle-ci qui témoignent clairement d'un manque de respect pour le processus et d'un manque de respect envers vous. Ils considèrent toujours ces meilleures pratiques comme un obstacle causé par vous et non comme un processus appartenant à l'équipe que votre équipe défendra pour ses propres mérites.

Vous avez mentionné dans des commentaires précédents que d'autres membres de l'équipe suivaient effectivement ces pratiques et ces normes et les appliquaient correctement. Concentrez-vous sur leur attention pour renforcer leur soutien, demandez-leur ce qui fonctionne, ce qui ne fonctionne pas, ce qu'ils aiment et ce qu'ils aimeraient voir changé. Si vous agissez ainsi et prenez leurs opinions au sérieux, ils se sentiront très différemment à propos des normes, comme s'il s'agissait d'une décision communautaire plutôt que d'une procédure qui leur avait été imposée par un supérieur.

Vous renforcez la prise en charge des meilleures pratiques et normes en indiquant à l'équipe comment elle a amélioré le processus de développement logiciel ou la qualité du logiciel.

Organisez un vote sur les questions à débattre et documentez les résultats. Idéalement, chaque décision doit être prise à l'unanimité pour des raisons de légitimité. Toutefois, si vous traitez avec des obstructionnistes intransigeants, cela peut être impossible et risque de bloquer tous les problèmes. Utilisez un vote majoritaire dans cette situation. Si la majorité est contre vos normes et pratiques proposées, alors vous avez déjà perdu la place, abandonnez-la à ce moment-là.

Ils seront propriétaires de ces normes et procédures et les appliqueront afin que vous n'ayez pas à le faire. En tant que responsable technique, vous ne devriez pas être obligé de déclarer des édits et décrets, c’est une mauvaise façon d’être un leader.

Une fois que l’équipe a l’impression de maîtriser les procédures, les membres de l’équipe qui commencent à vous attribuer certaines procédures et les meilleures pratiques seront illégitimes de le penser. Votre équipe aidera à corriger cette attitude chez les autres.

Bonne question! Je pense que la réponse dépend de la raison pour laquelle les gens ne veulent pas améliorer leurs compétences. Les réponses possibles sont:

• Ils pensent qu'ils sont trop occupés pour apprendre quelque chose de nouveau ou que la nouvelle façon de faire (comme écrire tous ces tests) leur prendra plus de temps et qu'ils n'ont pas le temps de le faire. La réponse évidente serait alors: donnez-leur plus de temps. Apprendre quelque chose ou d' essayer quelque chose comme TDD lorsque vous avez des choses différemment toujours fait vont prendre plus de temps les deux premières fois. Si vos programmeurs n'ont pas ce temps, vous ne pouvez pas leur reprocher de ne pas essayer.
• Ils ont une perception différente de leurs propres compétences, c'est-à-dire qu'ils pensent être de très bons programmeurs produisant du code de haute qualité. C'est un terrain psychologique difficile, car briser cette croyance peut être très démotivant. Peut-être qu'une sorte de compétition informelle peut aider (qui produit le moins de défauts / caractéristiques? Le code le plus court? Le moins de WTF / minute dans une révision de code?).
• Il peut y avoir un problème de motivation réel (par exemple, ils veulent juste "faire leur temps et être laissés seuls" jusqu'à l'heure de fermeture). Heureusement, c'est trop général / pas lié à la programmation, parce que je n'ai vraiment pas de réponse à cela.
• Ils sont débutants et ils ne savent pas mieux. Dans ce cas, une formation, des critiques de code peuvent aider, ou un "club de lecture" où un membre de l'équipe doit discuter d'un nouveau livre technique tous les mois.
• Ils ont déjà vu des balles d'argent (et ont été amèrement déçus) et pensent que tout ce que vous essayez de leur vendre n'est qu'un nouveau mot à la mode qui sonne bien en théorie et qui n'a guère d'utilité en pratique. Dans ce cas, il pourrait être utile de démontrer les avantages lors de la révision du code et des sessions de programmation en paire. Essayez de ne pas être un tout à fait savoir quand vous faites cela.

La meilleure solution dépend vraiment du problème fondamental: par exemple, des directives de codage, des métriques et des critiques formelles peuvent s’avérer utiles pour les débutants, mais les personnes ayant une "mauvaise perception de leurs propres compétences" peuvent se battre ou jouer les métriques car elles le voient. comme des obstacles bureaucratiques contre-productifs à l’accomplissement de leur travail.

La vraie question est de savoir comment vous approchez une telle personne / équipe et les intriguez pour savoir comment mieux faire les choses. Comment les incitez-vous à apprendre? Sans cela, il semble que tous les enseignements, réunions, conférences, discussions soient inutiles s'ils sont parfaitement heureux de retourner à leur bureau et de faire ce qu'ils ont toujours fait.

C'est ça! C'est en effet une vraie question.

Pour résumer, nous n’avons simplement pas le temps de mettre beaucoup de formation formelle - mais parfois si je le fais - cela ne voit toujours pas la lumière. J'ai également fait partie des entreprises où la formation formelle devient un processus en soi mais Je suis si souvent témoin que l'on ne leur apprend guère à penser.

Donc, la question que je leur pose n’est pas de savoir comment leur apprendre , mais comment leur faire apprendre? La différence est subtile mais c'est ce qui va faire toute la différence.

Je ne sais pas si j'ai raison. mais souvent je crois au dialogue d'une matrice du film - "C'est la question qui nous pousse!" Le plus important est de les faire réfléchir, de leur demander pourquoi! Et bien sûr, la plupart des personnes qui pensent tout savoir sur certains modèles de conception, car elles ont obtenu de bonnes notes dans les cours universitaires, sont les plus difficiles.

Comment obtenez-vous ces questions? Mon approche générale est "qui les jette dans l'étang si vous voulez qu'ils apprennent à nager" . Je suis d'accord que les gens peuvent être en désaccord; et j'accepterai volontiers d'être en désaccord avec eux. Lorsque vous les jetez dans l’étang, ils n’apprennent pas à nager automatiquement; mais cela suscite un instinct de survie qui les fait réfléchir - une fois que cela se produit, ils penseront naturellement à COMMENT et POURQUOI.

Un exemple concret que je donne aux gens est de les placer dans un projet beaucoup plus complexe que celui qu'ils espéraient obtenir et de les laisser mener leur propre bataille. Lorsqu'ils ont commencé à déchiffrer le code et ont eu du mal à le retracer, vous réalisez qu'ils commencent à poser une bonne question.

Cela peut sembler un peu extrémiste, cela peut sembler un gaspillage de ressources . Et j'en suis sûr, beaucoup d'autres me donneront le conseil de ne pas le faire. Mais cela a fonctionné pour moi!

Peu importe les packages de paie et les tags HR que vous lui affectez, cela ne résoudra pas le problème de motivation de base . Pour que le seul chemin est qu'ils sont contestés; Si vous suscitez cet esprit humain fondamental, tout le reste fonctionne. Si vous ne pouvez pas, c'est un jeu lâche.

PS: Juste à propos, j’ai posté une réponse ici https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - et j’ai eu tout le chahut; principalement la plupart des gens croient que les entreprises ne peuvent pas se permettre de gaspiller des ressources! Je suis sûr que cette réponse pourrait recevoir un traitement similaire ici. Mais la vérité est que faire travailler les gens et leur faire croire qu’ils font du bon travail est un sujet de psychologie humaine qui explique comment élaborer le programme du cours.

Quoi qu'il en soit, la tâche que vous décrivez ici revient à enflammer la passion intérieure qui consiste à faire de grands changements. Et plus le système est complexe, plus il devient difficile. Commencez par les plus jeunes boursiers, toujours ancrés dans l’ esprit « je ne veux pas faire le bon travail » et défiez le statu quo.

Comme vous le soulignez, sa motivation. Ne vous méprenez pas sur le fait qu'ils ne s'en soucient pas. Ils savent clairement quoi faire. Ils s'en moquent . Si tel est le cas, la vraie question qui se pose est la suivante: qu'est-ce que votre direction fait de mal à les garder si démotivés? Êtes-vous le membre le plus récent de l'équipe? Peut-être ont-ils déjà traversé tout cela auparavant, avec seulement des problèmes de gestion de leur part. Donc, ils se contentent de faire le moins de travail possible pour garder leur emploi, car ils ne pensent pas que l'employeur fera plus.

Il me semble que c’est un problème de gestion et de direction - si c’est votre équipe, vous pouvez travailler à faire de l’amélioration (personnelle et du code) un attribut fondamental de votre équipe, la question est de savoir si votre volonté sera appuyée par votre direction - car vous allez vouloir faire des choses qui prendront du temps (ils obtiendront un gain net car vous devriez réduire la nouvelle dette technique et rembourser la dette technique existante).

Donc, vous affirmez que vous voulez que l'équipe s'améliore, vous obtenez son accord sur le fait que c'est une bonne chose (que l'équipe, dans son ensemble, travaille à améliorer la qualité de son code) et que vous démarrez ensuite un programme pour la rendre arrive - ça a l'air si facile ... je suis conscient que ce n'est pas le cas!

Je pense que cela comporte deux parties: l’éducation et les pratiques de travail.

• Education, vous pouvez commencer un déjeuner par semaine - tout le monde mange ensemble, vous organisez une présentation de 20 à 30 minutes avec questions / réponses. Vous commencez avec les bases que vous souhaitez - SOLID peut occuper les 2 à 4 premières semaines - au fil du temps, vous demandez à l’équipe de parler en alternance et vous pouvez déterminer comment décider qui discute entre quoi. Permettez aux orateurs un peu de temps de préparation au travail. Au-delà, encourager la participation des groupes d'utilisateurs locaux (en le rendant au moins partiellement social si possible)
• Pratiques de travail ... Cela dépend de ce que vous faites maintenant et des outils dont vous disposez, mais vous voudrez peut-être examiner les normes de codage, introduire la révision de code par les pairs (est-il solide), les tests unitaires (pas nécessairement les premiers tests) , exécutant un serveur d'intégration continue et envisageant des tests plus automatisés (en plus des tests unitaires). Mais ceux-ci doivent essentiellement être introduits avec consentement / accord (pas le serveur build / CI!) Et vous devez vouloir faire progresser la qualité en équipe. Il y a toujours des choses que l'on peut améliorer (Kaizen)

Cela vaut également la peine de regarder Kanban (qui est perçu comme un facteur de changement / d’amélioration).

Une dernière pensée: je suis un programmeur professionnel et je voudrais que mon équipe soit la même, mais travailler plus de 40 heures par semaine n’est pas une bonne chose. L’objectif devrait donc être d’avoir une équipe qui fasse son travail. efficace et bien dans la semaine normale de travail et en ce qui concerne ce l'argument en faveur de l' amélioration des pratiques de travail est qu'il est plus probable par exemple: ajout de tests unitaires pour démontrer le cas à défaut lorsque (avant) bug de fixation vous donne la confiance qu'il estfixé; Avoir un serveur de build vous donne confiance dans votre capacité à construire vos solutions proprement - si cette build génère également des packages de déploiement, cela signifie que le déploiement est considérablement simplifié. Le code SOLID est, par définition, plus facile à modifier; et partout, moins vous contractez de dettes techniques, moins vous devez rembourser ...

Je suis tombé dans la programmation par accident il y a environ 30 ans. J'étais motivé à apprendre les principes de base du génie logiciel en étant chargé de maintenir / supporter le code des autres. Dans ces missions, j'ai appris comment un lecteur de code expérimente le code - comment faire preuve d'empathie avec le lecteur de code. Je ne voulais pas infliger la douleur de mon code mal écrit à d'autres!

Cette pratique consistant à affecter de nouveaux programmeurs à la maintenance / au support du code d’autres personnes n’est pas une solution miracle, elle semble motiver pour apprendre à produire du code solide plus souvent qu’autrement.