Je travaille actuellement sur un projet utilisant des technologies telles que Silverlight, WCF, EntrepriseLibrary, Unity, Linqtosql, Nunit, Rhinomocks dans .NET 3.5
J'entraîne un nouveau développeur qui possède une expérience avec VB Script et SQL, mais aucune exposition à .NET
Près de 100% du codeBase a une couverture de test unitaire, mais il semble simplement que l'obtention du nouveau développement pour commencer à écrire des tests est trop, il y a suffisamment de choses pour que sa tête soit suffisante, sans la confusion supplémentaire de l'unité tests et moqueurs.
Il a été attribué aux tâches pour mettre en œuvre de nouvelles fonctionnalités à la solution qui coupent toutes les couches, de l'interface utilisateur à la base de données, et comme toujours une demande de client forte pour obtenir la fonctionnalité dans la production dès que possible.
Que pensez-vous que la meilleure approche serait pour obtenir quelqu'un à la hauteur de la vitesse?
13 Réponses :
Avec absolument aucune expérience .Net, je dirais que je vous enlève la tête autour de TDD en même temps que l'apprentissage .NET est un peu beaucoup.
Certaines personnes ayant beaucoup d'expérience .NET ont suffisamment de temps avec TDD - il nécessite un véritable changement d'approche fondamentale du développement. Aller de VB à .NET n'est pas difficile mais cela prend du temps.
Vous voulez vraiment éviter la confusion - TDD est un bon moyen de développer, mais ce n'est pas la way et tdd! = .NET DÉVELOPPEMENT. En fait, il est totalement orthogonal - essayer d'enseigner une nouvelle méthodologie et une nouvelle plate-forme en même temps? Je ne peux pas voir comment c'est une bonne idée.
Apprenez d'abord les bases, puis clouez de nouvelles techniques.
Merci pour toutes les réponses! Je pense que je vais aller avec cette approche, puisque au début, c'est plus amusant de voir du code et de travailler, que de rédiger des tests d'unité qui passent. Je maintiendrai la couverture de test de l'unité moi-même, et cela me donnera une bonne occasion de revoir son code et de lui fournir des conseils à travers les tests que j'écris.
Une chose à la fois. Une fois qu'il a obtenu un peu du .NET absorbé, puis introduisez le TDD. TDD devrait être facile à apprendre après sa familiarisation avec .NET. Si vous lui donnez tout de suite que vous vous en tenez probablement de le confondre totalement
+1 pour la remarque "orthogonale" - TDD & .NET sont deux dimensions.
On dirait que le nouveau développeur traverse déjà un essai par incendie.
On dirait que vous devriez le laisser monter rapidement et commencer à sa part des caractéristiques, donnez-lui de temps à travailler sur eux et, une fois qu'il est confortable ..., commencez-le sur des tests d'unité.
Considérant qu'il y a déjà beaucoup de choses à apprendre, j'ai peur de parler de TDD et de tests automatisés pourrait être un peu "trop": si votre nouveau développeur ne sait pas comment développer, il ne saura pas comment Pour développer des tests - et les tests qu'il va écrire ne sera probablement pas vraiment utile.
Dans votre situation, je le laisserais coder pendant quelques jours / semaines, testant à la main; Et quand il commence à comprendre votre codebase, je passerais du temps avec lui, pour une programmation par paire: ce serait une grande occasion d'introduire des tests automatisés et d'examiner son code / commentaire / amélioration en même temps. < / p>
Je dirais oui - l'ensemble du point de tests est de se concentrer dans une zone. Cela aide effectivement à clarifier la tête et que ce n'est pas comme si cela prend plus de 10 minutes pour apprendre Nunit. Bien sûr, il va probablement lutter un peu avec les concepts pendant un moment, mais un peu de travail acharné et beaucoup de couples devraient surmonter que beaucoup plus facile que de lui jeter des missions sans la guidage que TDD fournit.
Je dirais commencer le programmateur hors de la prise en charge. Comprendre le problème des utilisateurs et la recherche du bogue, la recherche de défauts et la correction apprendront de nouveaux programmeurs comment la demande est assemblée, les tests de rédaction sont davantage sur le nouveau développement.
Si vous avez de fortes moqueries dans votre zone de test, il aura de graves problèmes pour comprendre cela. Toutefois, si vous cédez lui des tâches plus simples (où il n'aurait pas à se soucier de la moquerie) et d'apprendre à découvrir "Que faire mon code?" Cela devrait être faisable.
à un développeur inexpérimenté, le test unitaire semble doubler tout votre code. C'est un coup énorme.
Vous devez vraiment les laisser échouer avant de pouvoir vraiment apprécier les bénifieurs des tests unitaires.
Si c'était moi, je pairais un peu avec lui et TDD. Vous écrivez un test, il écrit le code qui le fait fonctionner puis il écrit le prochain test et vous écrivez le code pour le faire fonctionner, etc.
amusant, vous obtient rapidement, économise du temps et de l'argent.
+1 Si vous utilisez un test d'unité ou TDD dans votre projet. Ensuite, la programmation par paire est la meilleure façon d'accéder à de nouveaux développeurs de votre équipe. Ne changez pas votre processus simplement parce qu'ils sont nouveaux.
Hmm, je ne pense pas que je suis d'accord avec ne pas changer votre processus ... Juste en ce que je me demande si vous recommandez un processus différent de voir si cela pourrait être plus rapide dans certaines situations, ou b) changer à un processus que vous avez trouvé mieux / plus rapide / peu importe dans une situation donnée. De toute façon, je ne suis pas sûr que je viens de respecter aveuglément à un processus donné est une bonne idée. Le point d'agile est de continuer à essayer différentes choses et de garder ceux qui fonctionnent.
Je démarrerais simple - Découpez l'affectation en pièces logiques, puis associez-la avec lui jusqu'à ce qu'il reçoive une compréhension de la partie actuelle. Je ne pense pas qu'une immersion totale dans TDD serait efficace jusqu'à ce qu'un bon niveau de confort soit atteint de sa part, mais cela ne signifie pas que vous ne pouvez pas l'exposer à des tests unitaires et tels.
Peut-être, dans le cadre de vos travaux de préparation, vous pouvez écrire quelques tests qui seront nécessaires pour accomplir la tâche assignée. Comme il travaille dans le problème, vous pourriez le guider vers une solution générale, en utilisant les tests («rouge rouge»! ») Pour démontrer où sa pensée est éteinte.
De là, vous pourriez "conduire" pendant qu'il "navigue" - il définit la fonctionnalité souhaitée et vous pouvez l'interroger sur la manière dont vous pourriez tester cette fonctionnalité. Commencez à écrire les tests avec lui afin qu'il puisse voir la connexion entre les tests et le produit, puis laissez-le prendre lentement.
Espérons que, s'il est bon, il sera capable de saisir les concepts de la terre, puis de déduire comment écrire ses propres tests (avec votre guidage, bien sûr!). La dernière étape que je pense serait de le jeter dans la piscine et de le forcer à écrire les tests dans le cadre de la définition des fonctionnalités qu'il souhaite écrire.
Ce n'est probablement pas un processus rapide, mais j'espère que cela lui donnera une bonne mise à la terre dans TDD / Test de l'unité
Il a été assigné avec les tâches à mettre en œuvre de nouvelles fonctionnalités à la solution qui coupent à travers chaque couche, de l'interface utilisateur à la base de données, et comme toujours il y a un forte demande client pour obtenir le fonctionnalité dans la production dès que possible.
Que pensez-vous la meilleure approche serait pour obtenir quelqu'un jusqu'à Vitesse?
Si vous avez withold Information, il peut jamais monter à la vitesse. Apprends-lui comment vous feriez le travail.
En tant que membre junior de l'équipe, "la forte demande des clients" (c.-à-d. Les problèmes avec le calendrier) ne sont pas son problème: c'est quelque chose que le chef d'équipe et / ou le chef de projet devraient l'abri de .
Vous devrez peut-être éduquer le client: qui apportant un nouveau membre de l'équipe qui n'a aucune expérience antérieure avec les technologies est un investissement qui vaut la peine à long terme.
dans le court terme que vous (ou le client plutôt) peut voir peu ou pas d'avantage immédiat: parce qu'il est lent (apprentissage) et en prenant une partie de votre temps (non indépendant).
imo vous devriez:
ne le faites pas se dépêcher (laissez-le apprendre à le faire bien avant de vous attendre à ce qu'il le fasse rapidement)
Concentrez-vous sur tout nécessaire pour vous assurer que sa production ne dégrade pas la qualité globale des produits livrables du projet (c'est-à-dire que vous devriez certainement lui apprendre et veiller à ce que son horaire le permet, des méthodes de test du développeur et d'assurance qualité que vous avez attendre des développeurs)
Cela dit, Je ne pense pas que le test de l'unité est toujours nécessaire . Mais dans une situation où il s'agit d'un nouveau programmeur (inexpérimenté), et où vous aviez évidemment déjà décidé que la couverture de test de 100% était la bonne chose pour ce projet , je trouve Difficile de voir pourquoi vous envisagez de changer votre processus de développement maintenant pour lui (à moins que ces fonctionnalités qu'il a été assignées ont des exigences de calendrier / qualité différentes des autres fonctionnalités).
sinon maintenant alors quand? Je pense que la ligne de raisonnement que je vois dans cette discussion est une excuse pour ne pas faire des tests unitaires. Il y aura toujours un meilleur programmeur que moi, je serai toujours un meilleur programmeur demain.
Aimant même que "Seuls les développeurs Uber Ninja" devraient faire le test Unitat est le mauvais message à envoyer, surtout si vous valorisez vos statistiques de couverture à 100%.
Le test unitaire enseigne l'une des API du code sous test à l'envers et en avant sans faire de développeur apprendre en faisant des modifications dangereuses non testées au code de production.
Quant au problème de la complexité - le code complexe est un code complexe. Développement de cow-boy sans tests d'unités ne le rend pas plus simple.
Le nouveau développeur ne comprend même pas .net. C'est une énorme quantité d'informations à digérer à la fois. Tout le monde mange plus d'un repas par jour, mais ils ne les mangent pas tous à la fois. Cela vous fait sentir ballonné.
Je pense que le vrai hareng rouge ici est que le questionneur a mentionné toutes les technologies que son application utilise. Si nous avons introduit uniquement le cadre MS de la même manière (avec 100 espaces de noms), je pense que les gens pourraient être réticents à démarrer du tout. L'API de test unitaire est faible par rapport à dire même System.IO et les forces tests unitaires un à regarder le code à tester une méthode à au moment.
Demandez à quelqu'un d'autre d'écrire les tests de l'unité et demandez-lui d'écrire le code pour effectuer le test de test. Une fois qu'il est à l'aise avec cela, vous pouvez le présenter à la création de tests.
Ce que je ferais, c'est dire:
"Nous utilisons TDD ici, que vous allez aussi, mais je veux d'abord que vous vous soyez à l'aise avec l'environnement .NET. Ensuite, dans quelques semaines, nous allons nous asseoir et coder quelques tests unitaires."
Je pense que cela lui donne le temps de digérer.