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.