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


35

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.


De quel pays s'agit-il?

3
@ ThorbjørnRavnAndersen - USA. maintenant vous devez écrire une réponse parce que je suis très curieux de savoir comment cette information l'a affecté :) J'ai toujours pensé que nous étions tous humains et que ce type de contenu était universel. Et non, cette question n'a rien à voir avec l'externalisation.
DXM

8
Les différences culturelles entre les pays peuvent être considérables et toute tentative d'introduire un changement doit en tenir compte. Ce qui fonctionne dans une culture ne fonctionnera probablement pas dans une autre. Dans votre cas, j'estime que le meilleur moyen consiste à faire en sorte que la direction élève officiellement la barre de ce qui est acceptable.

Réponses:


18

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.


3
Je ne suis pas d'accord: la motivation à travailler et la motivation à apprendre sont deux choses totalement distinctes. Par exemple, certaines personnes aiment leur travail et leur travail, mais elles pourraient penser que "SOLID" est juste un autre mot à la mode connerie-bingo ou "TDD" est un concept de tour d’ivoire qui n’a aucune utilité dans le monde réel.
Nikie

5
@maple_shaft a raison: certaines personnes travaillent 70 heures / semaine et produisent la pire quantité de code spaghetti sans aucun test (elles n'ont pas le temps de faire ce genre de bêtises!). Ils sont passionnés et améliorent constamment leurs compétences, mais rentrent chez eux après 40 heures, car ils savent qu’ils ne peuvent pas être productifs plus longtemps que cela. Ne mélangez pas les deux choses!
Nikie

13
Non non Non. Volonté d'être exploité par un employeur! = Capacité à produire un code de qualité. Il y a beaucoup trop de choses absurdes dans notre industrie "sans rester jusqu'à 2 heures du matin pour le faire" sans que nous confondions cela avec un développeur mythique d'Ideal. Si VOUS aimez travailler 80 heures par semaine, vous aurez plus de pouvoir. J'ai des choses qui sont importantes pour moi en dehors du travail. Pour conclure, je suis mauvais dans ce que je fais à cause de cela, ce qui est au mieux faux. Aucune autre industrie ne s'en tire avec ce que nous faisons, et c'est à nous de changer cela, si cela doit changer.
Dan Ray

6
Devoir travailler jusqu'à 2 heures du matin pour travailler sur un projet est un moyen très efficace de tuer tout amour pour ledit projet, en particulier pour les personnes ayant des obligations familiales.

2
Je pense que tous les points soulevés ici sont valables, mais certains d’entre vous ont peut-être mal compris MainMa. Il n'a jamais dit de travailler jusqu'à 2 heures du matin parce que vous êtes obligé de respecter les délais. Au lieu de cela, il a simplement fait référence aux personnes qui sont si captivées par l'excitation de voir quelque chose fonctionner que parfois, elles préfèrent le faire que d'aller dormir. Je peux comprendre cela. Pour moi, un exemple extrême est une tâche sur laquelle je travaillais pour ajouter un support de tunneling à notre bibliothèque de streaming vidéo. Cela a été estimé à 5 jours, mais avec notre nouvelle architecture de pipeline, tout se passait si bien que j'ai commencé vendredi après-midi ...
DXM

12

"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.


1
+1 pour mettre l'accent sur les relations plutôt que sur les principes
sunwukung

5

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.


Bons points. J'aime particulièrement le premier - et je dirais même plus généralement: il faut d’abord préciser que l’apprentissage sur le tas est encouragé et qu’il est acceptable de réserver du temps de manière explicite.
Sleske

Si les gens ont une perception différente de leurs compétences, peut-être mesurent-ils simplement le succès selon différents paramètres? Si vous mesurez la qualité du code et pensez à la vitesse à laquelle il peut être créé, le résultat sera évidemment différent. Dans ce type de cas, vous devriez demander comment ils mesurent le succès. Différentes personnes ont une manière différente de penser à cela.
tp1

3

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.


merci d’avoir soulevé la matrice, je dois la regarder 2 heures de plus dans ma vie :) C’est drôle, mais j’ai trouvé que les "freshers" sont ceux qui absorberont tout ce que vous leur lancez. Étant moi-même diplômé d'un excellent programme de CS, j'explique très clairement ce que je pense de leur "éducation" et la plupart du temps ils sont d'accord avec moi. Je trouve que les plus gros problèmes sont ceux qui le font depuis 10, 15, 20 ans et plus. Je suis également d'accord avec votre approche du "procès au feu". C'est exactement comme ça que j'ai appris à ne pas faire. Le problème est a) cela prend beaucoup de temps que la plupart des équipes ne peuvent pas se permettre et b) quand on travaille en équipe ...
DXM

.. réglage (oserais-je dire «semi-agile», ne me déteste pas S.Lott :)), nous n’avons pas la propriété exclusive, ce qui nécessite des essais au feu. S'ils écrivent quelque chose qui échoue, quelqu'un interviendra et le réparera. En tant que personne qui a vécu la plupart du temps dans l’étang, j’aimerais réfléchir, j’étais curieuse de savoir si quelque chose pouvait être fait pour transférer cet état d’esprit sans que toute votre équipe ne traverse l’étang.
DXM

@DXM Je suis d’accord avec vos préoccupations: mieux vaut ne pas jeter toute l’ équipe à la fois. Oui. Le point est, commencez à en jeter certains un par un alors! Au moins c'est un bon accord entre nous. Je pense que l'état d'esprit qui a grandi pendant de nombreuses années nécessitera du temps et de la persévérance pour changer.
Dipan Mehta

@DXM pour vous donner des éléments plus concrets - essayez de petites initiatives à la fois - montrez les réalisations et montrez que la gestion est synonyme de travail pour faire du bon travail. Et promouvoir l'esprit en marche - une étape à la fois. la persistance serait un must, mais j'avais réussi une telle chose dans ma dernière entreprise. Au fil du temps, la direction a continué à donner à mon équipe un exemple de réussite.
Dipan Mehta

1
J'aime votre réponse, surtout si cela fonctionne pour vous, alors ce qui suit n'est pas une critique, mais juste une remarque: malheureusement, cela ne fonctionne pas dans tous les cas. J'ai eu plusieurs cas où des développeurs non motivés ont démarré de grands projets. Le projet a échoué à chaque fois: le projet a échoué et ils ont blâmé la direction, ses collègues, le manque de temps ou de ressources, ou le manque de clarté des exigences. Je me demande ce qui fait la différence entre ceux qui vont apprendre à nager et ceux qui vont probablement blâmer l’eau.
Arseni Mourzenko

2

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.


Je suis le chef d’équipe et je fais partie de l’équipe depuis près de 9 ans, mais c’est il ya environ un an. Je pense qu'il y a une différence entre "ne vous souciez pas du travail ou de la qualité de mon code" et "ne vous souciez pas de l'acquisition de nouvelles compétences". Nous avons en fait apporté beaucoup d’améliorations du côté de la direction et beaucoup de nos coéquipiers sont maintenant très heureux. Cependant, certains sont assez contents de faire ce qu'ils ont toujours fait. Ils ont effectivement passé des heures supplémentaires sans qu'on le leur demande, très réactif, mais ils semblent toujours assez satisfaits de déboguer leurs propres bogues 75% du temps.
DXM

1
Eh bien, alors, comme dans toutes les professions, tout le monde ne se trouvera pas dans la moitié supérieure de la courbe en cloche. Il est possible que vous n'ayez que quelques personnes pour le salaire.
GrandmasterB

Vous savez, chaque année, nous sélectionnons un devis d'équipe et l'année 2011 était "c'est ce qu'elle est", mais nous sommes sur le point de commencer une nouvelle année et au moins pour le moment, je refuserai d'accepter que c'est ce qu'elle est, Bien que je sois d’accord avec vous, il le fait la plupart du temps. J'ai réfléchi davantage à cette question et j'ai en fait une idée qui pourrait avoir un potentiel. Puisque je ne peux pas répondre à ma propre question (problème personnel, pas de limitation du système), si 2 personnes supplémentaires votent en faveur de la réouverture de programmers.stackexchange.com/questions/127080/…, je posterai ici :)
DXM

2

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 ...


0

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.


1
J'ai commencé de la même façon, mais pas par accident. Ceci est très similaire à ce que Dipan Mehta a déclaré dans son message. Vous jetez une personne dans un étang, en vous assurant qu'elle n'est pas trop profonde, et vous la laissez nager. Vous avez été l'un de ceux qui ont appris à nager, mais ce n'est pas universel (voir sa réponse avec les commentaires). De plus, j'estime que ce type d'approche fonctionne mieux pour les nouveaux arrivants que ceux qui ont déjà des habitudes bien ancrées. Ensuite, non seulement ils doivent nager, mais ils vont également à l’encontre des pratiques établies.
DXM
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.