Comment codez-vous sans offenser?

Ce que je veux dire par là, comment procédez-vous pour développer sur une base de code que vous partagez avec des développeurs qui y travaillent depuis des années et qui le connaissent très bien?

Je ne veux pas marcher sur les orteils de quelqu'un, mais je ne reçois pas de plaintes si subtiles sur la façon dont je fais les choses, que ce soit la façon dont j'espace mon code, ou la fréquence à laquelle je m'enregistre sur SVN (trop souvent). Donc, bien que je puisse changer ces choses facilement - je veux être un meilleur développeur d'équipe en général.

Je ne sais pas quoi faire, à part demander, mais vous avez peut-être des idées à mettre en pratique.

MISE À JOUR

Il n'y a pas de guide de style à proprement parler - c'est juste que les gens ne sont pas habitués à partager la base de code. Chacun a son propre petit monde de code cloisonné.

Ceci est une boutique Perl, mais je suis sûr que cela s'applique à toutes les langues

MISE À JOUR 2

Le CTO qui devint plus tard PDG était un mégalomane complet et était la principale source de ces plaintes. Si vous ne faisiez pas les choses exactement comme il le voulait, que ce soit avec un Mac ou Emacs, ou 4 espaces de tabulation au lieu de 2, ou habillez-vous d'une certaine manière, vous étiez inférieur. C'était une situation horrible que j'ai essayé de corriger, mais la seule bonne réponse pour moi était de partir.

Je suis convaincu qu'il s'agissait d'un cas d' intimidation en milieu de travail, et par la suite, je suis plus conscient de ce qui pourrait être une intimidation subtile et un comportement inapproprié dans un environnement de travail.

Pour tout développeur à la recherche de réponses à une situation comme celle-ci, partez immédiatement. Vous ne pouvez pas travailler en équipe pour sortir d'une mauvaise situation d'équipe.

Demander. Autrement dit, demandez aux gens avec qui vous travaillez. Faites de votre mieux pour vous en tenir au style établi du code existant. Demandez surtout s'il existe une liste de documents de normes de codage et suivez-la. S'il n'y en a pas, rédigez un premier projet basé sur ce que vous observez dans le code, puis demandez aux autres membres de l'équipe de le critiquer. Vous rendrez service à l'entreprise (et aux nouveaux développeurs qui viendront après vous) en commençant par documenter les pratiques de codage acceptées. Le seul risque est peut-être de se faire prendre au milieu s'il s'avère que les anciens ne s'entendent pas sur ce qui est ou n'est pas acceptable.

Aussi, n'ayez pas peur d' être vous-même . Vous êtes peut-être le nouveau gars, mais vous êtes membre de l'équipe et vos opinions sont valables. Si vous pouvez penser à de meilleures façons de faire quelque chose, suggérez-le. Respectez les autres membres de l'équipe et la façon établie de faire les choses, mais ne les laissez pas vous pousser. L'entreprise ne vous aurait pas embauchée si elle n'avait pas apprécié votre contribution.

Cela vous aidera beaucoup si vous pouvez trouver quelqu'un dans l'équipe qui semble sympathique et particulièrement disposé à répondre aux questions. (Si c'est une bonne équipe, cela devrait être tout le monde, mais les équipes ne sont pas toujours comme ça.) Votre patron peut avoir assigné quelqu'un pour vous aider à démarrer. Utilisez cette personne comme ressource. Écrivez les questions au fur et à mesure qu'elles vous viennent à l'esprit, puis demandez à cette personne utile d'y répondre de temps à autre.

Quant à l'archivage du code "trop ​​souvent", pourquoi ne pas créer votre propre branche pour vos validations périodiques, puis fusionner à nouveau dans le tronc lorsque votre code est prêt? Cela ne fait de mal à personne d'autre et lorsque vos collègues vous voient bénéficier des avantages de SVN qu'ils aimeraient, ils pourraient suivre votre exemple.

En ce qui concerne les espaces blancs: faites-le mais le code le fait déjà. Allez avec le courant.

Concernant les enregistrements SVN: documentez-les très clairement. Cela aide les gens à comprendre ce qui se passe dans le code. (Suivi: Quelles sont leurs objections aux enregistrements fréquents?)

En général: commencez à créer un document standard de codage. N'essayez pas de le remplir avec 100 règles. Ajoutez simplement des règles à mesure qu'elles apparaissent.

Aussi: Posez des questions à vos collègues développeurs. Cela leur donne l'occasion de peser avant de faire quelque chose qu'ils n'aimeront pas. De plus, il établit des relations. De plus, vous en apprendrez plus sur le fonctionnement de la boutique.

En ce qui concerne le style de formatage du code (espace, tabulations, emplacement des accolades, etc.), vous devez suivre la norme en vigueur dans le code. S'il n'y en a pas, je ne pense pas qu'ils aient beaucoup à se plaindre. En fin de compte, que vous mettiez des accolades sur leur propre ligne ou non, placez des espaces autour des listes de paramètres de méthode, etc. est une préférence personnelle, et vous devriez céder au style dominant car à long terme, ce n'est vraiment pas le cas importe . Ce qui compte, c'est d'être cohérent.

Quand il s'agit de vérifier le code dans SVN, j'essayerais d'évangéliser ce que je pense être la bonne façon de faire les choses, plutôt que de me laisser rouler. Je n'archive pas mon code à moins qu'il ne construise et ne passe des tests, et si j'apporte plusieurs modifications non liées, je décompose mon travail en plusieurs validations. Si quelque chose est cassé pendant un moment, je crée une branche et j'y fais mon travail. Les validations obtiennent des commentaires descriptifs. D'après mon expérience, cela fonctionne mieux que la méthode «enregistrer une pile de changements vendredi à 5 h», et il semble que ce soit la «meilleure pratique» en vigueur selon la plupart de ce que j'ai lu ici et ailleurs.

Lisez d'abord leur document sur les conventions de codage (s'ils n'en ont pas, demandez-leur d'en écrire un afin que vous puissiez le suivre)

Ensuite, faites attention et faites un effort conscient pour suivre cela et ce qu'ils disent. Il peut vous sembler qu'ils sont sévères, mais les normes de codage sont importantes, il vaut mieux souligner maintenant ce qui ne va pas plutôt que de le laisser devenir un problème plus tard lorsque vous apportez des modifications plus importantes.

Je suis sûr que vous ferez la même chose dans un an ou deux quand un débutant se met sur vos orteils :)

Demandez les normes du code de l'entreprise. Faites plus attention aux détails. Si vous voyez que d'autres suivent une forme très spécifique d'espaces blancs et de motifs d'accolade, suivez-les. En tant que Sr., vous pourriez dire que c'est un peu difficile, mais en tant que Jr. ou nouveau mec sur un projet, vous devez montrer que vous pouvez suivre avant de pouvoir diriger.

Comprenez également que tout nouveau développeur sur un projet aura en effet un temps de "montée en puissance" nécessaire . Alors ne vous en faites pas.

La meilleure chose que vous puissiez faire est de suivre les conseils qu'ils vous donnent. Il n'y a aucun moyen de dire à l'avance ce qu'ils veulent. Sauf si vous êtes psychique.

Cependant, je dirais que lorsque les gens vous donnent des conseils, vous les documentez. Avez-vous un wiki? Si oui, utilisez-le. Sinon, un fichier texte archivé avec le code source peut être une bonne idée. Élaborez un guide de programmation bien organisé. Cela vous aidera à vous rappeler comment faire les choses, et si quelqu'un contredit les conseils que vous avez reçus précédemment, cela vous donne un point de référence pour discuter de l'incohérence. De plus, lorsque la prochaine personne rejoint l'équipe, elle n'aura pas à passer par ce que vous vivez.

Je suggérerais que vous n'attribuiez pas les conseils dans le document à des individus (donc "les blocs de code devraient être indentés de trois espaces", pas "Bill m'a dit que les blocs de code devraient être indentés de trois espaces"). Cependant, si vous pouvez enregistrer ces informations de manière discrète (par exemple, dans le commentaire de validation, écrivez "règle ajoutée sur l'indentation basée sur les conseils de Bill"), alors cela pourrait être utile pour résoudre les contradictions, car vous pouvez immédiatement obtenir deux points de vue sur quelque chose. Ce à quoi je pense ici, en fait, c'est que si vous recevez des conseils contradictoires, vous devez éviter de devenir un ballon de foot avec deux collègues qui ne sont pas d'accord sur quelque chose. C'est un peu une approche à couvert, mais cela pourrait être prudent.

Le plus simple est de trouver le guide de style et de le suivre. La plupart n'ont rien de trop offensant et vous empêcheront d'offenser les autres.