J'attribuerais quelques bogues de faible priorité le premier jour, de cette façon, personne ne crie s'ils ne le font pas tout de suite, ce qui donne au nouveau développeur le temps de se familiariser avec la base de code.
La chose la plus critique à faire est d'avoir une révision du code de tout son travail les deux premières semaines. Vous ne voulez pas savoir que le gars va dans la mauvaise direction ou ne suit pas les normes de codage de l'entreprise des mois durant. Il vaut mieux s'assurer qu'il sait ce qui est attendu dès le début, et les revues de code le garantissent. Bien sûr, je pense que les révisions de code sont bonnes pour tous les employés (nous examinons 100% de notre code avant le déploiement), mais elles sont essentielles pour les nouveaux employés et doivent être effectuées en personne, où vous pouvez répondre aux questions et les référer à la documentation qu'ils n'ont peut-être pas. vu encore si besoin est.
Ce que vous ne voulez pas, c'est qu'un nouveau mec arrive et utilise un style différent du reste d'entre vous. Les gens essaient souvent de continuer à utiliser le style de code de leur travail précédent même s'il entre en conflit avec le style de code utilisé au nouvel emplacement, ce qui peut créer de la confusion et de la gêne de la part des autres développeurs.
Une chose que j'ai remarquée même avec des développeurs expérimentés est que certains d'entre eux ne sont pas aussi bons qu'ils semblaient l'être dans l'interview, la révision du code vous aidera à le découvrir rapidement, afin que vous puissiez le corriger. Cela les encouragera également à faire quelque chose, j'ai vu de nouveaux employés qui ne sont pas soumis à une révision de code faire glisser un projet sans montrer ce qu'ils faisaient à personne, puis partir une semaine avant la date limite qu'ils savaient qu'ils n'allaient pas frapper parce que ils étaient au-dessus de leurs têtes et n'avaient en fait achevé aucune partie du projet. Mieux vaut vérifier tôt et souvent avec de nouvelles personnes jusqu'à ce que vous soyez vraiment sûr qu'ils travaillent.
En outre, il est normal que le nouveau gars soit consterné par l'état de votre projet hérité. Ce n'est pas conçu comme il le pense. Attendez-vous à cela, écoutez-le et ne rejetez pas automatiquement tout ce qu'il dit. En particulier, cette personne semble avoir plus d'expérience que vous ou les autres développeurs, il peut voir des choses que vous n'aviez pas envisagées. Cependant, en tant que responsable, vous devez équilibrer les modifications proposées par rapport à la charge de travail et aux délais actuels. Vous voudrez peut-être tous investir un peu de temps dans l'apprentissage de la refonte du code existant et investir quelques heures dans vos estimations de temps pour le faire, surtout si le nouveau type a des préoccupations valables. Vous ne pouvez probablement pas prendre en charge une réécriture totale (beaucoup de gens qui viennent de nouveau pensent que nous devrions recommencer et faire mieux),
Si vous avez un certain temps où il ne devrait pas contribuer pleinement (et rendre pleinement compte de son temps par le client), cela pourrait aussi être un moment où il peut commencer certaines de ces choses de refactorisation que vous avez voulu faire mais que vous n'avez pas '' t eu le temps de faire. Parfois, c'est une bonne chose d'utiliser la période de formation de la nouvelle personne pour aborder certaines choses qui ne figurent pas dans le plan de projet. Ils peuvent apprendre la base de code et si ce qu'ils veulent faire ne fonctionne pas, vous n'avez pas affecté les planifications existantes car vous ne les avez pas encore prises en compte dans la planification existante. Et si cela fonctionne, vous pourriez avoir un gros gain pour faciliter la maintenance future ou améliorer la sécurité ou quel que soit le problème.