Tâches typiques d'un développeur Java sur un projet

Quelles sont les responsabilités typiques d’un développeur Java ? Après tout, vous devez comprendre ce que vous recherchez et ce que vous ferez en fin de compte, n’est-ce pas ? Aujourd'hui, je voudrais parler des dix tâches principales qu'un développeur Java effectue. Mais d’abord, faisons connaissance avec un outil comme Jira. Ou rafraîchissons-nous la mémoire si cela vous est déjà familier. Jira est un outil d'interaction utilisateur, même si dans certains cas, il est également utilisé pour la gestion de projet. Autrement dit, le développement du projet se décompose en petites tâches qui sont décrites dans cet outil. Ces tâches sont confiées (attribuées) aux développeurs, qui seront responsables de leur mise en œuvre. Par tâches, nous entendons, par exemple, l'ajout de certaines fonctionnalités. Au fur et à mesure que les progrès progressent, les développeurs et autres spécialistes ajoutent des commentaires sur qui a fait quoi et combien de temps ils ont passé : ils suivent le temps. Ceci est fait afin de suivre le temps passé : combien a été dépensé et pour quoi. Idéalement, cela se fait une fois par jour : le soir avant de partir, vous tracez vos 8 heures selon les tâches auxquelles vous les avez consacrées. Les fonctionnalités de Jira sont beaucoup plus larges que celles décrites ci-dessus, mais cela suffira pour une première compréhension. Alors, quelles sont les responsabilités d’un développeur Java ?

1. Développement de nouvelles solutions

Avant de créer et de mettre en œuvre quelque chose, vous devez le proposer, n'est-ce pas ? Comme je l'ai dit, il se peut qu'il s'agisse simplement d'une tâche Jira qui vous sera assignée, et vous travaillerez au développement d'une nouvelle solution, en notant dans Jira combien de temps vous avez passé et à quoi. Cela pourrait également être une discussion lors d'un appel d'équipe en groupe : chacun pourra exprimer son avis et proposer l'approche qui lui semble la meilleure. Et ici, je voudrais souligner quelques points. Premièrement, le métier de développeur est un domaine très créatif, car il faut trouver des moyens uniques de résoudre des problèmes à l'aide d'outils standards. Souvent, un problème peut avoir de nombreuses solutions différentes : par conséquent, tout dépend de « l'esprit créatif » du développeur, de la base de connaissances et de l'expérience accumulées. Ici, vous pouvez montrer toute votre créativité et votre génie, mais l'essentiel est de ne pas en faire trop : dans ce cas, le code deviendra trop complexe et illisible et par conséquent, après votre départ, personne ne comprendra complètement de quoi il s'agit et Comment ça fonctionne. Et vous devrez tout réécrire à partir de zéro. Et ils se souviendront peut-être de vous. Et plus d'une fois. Et il est peu probable que ce soient des mots chaleureux et gentils. En as-tu besoin? Deuxièmement, le développeur doit être flexible dans le sens où il ne doit pas rester coincé dans une solution et se fermer aux autres. Par exemple, vous ne devez faire que de cette façon et rien d’autre. Cela peut arriver pour diverses raisons : par exemple, vous souhaitez prouver votre point de vue, ou vous avez déjà développé et mis en œuvre votre solution, à laquelle vous êtes assez attaché et, bien sûr, vous ne voulez pas admettre que ce n'est pas la bonne. meilleur. Cela peut vous aveugler. En fait, vous devez être capable d'admettre vos erreurs et d'être toujours ouvert à la nouveauté (« ouverture d'esprit »), même si vous devez supprimer des fonctionnalités que vous écrivez depuis de nombreuses semaines et dont vous êtes très fier. Je me souviens qu'une fois l'ambiance d'une journée entière était créée par le suivi du temps de quelqu'un dans Jira avec le commentaire : « J'ai supprimé ma fonctionnalité mort-née. J'ai pleuré"

2. Écriture de nouvelles fonctionnalités

Il s’agit d’une étape logique faisant suite à la précédente : la mise en œuvre de nouvelles fonctionnalités. Tout le travail sur le projet est divisé en tâches dans un jira, que les développeurs reçoivent au fur et à mesure de leur travail. Il existe différentes approches de ce problème - les «méthodologies», que vous pouvez lire plus en détail dans cet article sur JavaRush . En règle générale, les tâches ont une « estimation » - le temps prévu pour leur achèvement. Il est défini soit par vous-même lorsque vous assumez la tâche, soit par le chef d'équipe, soit lors de la planification, les développeurs l'évaluent ensemble. Cette période est très rarement estimée avec précision, car de nombreux facteurs différents influencent le développement. Par exemple, le programmeur est-il familier ou non avec cette technologie, quelle est son expérience générale, les différents pièges qui peuvent déjà apparaître au cours du développement, etc. Par conséquent, si vous ne respectez pas ce délai lors du développement des fonctionnalités, rien de grave ne se produira. Ce ne sont que des estimations générales. Mais encore une fois, tous les projets n'ont pas d'estimations de tâches et, quant à moi, il est beaucoup plus facile de vivre sans, surtout quand le PM ne vous pique pas plusieurs fois par jour avec la question « Où sont les estimations ? » En conséquence, vous prenez une tâche, développez les fonctionnalités nécessaires, la téléchargez sur une branche commune dans GIT et dans Jira, changez le statut de la tâche en « Prêt pour révision » , c'est-à-dire prêt à être visualisé (vérifié) et priez pour que il ne vous est pas renvoyé avec des commentaires sur la révision.

3. Rédaction de tests de fonctionnalité

La personne qui vérifie votre code - le réviseur - a aimé la fonctionnalité que vous avez développée, mais elle a une question : où sont les tests pour celle-ci ? Et il vous renvoie la tâche pour révision. Les tests sont une partie importante de toute application Java. En les exécutant, vous pouvez immédiatement détecter où l'application ne fonctionne pas correctement. Par exemple, un développeur a apporté des modifications dans une partie du système, ce qui a entraîné des changements de comportement dans une autre, et ne l'a pas remarqué pendant le développement. En exécutant les tests, il pourra voir les tests ayant échoué (ceux qui n’ont pas fonctionné correctement). Cela lui indiquera que quelque chose est cassé dans une autre partie du système. Par conséquent, il ne téléchargera pas les modifications importantes sur le serveur, mais continuera à affiner sa solution. Oui, bien sûr, peu de développeurs aiment les tests, mais on ne peut nier les avantages qu’ils apportent à l’application. Souvent, les clients précisent eux-mêmes à quel niveau de couverture des tests ils doivent adhérer (par exemple, 80 %). Par conséquent, vous devez connaître différents types de tests et être capable de les rédiger. Les développeurs Java écrivent principalement des tests unitaires et des tests d'intégration, tandis que les AQA (testeurs d'automatisation) s'occupent de tests plus approfondis (de bout en bout). Vous pouvez en savoir plus sur eux et sur d'autres représentants des professions informatiques dans ma revue .

4. Trouver et corriger le bug

C'est également une tâche très courante et fréquente pour un développeur Java. La tâche principale du QA et de l’AQA est de détecter les bogues. Autrement dit, ils recherchent les endroits où le programme se comporte incorrectement, créent des problèmes dans Jira et accusent quelqu'un d'autre. Par exemple, un chef d'équipe, qui décide à son tour à quel développeur attribuer cela, en fonction de sa charge et de sa familiarité avec cette partie du système. Après cela, le développeur recherche le bug, passe des heures dans le débogueur , utilisant la description du problème par les spécialistes de l'assurance qualité pour répéter la situation dans laquelle le bug s'est produit. Ensuite, le développeur trouve un bug, le corrige et l'envoie pour examen. Eh bien, il est possible que le développeur n'ait pas pu reproduire le bug et il renvoie la tâche au spécialiste QA avec un commentaire à ce sujet. Il semble que la recherche et la correction du bug ne prendront pas beaucoup de temps, mais il existe quelques nuances. Tout dépend principalement de la familiarité du développeur avec cette section de code, de son expérience et de sa connaissance des questions théoriques. Parfois, un bug peut être trouvé et corrigé en 20 minutes, et parfois cela peut prendre trois jours. En conséquence, ce type de tâche est particulièrement difficile à évaluer à l'avance, à moins que le développeur, après avoir lu la description, ne comprenne immédiatement quoi, où et avec quoi n'a pas fonctionné. Dans ce cas, il pourra deviner l’heure avec plus ou moins de précision.

5. Révision des codes

Comme mentionné ci-dessus, dès que vous terminez une tâche, elle doit être envoyée pour révision, et si elle réussit, elle entre dans le fil de discussion général, sinon elle sera renvoyée au développeur avec des commentaires sur ce qui doit être corrigée. Il est clair que tout cela n'est pas vérifié par certaines puissances supérieures, mais par d'autres développeurs. Mais tous les développeurs ne sont pas autorisés à devenir réviseurs, mais seulement les plus expérimentés, qui ont de la pratique derrière eux et peuvent distinguer le mauvais code du bon. La révision du code est généralement effectuée à l'aide d'un outil auxiliaire, par exemple Crucible . Les réviseurs examinent le code et, si nécessaire, laissent des commentaires sous certaines lignes. Les commentaires peuvent également être de différents types. Par exemple, les commentaires critiques, sans correction desquels le réviseur ne transmettra pas le code, et d'autres sont plutôt de simples commentaires sur l'approche choisie, que le développeur peut écouter, prendre note ou ignorer. L'équipe peut créer sa propre procédure et ses propres règles pour mener des révisions, se mettre d'accord sur ce qui mérite d'être pris en compte et ce qui ne l'est pas, dans quel délai la révision du code doit être effectuée, etc. Pour mener une revue, l'expérience seule ne suffit pas : encore faut-il se développer beaucoup dans le sens technique, lire divers livres (par exemple, « Clean Code » ). Si vous êtes intéressé par les nuances de la réalisation d'une revue de code selon Google, je vous conseille de lire cet article .

6. Analyse des codes

Puisque le projet est écrit simultanément par plusieurs personnes qui pensent différemment, leur code et leurs approches seront différents. Et avec le temps, tout va peu à peu se transformer en bouillie. Pour améliorer le code, vous créez parfois des tâches à analyser, peut-être un module particulier ou l'application entière, pour trouver des failles et les signaler, puis créez plus tard une tâche de refactoring basée sur ces commentaires. L'analyse est également utile dans les situations où certains raccourcis plus simples n'étaient pas visibles dès le début du développement, mais ils peuvent être vus maintenant. Par exemple, la même logique est souvent répétée dans certaines méthodes et, par conséquent, elle peut être déplacée vers une méthode distincte et réutilisée plusieurs fois. Eh bien, soit certaines classes sont devenues douloureusement surchargées, soit certains codes sont devenus difficiles à maintenir ou obsolètes, ou bien... Les tâches d'analyse aident à améliorer la qualité du code et de l'application. Bien que, à mon avis, analyser une grande quantité de code puisse être une tâche ennuyeuse.

7. Refactorisation du code

La partie suivante de l'analyse est la refactorisation du code. Il peut être obsolète, inutile, mal rédigé, difficile à lire, etc. Vous devez toujours rechercher la perfection (même si cela n'existe pas) et un code à jour, en supprimant tout ce qui est inutile, car cela ne fait que vous confondre et vous empêche de voir l'essence de la fonctionnalité. Il va sans dire qu'il est peu probable que vous voyiez ces tâches au début du projet : elles n'interviennent qu'aux étapes ultérieures du développement, lorsque l'application est peaufinée et perfectionnée. Ici, il peut être approprié de consulter des collègues sur la manière dont ils procéderaient et quels pièges ils voient. L’essence de ces tâches est similaire au développement de nouvelles fonctionnalités. Par exemple, vous recevez une tâche pour modifier certaines fonctionnalités sans modifier leur comportement. Pour ce faire, vous supprimez l'ancien, écrivez le vôtre et vérifiez les tests. Si vous avez tout fait correctement, sans apporter de modifications aux tests, ils devraient fonctionner comme avant. Une fois que tout est réglé dans le code, nous l'envoyons pour révision et allons prendre un café))

8. Rédaction de documents

Imaginez que vous êtes un nouveau développeur sur un projet en développement depuis longtemps. Vous devez vous familiariser avec celui-ci ou effectuer une tâche spécifique, par exemple détecter un bug. Comment allez-vous naviguer dans le projet ? Retirer les membres de votre équipe toutes les cinq minutes ? Et s’ils sont occupés ou le week-end, que se passe-t-il ? C'est pourquoi une documentation existe, pour qu'une personne peu familiarisée avec la fonctionnalité puisse y entrer, trouver la bonne page et comprendre rapidement à quoi sert la partie de l'application qui l'intéresse. Mais quelqu'un doit également remplir la documentation ^^ Si le projet a une documentation que les développeurs doivent prendre en charge, lors de la mise en œuvre d'une nouvelle fonctionnalité, ils la décrivent et avec diverses modifications et refactorisations, ils mettent à jour la documentation. Des situations sont également possibles lorsqu'un spécialiste distinct, un rédacteur technique, est embauché pour rédiger, soutenir et contrôler la documentation. Si un tel spécialiste existe, cela facilitera un peu la vie des développeurs ordinaires.

9. Participation à divers rassemblements

Les développeurs consacrent beaucoup de temps à diverses réunions, négociations et planifications. L'exemple le plus simple est celui des « réunions quotidiennes » (réunions quotidiennes), où vous devez dire ce que vous avez fait hier et ce que vous allez faire aujourd'hui. De plus, vous devez avoir un appel individuel, par exemple avec un spécialiste de l'assurance qualité, afin qu'il puisse montrer/expliquer les nuances de la reproduction du bug, ou discuter des nuances et des exigences avec un analyste commercial ou un organisme organisationnel. problème avec un MP. Ainsi, même si un développeur peut être un introverti qui préfère la solitude, il doit quand même être capable de trouver un langage commun avec les autres (enfin, au moins un peu). Plus le rang d'un développeur est élevé, plus il a besoin de temps pour communiquer et moins de temps pour écrire du code. Un chef d’équipe de développeurs peut même consacrer la moitié, voire plus, de son temps de travail à des conversations et des réunions et à écrire du code moins souvent (cela peut conduire à une petite perte de contrôle). Mais si vous êtes aussi quelqu'un qui aime parler, vous pouvez facilement évoluer du poste de chef d'équipe vers le côté managérial et oublier complètement le code, en communiquant toute la journée avec diverses équipes, clients et autres managers.

10. Mener/réussir un entretien

Si vous travaillez pour une entreprise d'externalisation ou de sous-traitance, vous devrez passer des entretiens externes fréquents, lorsque vous devrez être « vendu » au client (vous pourrez alors être interviewé par une personne du côté du client), et des entretiens internes, pour augmentez votre rang au sein de l'entreprise. J'appellerais cela un bon facteur de développement, car grâce à des entretiens fréquents, vos connaissances doivent toujours être en forme : vous ne vous rouillerez pas et ne vous détendrez pas, car si vous vous détendez en informatique, vous pouvez complètement sortir du terrain. Lorsque vous deviendrez un développeur plus expérimenté, vous pourrez visiter l'autre côté : ne pas passer, mais mener des entretiens. Croyez-moi, vous serez très surpris si vous regardez les choses sous cet angle, car mener des entretiens peut être plus effrayant que réussir. Vous devez avoir votre propre stratégie d'entretien, une liste de questions et avoir le temps de poser des questions sur tous les sujets nécessaires en une heure. Et après cela, vous êtes responsable des commentaires, car en s'appuyant sur eux, une personne peut ou non recevoir une offre ou une promotion aussi attendue. Eh bien, et vice versa : vous pouvez manquer un candidat franchement faible pour un poste pour lequel il ne correspond pas, et alors on peut vous demander : comment l'avez-vous même manqué avec un tel niveau de connaissances ? Par conséquent, lorsque vous passez un entretien, gardez à l’esprit que la personne en face de vous traverse également une période difficile et qu’elle peut également être stressée. Tout entretien est stressant tant pour le candidat que pour l'intervieweur. Peut-être que nous terminerons ici. Merci à tous ceux qui ont fini de lire : aimez et apprenez Java ^^