Que faire lorsque vous êtes confronté à une tâche de programmation que vous n'avez jamais effectuée?
J'ai commencé ma carrière en tant que développeur .NET il y a 3 mois et après un long plan de formation sur diverses technologies, modèles et concepts, les développeurs qui me supervisaient ont décidé que je suis prêt à rejoindre l'un des nombreux projets que la société gère.
Je suis très excité de pouvoir enfin commencer à coder. L'équipe que j'ai rejointe est plutôt petite pour l'instant car je commençais avec un nouveau projet, ce qui est génial car je peux m'impliquer dans tout le cycle de vie du projet. Il s'agit d'un projet SPA basé sur le Web avec un support qui utilise l'API Web ASP.NET MVC/ASP.NET et en frontal le framework Durandal et les bibliothèques associées.
Mon problème est qu'après avoir rencontré mes collègues et établi les tâches et les estimations pour le mois prochain, je me retrouve dans une position que je ne sais pas si je suis capable de prendre en charge l'une des tâches.
Je n'ai jamais effectué aucune des tâches créées et je ne sais pas comment procéder.
Par exemple, l'une des tâches créées consiste à créer un mécanisme générique de gestion des erreurs pour l'ensemble de l'application.
Comment procède-t-on habituellement face à des tâches qu'il n'a jamais accomplies?
Vous pouvez et devez faire plusieurs choses pour vous préparer à la tâche:
- Pensez au problème et dessinez des diagrammes. Assurez-vous que vous savez quel est le problème que vous essayez de résoudre.
- Faites des recherches sur ce que vous essayez de faire. Internet est une précieuse source d'informations. Je ne dis pas demander Stack Overflow - je dis faire des recherches sur la façon dont d'autres personnes ont déjà résolu un problème comme le vôtre ou l'ont abordé. Voici ce que Google a proposé: "La gestion des exceptions en tant que problème à l'échelle du système" . Personnellement, j'essaie toujours d'apprendre des autres.
- Enfin, et c'est peut-être le plus important, parlez aux autres membres de votre équipe pour obtenir plus de précisions et de directives sur ce qu'il faut faire. Je veux toujours voir de nouveaux ingénieurs venir demander des conseils sur les projets.
Ne pas savoir comment faire quelque chose ne finira jamais vraiment. Chaque jour, je rencontre des problèmes que je n'ai jamais abordés auparavant. Il est extrêmement important de savoir comment résoudre de nouveaux problèmes. Même les anciens problèmes ne sont jamais totalement anciens - dans la programmation, il y a presque toujours une nouvelle torsion ou une demande pour que votre solution fonctionne d'une manière nouvelle ou différente.
C'est pourquoi je suis ingénieur; J'adore découvrir de nouvelles choses.
N'arrêtez jamais d'apprendre de nouvelles choses. L'apprentissage est ce qui vous rend meilleur.
Il n'y a pas de solution parfaite, mais certaines choses pourraient aider:
Répartissez les tâches en unités les plus petites possibles - décomposez-les jusqu'à ce que vous ayez des choses à faire.
Reformulez la tâche ou le problème immédiat pour vous assurer de bien le comprendre. Ensuite, faites une analyse et répétez.
Choisissez d'abord la tâche la plus simple, même si elle semble trop simple juste pour donner de l'élan. Certaines personnes préfèrent la tâche la plus difficile, donc le "travail acharné" est à l'écart. J'ai constaté que la "tâche la plus simple" fonctionne généralement mieux, car vous cherchez simplement à donner un élan et j'ai vu "le plus dur d'abord" conduire à des projets au point mort avant qu'ils n'obtiennent un véritable élan.
Demandez de l'aide pour sélectionner la bonne tâche et la bonne approche pour commencer.
Cherchez un mentor qui peut vous donner une rétroaction constante (idéalement quotidienne) pendant une semaine ou deux.
Posez beaucoup de questions mais concentrez-vous à être poli avec vos coéquipiers. Demandez-leur toujours s'ils ont le temps, et faites attention aux signes verbaux et non verbaux habituels qu'ils n'ont pas le temps.
Gardez une liste courante des problèmes que vous rencontrez, puis, dans une mêlée quotidienne ou à une heure régulière de votre choix, passez-les en revue avec les autres.
N'ayez pas peur de poser les questions les plus élémentaires. Les hypothèses des autres peuvent être difficiles à remettre en question, mais si vous ne pouvez pas continuer avec ce que vous avez reçu, vous devez à nouveau remettre en question.
Si vous connaissez l'objectif, faites autant que vous le pouvez jusqu'à ce que vous soyez bloqué, puis postez la progression et la question sur Stack Overflow.
Bien sûr, vous ne savez pas comment écrire un "mécanisme d'erreur générique". Personne ne sait comment écrire un "mécanisme d'erreur générique" jusqu'à ce que certaines exigences soient définies. On dirait que tout ce que vous avez, c'est la notion de quelqu'un qu'un "mécanisme d'erreur générique" est en quelque sorte requis pour démarrer ce projet.
Personnellement, je repousserais cette notion. Écrire quoi que ce soit de "générique" avant de mettre en œuvre les besoins réels des utilisateurs est presque toujours une perte de temps. Et comme il est générique , par définition, il n'est pas spécifique à votre entreprise ou application, donc il y a probablement déjà quelque chose qui répondra à environ 95% de votre Besoins.
Mais puisque vous êtes le membre junior, repousser n'est peut-être pas une bonne idée. Vous devez donc parler aux personnes qui pensent avoir besoin d'un "mécanisme d'erreur générique" et savoir quels services elles attendent de ce mécanisme. Recherchez ensuite sur le net pour voir si quelque chose déjà écrit suffira. Si vous trouvez quelque chose, proposez simplement de l'utiliser. Ils ne seront probablement pas d'accord, car quiconque demande un "mécanisme d'erreur générique" souffre probablement d'un mauvais cas de non-inventé ici.
En cas d'échec, l'étape suivante consiste à définir une interface pour le mécanisme d'erreur et à le faire approuver par les parties prenantes. Après cela, la mise en œuvre sera probablement triviale.
=================
P.S. Certains programmeurs pensent que la façon de démarrer un projet consiste à écrire une "plate-forme" pour fournir tous les services communs dont les modules d'application auront besoin. Cela se traduit généralement par des mois de travail trivial réinventant des choses déjà facilement disponibles gratuitement. Jusqu'à ce que vous atteigniez les limites de performances des solutions disponibles, il n'y a aucune raison d'écrire des services de "plate-forme". Il n'y a pas non plus de raison d'écrire des wrappers autour des API existantes. Si vous refactorisez continuellement, le wrapper exact requis par votre application apparaîtra comme par magie.
Je pense que vous souffrez plus d'anxiété que de déficit de compétences. À un moment donné, tout n'était-il pas nouveau? Vous a-t-on déjà confié une tâche et n'avez pas été en mesure de la résoudre dans une certaine mesure? Vous êtes payé pour comprendre les choses.
tilisez votre équipe - Si vous faites partie d'une bonne équipe, vous devriez pouvoir demander de l'aide. Il y a des choses que vous saurez que même les plus âgés ne sauront pas. Demander de l'aide n'est pas un signe de faiblesse (pas plus que de courir sur un site de questions.).
Recherche - Une recherche sur le Web sur la gestion des erreurs génériques n'a rien donné? Vous ne trouverez peut-être pas une solution complète. Vous devrez y travailler et l'adapter de toute façon à votre application.
Prototype - Changez votre point de vue sur la tâche de la production au prototype. Obtenez quelque chose à travailler et à construire à partir de là. Lorsque vous en êtes arrivé au point où vous pouvez l'utiliser, commencez à le considérer comme une production. Maintenant, vous ne verrez pas la tâche comme quelque chose que vous ne savez même pas par où commencer.
Get Over It - Seulement faire des choses que vous savez faire deviendra ennuyeux. Cela vous entraîne également dans un piège de brutalité qui force certaines solutions en répétant les mêmes choses encore et encore (si vous aimez répéter des choses, allez travailler sur une ligne d'assemblage.). Soyez prêt à faire des erreurs. Ceux qui vous disent qu'ils savent tout, ne demandent jamais d'aide ou ne font pas de recherches, ne font que mentir.
C'est la vieille blague sur les médecins qui "pratiquent" encore la médecine; ils n'ont pas non plus toutes les réponses.
Réjouissez-vous que vous ne faites pas quelque chose que vous avez fait cent fois auparavant. Vous avez trouvé la joie du développement de logiciels (pour moi, en tout cas, YMMV) - apprendre à conduire pendant que vous dévalez l'autoroute à des vitesses extraordinaires. C'est le genre de chose pour laquelle un grand développeur vit et excelle.
Mon processus personnel ressemble à ceci:
- Recherche. Découvrez si et comment ce problème, ou un problème similaire, a été résolu auparavant. Même si vous ne pouvez trouver que des informations sur des solutions pour différentes langues ou plates-formes, elles peuvent toujours être extrêmement informatives.
- Prototype. La meilleure façon absolue de faire quelque chose de bien est de le faire mal d'abord. Construisez une solution, tout inventer au fur et à mesure, en fonction de vos recherches. Essayez de le rendre conforme aux exigences principales, en tenant compte des exigences auxiliaires. Ne vous embêtez pas à le rendre joli ou parfait ou extensible ou flexible ou performant, faites-le simplement fonctionner. Prenez note des leçons apprises - ce qui a fonctionné, ce qui n'a pas fonctionné, les obstacles potentiels, etc. Ensuite, jetez le code. Si vous avez peur de regarder un imbécile pour avoir pris trop de temps, faites-le à votre rythme. Cela vous profite personnellement, en termes de connaissances.
- Conception. Combinez vos connaissances externes (recherche) avec vos connaissances personnelles (prototypes de leçons apprises) et formulez une conception de ce que vous pensez être la bonne façon de le faire.
- Coopérer. Trouvez un membre de l'équipe senior, montrez-lui votre conception proposée, obtenez des commentaires. Montrez-le à quelqu'un d'autre, obtenez ses commentaires. Affinez votre design.
- Répéter. Si vous n'êtes toujours pas sûr de votre solution, assurez-vous que les évaluations par les pairs font partie de votre cycle d'itération. Apportez régulièrement votre implémentation à un membre de l'équipe senior pour obtenir des commentaires.
- Soyez heureux - vous avez avancé vos connaissances et votre carrière, et vous devez faire quelque chose de nouveau et d'intéressant au lieu de quelque chose d'ancien et ennuyeux que vous avez fait mille fois auparavant. Essayez de faire de votre prochain projet un défi encore plus grand.
Et enfin, ne vous inquiétez pas trop des apparences. En tant que responsable de l'équipe de développement, je préfère avoir quelqu'un qui peut prouver qu'il peut apprendre tout ce dont il a besoin en fonction de ses besoins, que quelqu'un qui peut prouver qu'il sait déjà la seule chose que nous essayons de faire en ce moment. Les premiers seront plus utiles pour tout ce que nous finirons par faire demain, le mois prochain ou l'année prochaine.