Je travaille en tant que développeur iOS dans une petite société d'externalisation au sein d'une équipe de 4 personnes. Nous travaillons sur un projet qui a commencé quelques années avant que moi et deux autres développeurs ne rejoignions l'entreprise. Avant cela, le projet était principalement réalisé par une seule personne.

Quand j'ai commencé à travailler sur le projet, c'était un gâchis complet. Il y avait beaucoup de répétition de code. J'ai vu les mêmes 500 codes copiés dans 20 fichiers différents avec des variations mineures. De plus, il n'était pas exactement bien organisé: tout le code de création d'interface utilisateur était mélangé dans les contrôleurs de vue avec la logique.

J'ai fait de mon mieux pour refactoriser les choses ici et là, éliminer les morceaux de code redondants, améliorer la structure des fichiers du projet, etc. C'était comme si le développeur précédent ne se souciait pas vraiment de toutes ces choses ou n'avait pas l'expérience. Il fut un temps où je travaillais seul sur une fonction assez importante pendant quelques mois. En raison de la nature de cette fonctionnalité, j'ai dû toucher beaucoup de code dans toute l'application, j'ai donc essayé d'apporter des améliorations.

Lorsque d'autres développeurs ont rejoint le projet, j'ai remarqué qu'ils utilisent un style de codage différent (parfois un style complètement différent) et n'utilisent souvent pas de fonctionnalités de langage moderne comme les accesseurs de propriété (c'est relativement nouveau dans Objective-C). Parfois, ils inventaient leurs propres vélos au lieu d'utiliser des fonctionnalités similaires du cadre, ou transféraient des concepts à partir d'autres langages de programmation ou de modèles qu'ils avaient appris dans notre base de code. Souvent, ils ne peuvent pas nommer correctement les méthodes ou les variables à cause du mauvais anglais (Objective-C est une langue où vous faites des noms longs).

Parfois, je pense que sans l'IDE, je pense qu'ils écriraient tout le code sans indentation ni mise en forme.

Fondamentalement, je déteste le code qu'ils écrivent. Il est mal formaté / organisé et est parfois radicalement différent du reste du projet. Je me sens très contrarié quand ils ajoutent leurs spaghettis à mon œuvre d'art et cela affecte mon humeur au travail et ma productivité.

On a de plus en plus l'impression qu'ils ne peuvent pas se soucier d'apprendre ou s'en moquent: ils font juste ce qui leur est demandé et rentrent chez eux. J'ai essayé de leur donner quelques conseils lorsque j'en ai eu l'occasion (par exemple, commenté leur PR ou commis sur GitHub). J'ai une fois demandé gentiment de suivre le style de codage et le formatage de la majorité du code existant (malheureusement, nous n'avons pas de document de style de codage formel). Mais ça n'a pas marché ...

Comment puis-je remédier à cette situation sans se concentrer uniquement sur la «mauvaise culture d'entreprise», les «diplômés inexpérimentés», etc. et commencer à améliorer la situation?

Enseignez et pratiquez ce que vous prêchez.

Tu sais que ce truc est important. Vous connaissez l'inconvénient quand ce n'est pas fait correctement.

Maintenant, le défi est de convaincre les autres. Cela ne se fera pas par le biais d'une seule conversation, d'une réunion, de conversations dans le couloir, de conseils ou dans le cadre d'une demande Pull.

Cela nécessite:

• Le public reconnaît par la direction que ces éléments sont importants
• Linters afin que les gens puissent se réunir, hacher et s'entendre sur le style, puis laisser les ordinateurs faire le maintien de l'ordre
• Lead développeurs qui adhèrent pleinement et sont prêts à enseigner aux autres
• Réunions, démonstrations, déjeuner et apprend, etc. pour enseigner ces approches
• Les personnes mesurées sur les éléments de qualité que vous mentionnez lors de leurs évaluations
• Normes documentées et publiées
• Pull demandes ayant de nombreux examinateurs
• Les demandes d'extraction ne sont pas fusionnées tant que la qualité du code n'est pas élevée
• Couplage de code fréquent
• Examens de code de groupe pour les RP complexes

En mots, il faut

Direction

La bonne nouvelle est que toutes ces activités sont généralement reconnues comme de bonnes pratiques.Par conséquent, lorsque vous allez pour les promouvoir ou obtenir l'adhésion de la direction, vous devriez avoir de bonnes chances de réussir et être en mesure de défendre de faire ce qui est juste. Cependant, la direction peut ne pas accepter, c'est un autre sujet et une autre question.

J'ai beaucoup écrit à ce sujet sur SoftwareEngineering.SE dans le passé et j'ai moi-même été dans des situations similaires. Par conséquent, je vais essayer de donner quelques conseils et de souligner quelques problèmes que j'ai notés lors de la lecture de votre question.

Mais d'abord, parlons d'un aspect important: votre rôle dans l'entreprise.

Ton rôle

Vous pouvez avoir un mandat explicite de votre patron pour améliorer les choses, et aussi une place dans la hiérarchie où d'autres développeurs doivent écouter vos commandes . Ou vous pouvez être parmi des pairs, avoir le même rôle et la même autorité, votre option étant seulement ... eh bien ... une opinion .

Dans les deux cas, ce qui compte, c'est moins votre place dans la hiérarchie, et plus:

• Ce que les autres développeurs pensent de vous. S'ils vous traitent comme un gars ennuyeux qui leur demande des choses stupides, vous n'irez pas loin. J'ai vu de nombreux cas où les chefs techniques et les chefs de projet n'avaient absolument aucune influence sur l'équipe, parce que l'équipe savait (ou pensait) que ces «chefs» n'avaient aucune formation technique requise pour prendre les décisions qu'ils prenaient. D'un autre côté, j'ai vu plusieurs développeurs qui ont été écoutés par leurs pairs, car ils savaient que ces développeurs étaient habiles et expérimentés.

• Quelle est la solidité de votre équipe et ce qui la motive. Imaginez une entreprise où chaque développeur est payé pour KLOC / mois. Est-ce que vous diriez quelque chose sur le style à vos collègues? Probablement pas, car rares sont les personnes qui veulent être moins bien payées. En général, si ce n'est pas une équipe mais juste un groupe de personnes travaillant sur le même projet, vous ne pourrez rien améliorer.

En fonction de cela, vous pouvez décider si cela vaut la peine de faire des changements. Si vous n'avez pas de voix et qu'il n'y a pas de cohésion d'équipe, allez simplement chercher un autre emploi. Si vous êtes connu comme un développeur talentueux et respecté et qu'il y a un fort sentiment d'équipe, vous pourrez améliorer les choses relativement facilement, même si vous êtes confronté à l'hostilité de votre patron ou d'autres équipes.

Dans tous les cas, il est essentiel de ne pas faire pression sur votre équipe. Travaillez avec eux, pas contre eux. Ne leur donnez pas d'ordre, mais guidez-les vers l'objectif.

Maintenant, les indices.

Style

J'ai une fois demandé gentiment de suivre le style de codage et le formatage de la majorité du code existant (malheureusement, nous n'avons pas de document de style de codage formel). Mais ça n'a pas marché ...

Bien sûr que non, car ce n'est pas ainsi qu'il faut procéder.

• Le style est ennuyeux .

• Le style suivant est ennuyeux .

• Écrire un document de style de codage est ennuyeux ( et sacrément difficile ; n'essayez même pas de le faire à moins d'avoir travaillé avec la langue pendant plus de dix ans).

• Le document sur le style de lecture est ennuyeux .

• Examiner le code pour les erreurs de style est ennuyeux .

• Trolling que mon style est meilleur que le vôtre est passionnant , surtout quand il n'y a absolument aucun avantage objectif d'un style sur un autre. Sérieusement, chaque personne sensée sait que la bonne façon d'écrire if (x)est la façon dont je l'ai écrit, pas if(x)ou if ( x )!

Donc:

• Ne faites pas de revues de style. C'est le travail des vérificateurs de style. Ces applications mignonnes ont quelques avantages sur votre cerveau: elles vérifient l'ensemble du projet en quelques millisecondes, pas des heures ou des jours, et elles ne font pas d'erreurs et ne manquent pas les erreurs de style.

• N'écrivez pas votre propre style. Vous vous tromperez de toute façon, et vos collègues vous diront que vous avez fait de mauvais choix.

• Ne forcez pas les développeurs à corriger 2 000 erreurs de style.

• Appliquez le style automatiquement lors de la validation. Le code qui comporte des erreurs de style n'a pas sa place dans le contrôle de version.

• Faites-le depuis le début du projet. La configuration du contrôle de style dans un projet existant est difficile, voire impossible.

Pour en savoir plus à ce sujet , lire la première partie de cette autre réponse sur SE.SE .

Aussi:

• Ne soyez pas trop strict. Par exemple, écrire jslintdu code compatible est assez ennuyeux, donc cela devrait être fait exclusivement lorsque cela est absolument nécessaire (ou si tous les membres de votre équipe sont satisfaits de l'utiliser). Il en va de même pour les outils de vérification statique; par exemple, l'analyse de code de .NET au niveau maximum pourrait être très oppressante et déprimante, tout en apportant peu d'avantages; le même ensemble d'outils à un niveau modéré, en revanche, s'avère très utile.

Revues de code

Maintenant que vous n'avez plus à vous soucier du style lors des révisions de code, vous pouvez vous concentrer sur des choses plus intéressantes: améliorer (ou corriger) le code source.

Différentes personnes réagissent différemment aux revues de code. Certains la considèrent comme une opportunité. D'autres détestent ça. Certains écoutent tout ce que vous leur dites, prennent des notes et ne discutent pas, même s'ils peuvent avoir raison. D'autres essaient de discuter sur tous les points. C'est à vous de trouver un moyen de traiter chaque développeur en fonction de sa personnalité. Il est généralement utile de:

• Faites des révisions de code en privé, surtout lorsque le développeur est junior et écrit un très mauvais code.

• Montrez qu'il n'y a rien de personnel: vous passez en revue le code, pas les compétences de la personne.

• Afficher l'objectif réel d'une révision de code. Le but n'est pas de montrer à quel point un développeur est mauvais. L'objectif est de fournir des opportunités d'amélioration.

• Ne discutez jamais. Vous n'êtes pas là pour convaincre, mais pour apporter votre expertise.

• Ne présumez jamais que le candidat est le seul à pouvoir apprendre quelque chose d'un commentaire. Vous êtes ici aussi pour apprendre, à la fois en lisant le code et en demandant des explications sur les parties que vous ne comprenez pas.

Une fois la révision du code terminée, assurez-vous que la personne améliore réellement son code. J'ai eu quelques cas où les développeurs pensaient que la révision du code se terminait à la fin de la réunion. Ils partent et reviennent à leurs nouvelles fonctionnalités, essayant d'appliquer ce que vous avez partagé avec eux uniquement pour le nouveau code. Avoir un outil de suivi décent pour la révision du code aide.

Notez qu'indépendamment de votre rôle particulier dans l'entreprise et de votre expertise par rapport aux autres, votre code devrait également être soumis à révision. Vous ne devriez pas non plus être le seul à revoir le code des autres.

Dans un projet récent où je travaillais en tant que leader technique, j'ai eu du mal à expliquer à mes collègues que c'était leur rôle de réviser le code de chacun, y compris le mien. La peur d'un stagiaire qui s'apprête à revoir le code de son responsable technique disparaît dès qu'il trouve les premiers problèmes dans le code - et qui parmi nous écrit un code sans faille?

Formation

Les révisions de code sont une excellente occasion d'enseigner et d'apprendre certains aspects de la programmation et de la conception de logiciels, mais d'autres nécessitent une formation.

Si vous êtes en mesure de former vos collègues, faites-le. Si votre direction est hostile à l'idée de la formation, faites-le de manière informelle. J'ai fait de telles sessions de formation sous forme de réunions informelles, ou parfois même comme de simples discussions, parfois interrompues par la direction et poursuivies plus tard.

Outre la formation directe, assurez-vous de bien connaître les livres tels que McConnel's Code Complete , et parlez de ces livres à vos collègues. Proposez-leur de lire le code source des projets open source, donnez-leur des exemples spécifiques de code de haute qualité. Et, évidemment, écrivez vous-même du code de haute qualité.

Concentrez-vous sur le contexte, pas sur les personnes

Comment puis-je remédier à cette situation sans se concentrer uniquement sur la «mauvaise culture d'entreprise», les «diplômés inexpérimentés», etc.

Ces diplômés ont un objectif: acquérir de l'expérience, apprendre des choses, devenir plus habile. Si, année après année, ils écrivent du code merdique et ne connaissent rien à la programmation, c'est probablement parce que votre équipe ou votre entreprise ne leur donne pas cette opportunité.

Si vous vous concentrez sur le fait que votre équipe a des diplômés inexpérimentés, cela n'aidera pas. Concentrez-vous plutôt sur ce que vous pouvez faire pour eux et avec eux. Les révisions de code et la formation sont deux des techniques pour améliorer la situation.

La mauvaise culture d'entreprise est une bête différente. Parfois, cela peut être changé. Parfois, ce n'est pas possible. Dans tous les cas, rappelez -vous que vous êtes une partie de cette société, de sorte que vous faites partie de la culture de l' entreprise. Si vous ne pouvez pas le changer et le trouvez intrinsèquement mauvais, tôt ou tard, vous devrez partir.

Obtenez vos mesures à droite

Comment mesurez-vous exactement le code en ce moment? Mesurez-vous le nombre de validations par jour et par développeur? Ou le KLOC par mois et par programmeur? Ou peut-être la couverture du code? Ou le nombre de bugs trouvés et corrigés? Ou le nombre de bugs potentiels détectés par les tests de régression? Ou le nombre de restaurations effectuées par le serveur de déploiement continu?

Les choses que vous mesurez sont importantes, car les membres de l'équipe adaptent leur travail aux facteurs mesurés. Par exemple, dans une entreprise où je devais travailler il y a quelques années, la seule chose qui a été mesurée était le temps que l'on passe au bureau. Inutile de dire que ce n'était pas encourageant de fournir un meilleur code, ou de travailler plus intelligemment, ou ... enfin, de travailler du tout.

Déterminer le renforcement positif et négatif et ajuster les facteurs mesurés au fil du temps est essentiellement l'effet de levier que vous avez sur les membres de l'équipe. Lorsqu'il est fait correctement, il permet d'obtenir des résultats qui ne seront pas atteints par une simple hiérarchie.

Les choses qui vous dérangent les rendent mesurables. Mesurez-les et rendez les résultats publics. Ensuite, travaillez avec d'autres membres de l'équipe pour améliorer les résultats.

Par exemple, considérons que les membres de l'équipe font trop d'erreurs d'orthographe dans les noms des classes, des membres de la classe et des variables. C'est énervant. Comment pourriez-vous mesurer cela? Avec un analyseur, vous pouvez extraire tous les mots du code et, à l'aide d'un correcteur orthographique, déterminer le ratio de mots contenant des erreurs et des fautes de frappe, disons 16,7%.

Votre prochaine étape consiste à convenir avec votre équipe du ratio cible. Ce pourrait être 15% pour le prochain sprint, 10% pour le prochain, 5% en six semaines et 0% en deux mois. Ces mesures sont recalculées automatiquement à chaque validation et affichées sur un grand écran au bureau.

• Si vous n'atteignez pas le ratio cible, votre équipe peut décider de passer plus de temps à corriger les fautes d'orthographe. Ou votre équipe peut juger préférable de calculer le ratio par développeur et d'afficher également ces informations sur grand écran. Ou votre équipe peut trouver que l'objectif était trop optimiste et que vous devriez le revoir.

• Si vous atteignez le ratio cible, l'étape suivante consiste à vous assurer que le nombre d'erreurs et de fautes de frappe n'augmentera pas avec le temps. Pour cela, vous pouvez créer une tâche supplémentaire dans votre build qui vérifie les fautes d'orthographe et échoue la build si au moins une erreur est trouvée. Maintenant que vous vous êtes débarrassé de ce problème, votre grand écran peut être réutilisé pour afficher les nouvelles statistiques pertinentes.

Conclusion

Je crois que chaque aspect mentionné dans votre question peut être résolu grâce aux techniques que j'ai incluses dans ma réponse:

• Lorsque d'autres développeurs ont rejoint le projet, j'ai remarqué qu'ils utilisent un style de codage différent (parfois un style complètement différent)

  Vous deviez appliquer automatiquement le style lors de la validation.

• et n'utilisent souvent pas de fonctionnalités de langage modernes comme les accesseurs de propriété (c'est relativement nouveau dans Objective-C).

  Les révisions de code et la formation sont là pour transférer votre connaissance de la langue.

• Parfois, ils inventaient leurs propres vélos au lieu d'utiliser des caractéristiques similaires du cadre

  Les révisions de code et la formation sont là pour transférer votre connaissance du cadre.

• ou transférer des concepts d'autres langages de programmation ou patters qu'ils ont appris dans notre base de code.

  C’est une excellente chose. Semble être une occasion pour vous d'apprendre d'eux.

• Souvent, ils ne peuvent pas nommer correctement les méthodes ou les variables à cause du mauvais anglais

  Les révisions de code devraient également se concentrer sur une dénomination correcte. Certains IDE ont également des correcteurs orthographiques.

• Parfois, je pense que sans l'IDE, je pense qu'ils écriraient tout le code sans indentation ni mise en forme.

  Bien sûr qu'ils le feraient. Le style est ennuyeux et devrait être automatisé.

• Fondamentalement, je déteste le code qu'ils écrivent.

  Rappelez-vous de la partie des revues de code: «Le but n'est pas de montrer à quel point un développeur est mauvais. L'objectif est de fournir des opportunités d'amélioration. »

• Il est mal formaté / organisé et est parfois radicalement différent du reste du projet.

  Vérification de style automatisée .

• Je me sens très contrarié quand ils ajoutent leurs spaghettis à mon œuvre d'art

  Attends quoi?! Œuvre d'art?! Devine quoi? Certaines personnes (dont vous dans six mois) peuvent trouver votre code loin d'être une œuvre d'art. En attendant, comprenez que considérer votre travail comme une œuvre d'art et leur travail comme de la merde n'aidera personne. En t'incluant.

• On a de plus en plus l'impression qu'ils ne peuvent pas se soucier d'apprendre ou s'en moquent: ils font juste ce qui leur est demandé et rentrent chez eux.

  Bien sûr, ils feront ce qui leur est demandé. Rappelez-vous: le contexte, pas les personnes et obtenez vos mesures correctes . Si le contexte exige d'eux qu'ils deviennent meilleurs dans ce qu'ils font, ils le feront. Si le contexte nécessite de produire autant de KLOC par mois que possible et rien de plus, ils le feront aussi.

Mettez en œuvre des normes de codage et respectez-les, des modèles de conception, une bibliothèque d'extraits de code que l'on peut utiliser comme lignes directrices, etc.

Les normes de codage peuvent aller de la décision d'utiliser des espaces ou des tabulations, des modèles de conception à essayer, des conventions de dénomination, etc. Cela ira un long chemin même si tout le monde code différemment.

Si vous le pouvez, implémentez des normes de codage et des révisions de code - pour commencer la révision à chaque enregistrement. Avec une petite équipe, ce sera difficile à vendre à des gens qui ne comprennent pas que dépenser 2x ou 3x supplémentaires sur votre code à l'avance vous fera économiser 20x ou 30x sur le temps de développement global, mais c'est un autre concept qui vaut la peine d'être acheté -en marche.

Je n'essaierais pas de tout mettre en œuvre en même temps, et je ferais de mon mieux pour les amener à proposer des normes également - pas seulement une indentation, mais essayer de les amener à réfléchir aux choses qu'ils ont rencontrées dans leur code et qui ont rendu leur vie plus facile ou plus difficile.

Pensez à organiser une réunion un jour par semaine pour examiner ce qui a bien fonctionné ou mal pour chaque personne au cours de cette semaine - vous pourriez également offrir à chaque personne la possibilité de dire ce que quelqu'un d'autre a fait de plus utile cette semaine-là - des trucs comme ça . Vous pouvez consulter les livres XP / Agile pour plus d'idées comme celle-ci. Étant une petite équipe, encore une fois, cela pourrait être difficile à vendre.

Vous avez mentionné des problèmes de langue. Si ces travailleurs sont locaux (soit des entrepreneurs sur place ou des employés à temps plein), cela ne devrait pas être trop un problème, mais s'ils sont des entrepreneurs à l'étranger travaillant à distance - permettez-moi de dire que dans mon expérience personnelle, ce n'est jamais va être corrigé, soit le retirer jusqu'à ce que la direction comprenne que cela ne fonctionnera pas, soit envisager de quitter l'entreprise. N'entrez pas dans une situation où vous êtes responsable de leur travail et ne perdez pas de temps à essayer de corriger les pratiques de développement de l'équipe. Très probablement, votre travail évoluera en passant 100% de votre temps à faire fonctionner leur code. De nombreux entrepreneurs à l'étranger sont d'excellents programmeurs, d'ailleurs, je fais juste référence au cas où la société contractante vous a envoyé le type de talent que vous avez décrit.

Les symptômes que vous décrivez suggèrent fortement un manque de cohésion d'équipe .

Dans une telle situation, les normes de codage, la formation, les procédures ou les outils ne seront pas la solution miracle qui pourrait améliorer considérablement la qualité. Il faut d'abord développer un esprit d'équipe, une communication ouverte et constructive et une appropriation partagée du produit.

Symptômes :

• "ils font juste ce qui est nécessaire et rentrent chez eux": ils sont démotivés. N'étaient-ils pas plus enthousiastes à leur arrivée?
• "ils" contre "nous" / "moi" / "je": manque de confiance mutuelle?
• "J'ai donné quelques conseils: j'ai commenté les relations publiques sur Git": le ton des critiques écrites est parfois mal interprété comme agressif ou arrogant malgré une intention constructive. Pourquoi ne pas en discuter face à face?

Vous êtes une petite équipe: profitez de cet avantage! Quelques idées pour commencer:

• Prenez des décisions importantes collectivement. Discutez ouvertement du désaccord. «Discuter» n'est pas d'imposer un point de vue, mais d'écouter et d'essayer de trouver un terrain d'entente.
• Vous avez refactorisé des parties importantes du code, vous avez donc une propriété très forte. Qu'ils adhèrent. Qu'ils aient un mot à dire.
• Et pour les sujets très sensibles mais très subjectifs comme le formatage du code, il suffit d'externaliser le devoir à une jolie imprimante automatisée qui reformatera selon la norme et sans se sentir à chaque enregistrement.

Citation du jour:

Si vous voulez aller vite, partez seul. Si vous voulez aller loin, allez-y ensemble

Vous pouvez répondre à votre question par "Changer votre entreprise ou changer votre entreprise". Pour ceux qui ne le savent pas, cela signifie que vous restez et vous battez pour apporter le changement que vous souhaitez voir dans votre entreprise, ou changer l'entreprise pour laquelle vous travaillez (c'est-à-dire partir et travailler ailleurs).

La deuxième partie est la plus simple. Vous partez et trouvez une entreprise qui partage les mêmes valeurs que celles avec lesquelles vous travaillez. Le premier n'est pas si simple à cause de ... les gens.

Ce que vous devez faire, c'est changer les gens. Penser qu'ils sont cassés et que vous devez les réparer ne fonctionnera pas. Les gens sont des êtres émotionnels. Cela peut facilement dégénérer en guerres personnelles. Donc...

Tout d'abord, vous devez savoir pourquoi la situation est telle qu'elle est. Parlez à tout le monde. Trouver. Ce que vous voyez maintenant est le résultat de décisions prises au cours des années (ou peut-être de ne pas prendre des décisions importantes au bon moment). Ne jugez pas et ne tirez pas de conclusions hâtives.

Cela a-t-il été causé par des développeurs inexpérimentés? Cela a-t-il été provoqué par la tentative de la direction de réduire les coûts en embauchant des diplômés bon marché au lieu de développeurs plus expérimentés et plus chers? S'agit-il de personnes paresseuses et mal intentionnées ou de personnes vaincues par un système brisé? Les délais vous forcent-ils à faire "ce qui doit être fait" pour que cela fonctionne ou les gens perdent simplement leur temps et ne se soucient pas trop de ce sur quoi ils travaillent? etc.

Le problème avec ce domaine du développement logiciel est que les gens apprennent sur le tas. S'ils travaillent dans un environnement de merde, ils prendront de mauvaises habitudes. Et les habitudes ont tendance à coller et à être difficiles à secouer. Ensuite, ils ne savent pas mieux parce que c'est tout ce qu'ils savent. Tous les développeurs ne sont pas passionnés par ce qu'ils font pour investir du temps dans l'amélioration ou la recherche d'amélioration. Certains se sont lancés dans cette entreprise pour diverses autres raisons. Découvrez donc pourquoi les gens sont comme ils sont.

Ensuite, il y a la gestion. La direction n'est-elle pas au courant de la situation ou s'en fiche-t-elle simplement? Trouver. Vous devez absolument avoir le soutien de la direction si vous voulez améliorer les choses. Si quelque chose qui a pris 3 mois à construire tout d'un coup commence à prendre 4 mois parce que vous devez maintenant écrire des tests, faire des revues de code, discuter au tableau blanc avec l'équipe pour décider de bonnes solutions, programme de paire, etc., vous pouvez être sûr que la direction remarquera le décalage horaire. Quelque chose qui passe de 3 à 4 mois est facile à observer et à mesurer. Avoir une base de code solide, un produit maintenable, une bonne architecture stable, des choses qui font une meilleure structure de produit n'est pas si facile à mesurer. Combien de temps les meilleures pratiques vous achètent à long terme ne peuvent pas être mesurées à l'avance, peut-être même pas après coup. D'autre part, un délai d'un mois est une évidence. Ayez donc un soutien de gestion à ce sujet. Préparez-vous à faire une vente difficile.

Regardez également le contexte de l'entreprise. Cela affecte-t-il votre façon de travailler? Avez-vous des opportunités à suivre à tout prix, notamment en sacrifiant la qualité du code ou les meilleures pratiques?

Changeons de perspective un instant.

Je me sens très contrarié quand ils ajoutent leurs spaghettis à mon œuvre d'art et cela affecte mon humeur au travail et ma productivité.

Désolé ... vous quoi? Art? Je sais que la plupart d'entre nous sont ici pour la reconnaissance de nos pairs et vous ne l'obtenez que si vous êtes un bon développeur, mais votre code est-il affiché dans un musée à côté d'une peinture? Doit-il provoquer des émotions chez les personnes qui le regardent? Des larmes de joie et de bonheur? Oui, je suis sarcastique et j'exagère délibérément parce que je veux dire pour garder un sens de la réalité. Ne vous attachez pas émotionnellement à votre code.

J'avais l'habitude de travailler avec un gars qui jetterait volontiers l'équipe, le projet et l'entreprise sous le bus juste pour imposer son "art" à tout le monde. Il était le «détenteur de la vérité» et, par définition, tout le monde était simplement inexpérimenté, aveugle, peu disposé à apprendre, peu soucieux ou simplement stupide. Ne deviens pas ce gars. En tant que développeur de logiciels, votre travail consiste à écrire du bon code, du code testé, du code maintenable, du code qui ajoute de la valeur commerciale et peut continuer à le faire sous de futurs changements constants. Et vous devez faire tout cela avec des contraintes de budget et de temps. C'est ce que signifie être un développeur de logiciels professionnel. À moins que vous ne soyez une galerie d'art, l'art est mauvais pour les affaires. Soyez pragmatique et gardez une vision équilibrée des choses. " Comment ignorer le mauvais code que mes collègues écrivent et se concentrer uniquement sur le travail"Votre question a été fermée à cause de la façon dont vous avez formulé le problème. Reculez et regardez le tout

Comment puis-je remédier à cette situation sans se concentrer uniquement sur la «mauvaise culture d'entreprise», les «diplômés inexpérimentés», etc. et commencer à améliorer la situation?

TL; DR: Regardez attentivement la situation pour savoir pourquoi les choses se sont retrouvées dans cette situation. Acceptez que la situation est comme ça et voyez comment vous pouvez vous améliorer à partir de là. Découvrez ce que tout le monde pense à ce sujet. Choisissez vos batailles. Forcer le changement ne fonctionne pas. Collaborez pour effectuer les changements. Vous devriez essayer de montrer comment les choses peuvent être améliorées sans souligner à quel point elles sont mauvaises. Convainquez tout le monde que ce que vous voulez faire est pour le plus grand bien à long terme. Faites-les monter à bord.

Et faites-le par petites étapes.

Si vous apportez trop de changement d'un coup, les gens se sentiront découragés et abandonneront. Les changements prennent du temps. Changez votre entreprise ou changez votre entreprise. Bonne chance!