Désaccord avec le chef de projet sur les normes de codage [clos]

Je travaille donc sur un nouveau projet avec mon chef de projet depuis 1 an.

Au départ, nous avions nos propres sous-projets qui résidaient dans des dépôts git séparés, j'avais peu d'interaction avec son code, donc l'odeur du code ne me dérangeait pas. Quelque 6 mois plus tard, j'ai commencé à maintenir et à ajouter des fonctionnalités à son code, car je jouais un rôle plus important dans le projet.

Maintenant que je suis le développeur principal des deux sous-projets (l'équipe est sur le point de s'agrandir; il est toujours au-dessus de moi), ces choses me dérangent et je voulais m'en occuper, mais on m'a refusé:

1. Pas d'accolades, fonctions capitalisées, utilisation de guillemets mixtes (double et simple avec logique cachée), n'utilisant pas ===, d'énormes classes avec d'énormes fonctions. En bout de ligne, pourrait être mieux.
2. Utilisation de l'option PHP pour désactiver les notifications / avertissements. Le code regorge d'utilisations non contrôlées des variables et des clés de tableau. Les variables sont définies à l'intérieur des ifs.

Arguments aux problèmes ci-dessus:

1. Ne pas vouloir appliquer un style de codage aux personnes.
2. Considéré comme une fonctionnalité de langue, qui se prête à un code plus court / plus efficace.

Je pense que certaines règles doivent être respectées et que le code doit être défensif. J'ai proposé d'utiliser les paramètres par défaut de PHPStorm pour le formatage, d'utiliser des accolades et une convention de dénomination acceptée par la communauté.

Je veux aligner les deux projets pour utiliser les mêmes directives, car elles sont inséparables.

Suis-je dans l'erreur? Dois-je imposer mes préférences personnelles?

Si vous pouvez démontrer clairement pourquoi le vôtre est meilleur (et quels problèmes majeurs peuvent découler de l'utilisation du sien), alors vous n'imposez pas de préférence personnelle, je pense, mais essayez plutôt de mettre en place un projet pour réussir.

S'il peut expliquer pourquoi son état est meilleur et quel genre de problèmes cela empêchera que le vôtre ne le puisse pas, alors il vous a trompé.

La haute direction décente devrait pouvoir en voir le mérite, mais ce sont les points dont ils se soucieront (et devraient) se soucier: pas si c'est plus facile pour les développeurs ou "je ne veux pas forcer tout le monde à travailler comme un robot" (ce qui est un point ridicule, mais ne l'utilisez pas comme un point douloureux pour la haute direction). Ils (devraient) se soucier de la stabilité continue du projet.

Par mon commentaire ci-dessus:

S'il est le chef de projet, cela semble impliquer que c'est essentiellement son appel.

C'était ma pensée. Si vous voulez changer la norme mais qu'il ne bouge pas, soit a) découvrez comment le dépasser, b) allez ailleurs pour travailler, ou c) essayez les petites choses que vous pourriez faire sans l'irriter trop.

Obtenir au- dessus de lui est seulement d' aller travailler si vous faites un dossier solide pour pourquoi il devrait y avoir de meilleures normes.

Fondamentalement:

• vous ne le faites pas comme son style de codage. C'est votre droit.
• il trouve ça bien comme ça et trouve passer des jours / semaines / plus juste ajuster le style est une perte de temps . C'est son droit.

Mettez-vous à sa place. Quels sont les avantages de votre entreprise, en plus de coûter beaucoup d'argent à l'entreprise (votre salaire)? Est-il toujours aussi attrayant? Ne voit-il pas qu'il y a des choses plus importantes à faire en ce moment?

Fondamentalement, vous devez trouver une sorte de compromis avec lequel vous pouvez vivre, sinon votre relation deviendra aigre. Cela dépend aussi beaucoup de la façon dont vous communiquez avec lui. Mettez votre ego de côté et essayez d'être utile ... parce que finalement vous lui demandez des choses que vous aimeriez, pas quelque chose qui l'intéresse. En d'autres termes, vous lui demandez une faveur .

Cela dépend aussi souvent de la façon dont vous demandez. Exemples:

Ce que tu veux:

rendre le code plus joli

Que ne pas dire:

votre code est nul

Quoi dire:

J'apprécierais vraiment si je pouvais rendre les deux projets cohérents, juste les bases, et cela me prendrait juste une journée.

Ce que tu veux:

plus d'avertissements non contrôlés

Que ne pas dire:

votre code est nul

Quoi dire:

Je connais un moyen rapide de se débarrasser de ceci et de cet avertissement. Ensuite, en les réactivant, nous pourrions détecter plus rapidement si quelque chose pouvait se casser à l'avenir.

Et enfin:

Je sais que ce n'est pas une priorité. Je peux donc le faire avec plaisir une fois que les trucs de haute priorité auront été supprimés.

Ou, si cela ne fonctionne pas ou si vous avez une mauvaise relation avec lui, envisagez de partir. Si vous ne pouvez pas trier les choses maintenant, il est peu probable que cela s'améliore à l'avenir ... et mettez votre ego de côté.

Note latérale

Je pense qu'il est plus courant que les personnes âgées soient plus indulgentes. Ils savent que le code sera mis à la poubelle dans une décennie ou deux de toute façon (parce que la technologie change, les API aussi, les équipes, les partenaires commerciaux, les exigences, les décisions mondiales, peu importe ...). Ils ont moins d'ego et se concentrent sur le fonctionnement plutôt que sur la perfection. Même si j'ai tendance à me perfectionner, je ne peux pas leur en vouloir.

Cela va probablement être controversé mais ...

Nous avons discuté et accepté de ne pas être d'accord et de le transmettre à la haute direction

Jamais. Déjà. Faire. Cette. DÉJÀ. Chaque fois que vous faites cela, cela nous fait tous reculer d'une décennie. Voici comment cela se déroulera:

• Cadre supérieur 1: "On nous a demandé de régler ce problème bla, bla, bla, quelque chose sur les normes de codage et la perte de temps."

• Senior manager 2: « Et ils demandent de nous pour résoudre leurs guerres intestines nerd parce que? »

• Cadre supérieur 3: "Parce que ce sont des bébés pleurnichards qui ne peuvent pas communiquer et ne se soucient pas / ne comprennent pas ce qu'est la valeur commerciale? *"

• Cadre supérieur 2: "Ça doit être ça. Qui est pour le golf?"

Vient ensuite vous et le temps d'examen des performances de votre patron:

"[cadre supérieur de votre patron]: je suis désolé, mais il est à craindre que vous ne soyez pas en mesure de gérer vos subordonnés directs et que vous ne suiviez pas les meilleures pratiques (même si je n'ai aucune idée de ce que vous faites, sauf taper du mumbo jumbo qui rend le logiciel fonctionnel) "

"[Cadre supérieur pour vous]: Je suis désolé, mais il est à craindre que vous ne vous sentiez pas bien avec vos pairs et que vous ayez du mal à suivre les instructions de votre supérieur immédiat."

Et c'est pourquoi nous sommes généralement sous-payés par rapport à la valeur que nous créons. **

Vous devez soit A) vous en remettre, soit B) passer à une boutique dont les normes sont un peu plus proches de vos goûts. FWIW, je ferais B (et j'espère passer à une langue qui ne permet pas de telles atrocités). Mais ne jamais escalader un différend technique aux poursuites, sauf s'il s'agit de quelque chose d'illégal ou potentiellement catastrophique (trou de sécurité béant). Simplement ennuyeux ne suffit pas ***.

* Pour le bien des gens qui liront ceci et comprendront mal, je ne dis pas que l'OP et son patron sont comme ça (je me rends compte que la qualité / lisibilité du code a un impact direct sur les résultats de l'entreprise), je dis qu'ils seront perçus comme ça par la direction non technique.

** Pour les personnes qui pensent que mon portrait de la haute direction comme étant un trou du vide est irréaliste, sachez que les gestionnaires se soucient (idéalement) de la gestion des personnes comme nous nous soucions de la gestion du code. Ils peuvent être ignorants sur les questions techniques, mais ils connaissent des gens, et c'est d'autant plus une raison pour leur apporter un différend que A) ils ne sont probablement pas qualifiés pour résoudre et B) vous devriez sans doute avoir pu résoudre sans aide vous fait mal paraître.

*** Oui, je me rends compte que la dette technique peut s'accumuler au point de couler l'entreprise. Je ne pense pas que les accolades vous sauveront (cela étant dit, je n'omet jamais les accolades et je préfère fortement que les autres ne le soient pas non plus).

À mon humble avis, vous êtes confronté à un développeur «ça marche», pas un qui se soucierait que le prochain s'en occupe. Ses arguments sont tout simplement sans valeur.

Tout ce que vous dites à propos de son code n'est qu'une paresse crue de sa part. Avoir des projets suivant la même norme de codage est une question de rigueur. Vous n'êtes pas des robots; vous êtes ingénieurs; vous êtes censé être rigoureux.

Vous pourriez souligner par quelques exemples que vous avez du mal à lire son code, et c'est une énorme perte de productivité pour vous, mais je n'ai aucune idée de comment lui apporter cela.

Mais je vais probablement vous répondre quelque chose est le ton:

Ça marche, inutile de changer

Mon conseil: s'il est vraiment franc et ne veut rien diriger, laissez tomber. Attendez que des erreurs / bugs / évolution se produisent dans son projet. Quand cela arrive, il suffit de corriger et de réécrire la partie du code modifiée / ajoutée de manière appropriée; ne lui allez pas dire quoi que ce soit. Il ne vous imposera pas son style de codage, puisque vous n'êtes pas un robot de toute façon ...

Lorsque vous travaillez sur un projet, vous devez définir des priorités.

La priorité n ° 1 est de vous entendre avec vos collègues. La priorité n ° 1 est suivie d'un énorme écart. Viennent ensuite les priorités pour des choses comme le code qui fonctionne, testable, testé, documenté, maintenable, etc. Vient ensuite un autre fossé énorme, puis viennent les normes de codage.

Et la modification du code existant pour se conformer aux nouvelles normes de codage est vraiment faible sur la liste des priorités.

PS. "Micro-optimisation" vs "ordinateurs ultra-rapides": argument totalement faux. L'argument contre la micro-optimisation n'est pas que les ordinateurs sont rapides, l'argument est que le temps perdu sur les micro-optimisations signifie que vous n'avez pas de temps à rechercher de réelles économies.

PS. Si cela ne vous prend qu'un jour pour apporter des modifications qui améliorent le code pour vous, mais bouleversent votre collègue et font de vous un ennemi, alors vous gaspillez un jour sur quelque chose qui est tout simplement contre-productif.

PHP n'est pas le groupe le plus élitiste de notre profession. En fait, vous critiquez son système logiciel probablement durement gagné. Votre niveau professionnel est plus élevé que le sien.

Ensuite, si vous n'avez aucune marge de manœuvre pour améliorer le code sous vos responsabilités, il n'y a qu'une seule solution: passez à autre chose .

Je ne connais pas le marché PHP actuel chez vous, mais vous pourriez d'abord vous diversifier un peu. Apprenez aussi un langage hype ou un créneau comme C #.

Vous n'obtiendrez peut-être pas un si bon travail, mais vous irez plus loin, professionnellement. Ayez donc de la patience et faites de l'auto-apprentissage. Argent sûr. Demandez alors une certaine marge de manœuvre dans vos projets, ou prenez une offre d'emploi.

J'ai du mal à croire que # 1 est sa vraie raison de ne pas vouloir changer les normes de codage. Si vous possédez la base de code, vous devriez être en mesure d'appliquer les normes de codage que vous (et les autres développeurs) acceptez. Si vous parvenez à un consensus avec les autres développeurs (en supposant que le responsable ne fait plus de travail de développement), il n'y a aucune raison pour qu'il s'en soucie vraiment, sauf pour celui-ci:

La fixation du style de la base de code est-elle la meilleure utilisation de votre temps en ce moment?

Je suis sûr que vous avez des livrables. Combien de temps cela coûtera-t-il pour parcourir et améliorer le style partout dans l'autre base de code? Et si vous introduisez des bogues en corrigeant le style de manière incorrecte? De l' oncle Bob:

Bien sûr, le mauvais code peut être nettoyé. Mais c'est très cher. À mesure que le code pourrit, les modules s'insinuent les uns dans les autres, créant de nombreuses dépendances cachées et enchevêtrées. Trouver et briser les anciennes dépendances est une tâche longue et ardue.

L'amélioration du style de code comme celui-ci n'est presque jamais une bonne utilisation du temps tant qu'élément de sprint autonome . La façon dont j'aime apporter ce genre d'améliorations est ce que j'appelle la "politique du bon voisinage": ne vous contentez pas de réparer tout le style et la structure logique que vous pouvez trouver, car vous investissez probablement autant de temps que vous le souhaitez et vous le ferez toujours ne pas être fait. Au lieu de cela: chaque fois que vous apportez une modification à une partie du code, corrigez le style lorsque vous y êtes et laissez-le mieux que vous ne l'avez trouvé. Si vous avez du mal à implémenter une fonctionnalité parce que le code est mal conçu, corrigez le style pour vous débloquer plutôt que de vous battre la tête.

De cette façon, chaque changement:

1. A une motivation commerciale en plus de la motivation de perfectionnisme technique
2. Ne sera pas considéré comme un investissement de temps important (car ce n'est pas le cas!)
3. Établira de bonnes habitudes stylistiques précisément parce que vous et votre équipe le faites au fil du temps
4. Ne présente pas un risque important pour la base de code car vous ne changez pas trop à la fois

Dans quelques mois, vous lèverez les yeux et remarquerez que le "paquet terrible" n'est plus si mal et votre patron verra que son équipe est plus heureuse. Mais parce que ce n'était pas une confrontation directe, ce sera déjà fait, et il n'aura rien à redire parce que vous n'avez pas perdu de temps (dans son esprit) en ajoutant un grand projet de refactoring à la liste des choses à faire. Il ne vous dira probablement jamais que vous aviez raison, mais ce n'est pas le but de toute façon (non?).

Posez ces questions sur votre piste.

• Sont-ils habitués à travailler seuls ou avec une très petite équipe?
• Ont-ils principalement codé dans ce magasin?
• Sont-ils habitués à prendre des décisions?
• Sont-ils habitués à «tout faire»?
• Ont-ils écrit la plupart du code?

Si les réponses sont «oui», alors je vais brosser un tableau d'un type particulier de programmeur principal. Si cela correspond à ce que vous avez vécu, cela vous aidera peut-être à entrer dans la tête. Sinon, ignorez cette réponse .

C'est quelqu'un qui est là depuis le premier jour, a passé des années au même travail à travailler sur la même base de code, a l'habitude de faire son chemin et n'a pas beaucoup d'expérience avec d'autres moyens.

Ils ne prennent pas en compte les autres lors de l'écriture de code car tout cela a du sens pour eux. Bien sûr, ils l'ont écrit, ou ils ont passé des années à le comprendre.

Ils considèrent que le style de codage est une préférence personnelle, pas un outil pour réduire la maintenance et les bugs. En discutant du style de codage, ils auront du mal à entendre vos arguments, car ils n'ont probablement jamais beaucoup réfléchi à la raison pour laquelle ils font les choses à leur manière. Ce qu'ils vont entendre, c'est "Je veux le faire à ma façon" ou "Je veux le faire de la manière nouvelle, chic et tendance".

Ils sont déterminés à leur manière. Parce qu'ils font la même chose depuis si longtemps tous leurs outils et éditeurs et cerveau micro-configurés exactement à leur style. Tout écart par rapport à ce style entrera en conflit avec cette façon de travailler soigneusement arrangée, mais très fragile. Les tentatives de modification susciteront des plaintes concernant leur éditeur, leurs outils, leur façon de travailler ou leur «difficulté à lire». Ils rejettent le changement parce qu'ils se sont tellement enveloppés dans le statu quo qu'ils ne peuvent pas changer.

C'est quelqu'un qui n'a jamais correctement appris le génie logiciel et l'architecture logicielle. Ils se mélangent juste quelque chose qui fonctionne.

Vous avez un problème humain, pas technologique.

Vous allez devoir recycler votre avance, ou vous devrez arrêter.

Aller à la gestion est un dernier recours . À la fois pour les raisons indiquées par @JaredSmith et parce que vous perdrez. Ce gars a passé des années à gagner de l'argent pour eux. Il a écrit leur entreprise. Il a été victime de nombreux incendies. Pour vous, c'est un chef cowboy qui fait des spaghettis. Pour eux, c'est un héros qui a construit et sauvé l'entreprise.

Pour vous recycler, vous devrez ...

• Gagnez sa confiance.
• Découvrez comment il pense.
• Répondez à ses craintes concernant le changement.
• Rendez le changement plus facile.
• Montrez comment c'est mieux pour lui .

Prenez son style au sérieux et entrez dans sa tête. Demandez-lui à ce sujet. Pourquoi fait-il les choses comme il le fait? Que voit-il en le lisant? Comment interagit-il avec ses outils? Comment se déplace-t-il dans le code? Connaître toutes ces choses vous permettra de comprendre et de répondre à ses objections.

Trouver la racine objective de ses objections subjectives, les rendre exploitables. "C'est difficile à lire" est subjectif, et il ne vous donne aucune information. Vous ne pouvez rien y faire. "Je suis daltonien et la coloration syntaxique ne fonctionne pas" est objectif, il vous donne des informations et vous pouvez faire quelque chose à ce sujet. Je recommanderais un livre intitulé Getting To Yes pour en savoir plus.

Une fois que vous arrivez au problème racine, le vrai problème qu'il rencontre, voyez si vous pouvez le résoudre ou l'atténuer. Alors ce n'est pas un problème. Ils auront probablement encore des problèmes émotionnels avec le changement, mais au moins ils ne peuvent plus soutenir que c'est un problème réel.

Faites-le petit à petit. C'est quelqu'un qui le fait de la même façon depuis des années. Il est habitué à voir certains modèles dans le code et à les utiliser pour le comprendre. Changer soudainement tous ces schémas sera déroutant. Aussi frustrant que cela puisse être de les mettre lentement au courant des bonnes pratiques connues, vous devez le guider.

Préconisez un style communautaire standard. Cela élimine l'argument selon lequel il s'agit de préférences personnelles et les met sous pression pour justifier pourquoi leur style différent est tellement meilleur. Si vous prévoyez d'embaucher, cela facilite l'intégration de nouvelles embauches.

Préconisez le style de code automatisé. Faites suivre le style correct d'une simple pression sur un bouton. Utilisez un outil qui commence par un style standard, vous permet de le configurer selon vos goûts et peut reformuler le code en appuyant sur un bouton. Rendre le style aussi simple que possible supprime de nombreux arguments sur la difficulté de suivre. Ils peuvent coder comme ils le souhaitent, et lorsqu'ils ont terminé, ils poussent un bouton et il suit un style que les autres peuvent lire.

Puisque cette personne n'est pas dans l'état d'esprit de penser aux autres, vous devrez montrer comment ces changements leur sont bénéfiques. Cela peut être aussi simple que «puisque c'est la norme maintenant, vous n'aurez pas à refaire ce combat avec la prochaine personne que vous embaucherez». Ou cela peut être "si nous avons des tests, vous pouvez être plus agressif pour changer le code et vous soucier moins de changer les choses". Ou "s'il existe de bons documents, les gens n'auront pas à vous déranger avec des questions sur le fonctionnement du code". Pour que cela soit efficace, vous devez savoir ce qu'ils veulent - certaines personnes aiment être dérangées, cela les fait se sentir importantes.

C'est une longue, longue route. Vous devrez décider si vous avez la patience de gérer et de recycler votre patron. Considérez-vous davantage comme leur enseignant que leur subordonné frustré, et vous pourriez vous sentir mieux à ce sujet.

Suis-je dans l'erreur?

Je ne connais pas PHP, donc je ne peux pas porter un jugement direct, mais je suppose pour votre argument que votre style de codage préféré est "meilleur" que le code que vous avez rencontré, car le vôtre est plus en ligne avec les outils automatisés existants.

Ensuite, vous n'avez pas tort de suggérer des améliorations au style de codage.

En résumé, pas le code avec lequel je veux travailler

Vous pouvez avoir tort de refuser de travailler avec un code qui ne répond pas à vos normes préférées, mais uniquement dans la mesure où, en travaillant pour l'entreprise, vous avez accepté de travailler avec leur code en premier lieu. En fin de compte, il n'est pas «mauvais» de quitter votre emploi si cela vous impose des exigences qui ne vous plaisent pas, car c'est votre droit, et vous pourriez en conséquence trouver un meilleur emploi.

Dois-je imposer mes préférences personnelles?

Non, il est le chef de projet et vous ne l'êtes pas. C'est son appel, bien que dans ce cas il soit "délégué vers le haut".

Il aurait tout aussi bien pu décider de vous déléguer vers le bas, en tant que développeur principal des sous-projets, et de vous donner la main libre pour définir les normes de codage pour les sous-projets et les collègues qui y travailleront à l'avenir. Mais pour quelque raison que ce soit, il est convaincu que vous ne devriez pas standardiser. Même s'il se trompe sur le style de codage, vous ne pouvez pas vous attendre à revendiquer une autorité qu'il ne vous a pas autorisée.

Cependant, comme il dit "Je n'aime pas appliquer les styles de codage", vous pouvez au moins écrire du nouveau code dans votre style préféré (et vous l'avez fait). En fin de compte, cela pourrait entraîner des opportunités de démontrer les avantages objectifs de votre style. Ce serait le bon moment pour faire un deuxième essai de plaidoyer.

Vous pouvez également (je pense) raisonnablement demander aux personnes qui éditent des fichiers de le faire dans le style que le fichier est déjà écrit. Cela vous permet de maintenir des normes dans les fichiers que vous avez écrits. Malheureusement, le revers de la médaille est que vous devrez modifier les fichiers qu'il a écrits dans quelque chose de similaire à son style.

Même en supposant que vous ayez une très bonne suite de tests et que vous puissiez donc refactoriser en toute sécurité, il y a encore des raisons (certes assez marginales) de ne pas passer au travers et de retaper des fichiers entiers. Le principal est que c'est un cauchemar d'essayer de fusionner, de réordonner ou d'annuler des modifications apportées avant et après un grand changement structurel. Mais il se pourrait bien que, dans ce projet particulier, cela n'arrive presque jamais.

[Mon manager dit qu'il n'aime pas] appliquer des styles de codage aux gens [parce que] nous ne sommes pas des robots.

Vous êtes-vous déjà demandé pourquoi nous ne jetons pas simplement le code source après l'avoir compilé et qu'il passe tous les tests? Le code source est pour les humains, et ce n'est pas seulement pour les humains d'écrire, mais aussi de lire .

Tôt ou tard, quelqu'un aura une raison de revenir en arrière et de lire le code. Peut-être qu'ils devront le changer, peut-être le documenter, peut-être le réutiliser. Peu importe. Cela va arriver, et le code sera beaucoup plus facile à lire et à travailler si tout est dans un style cohérent.

Même un mauvais style vaut mieux que pas de style du tout.