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 dans quoi vous vous embarquez et ce que vous finirez par faire, n'est-ce pas ? Aujourd'hui, je voudrais parler de dix tâches vitales qu'un développeur Java effectue. Mais d'abord, familiarisons-nous avec un outil appelé Jira. Ou rafraîchissez-vous la mémoire si vous le connaissez déjà. Jiraest un outil d'organisation des interactions humaines, bien que dans certains cas, il soit également utilisé pour la gestion de projet. En d'autres termes, un projet est décomposé en petites tâches qui sont décrites dans cet outil. Ces tâches sont confiées aux développeurs, qui sont responsables de leur mise en œuvre. Une tâche peut être, par exemple, l'ajout de certaines fonctionnalités. Au fur et à mesure qu'une tâche est exécutée, les développeurs et d'autres spécialistes ajoutent des commentaires sur qui a fait quoi et combien de temps ils ont passé. Ceci est fait à des fins de suivi du temps - pour savoir combien de temps a été consacré à quelles tâches. Idéalement, cela se fait une fois par jour : Avant de quitter votre bureau le soir, vous indiquez combien de vos 8 heures de travail vous avez consacrées à diverses tâches. Les fonctionnalités de Jira sont bien plus nombreuses que ce qui est décrit ci-dessus, mais cela suffira pour une première compréhension.

1. Concevoir de nouvelles solutions

Avant de créer et de mettre en œuvre quelque chose, vous devez le conceptualiser, n'est-ce pas ? Comme je l'ai déjà dit, cela pourrait simplement être une tâche dans Jira qui vous est assignée, vous travaillez donc pour concevoir une nouvelle solution, en enregistrant dans Jira combien de temps vous avez passé et sur quoi. Ce travail peut également se faire lors d'une discussion sur une conférence téléphonique d'équipe : chacun peut exprimer son avis et proposer l'approche qu'il juge la meilleure. Et ici, je voudrais noter quelques points. Premièrement, le développement de logiciels est une profession très créative, car vous devez utiliser des outils standard pour trouver de nouvelles façons de résoudre les problèmes. Une tâche peut souvent avoir plusieurs solutions différentes. En conséquence, tout dépend de la créativité du développeur, qui est fortement influencée par ses connaissances et son expérience accumulées. Vous pouvez montrer toute votre créativité et votre génie ici, mais l'important est de ne pas en faire trop. Si vous le faites, le code deviendra trop complexe et illisible. Par conséquent, après votre départ, personne ne comprendra parfaitement ce que vous avez codé et comment cela fonctionne. Et ils devront tout réécrire à partir de zéro. Et ils peuvent se souvenir de vous. Plus d'une fois. Et il est peu probable que des paroles chaleureuses et aimables soient prononcées. Avez-vous besoin de ça? Deuxièmement, un développeur doit conserver une flexibilité psychologique dans le sens où vous ne devez pas vous accrocher à une seule solution et devenir fermé d'esprit vis-à-vis des autres. Comme si vous deviez faire quelque chose d'une seule manière et qu'il n'y avait pas d'autres options. Vous pourriez tomber dans ce piège pour diverses raisons. Par exemple, supposons que vous vouliez prouver que votre point de vue est correct. Ou peut-être avez-vous déjà conçu et mis en œuvre votre propre solution familière — bien sûr, vous ne voudriez pas admettre que ce n'est pas le meilleur. Ces situations peuvent vous rendre assez aveugle. En fait, vous devez être capable d'admettre vos erreurs et être toujours ouvert d'esprit, même si vous devez supprimer des fonctionnalités dont vous êtes fier et que vous codez depuis plus d'une semaine. Je me souviens comment un collègue a illuminé la journée de tout le monde une fois en laissant ce commentaire de suivi du temps dans Jira : "J'ai enlevé mon trait mort-né. Et j'ai pleuré."

2. Écrire de nouvelles fonctionnalités

Cette étape - la mise en œuvre de nouvelles fonctionnalités - suit logiquement la précédente. Tout le travail impliqué dans un projet est divisé en tâches dans Jira, qui sont ensuite distribuées aux développeurs en fonction de leur charge de travail. Il existe différentes approches de ce processus, appelées "méthodologies", que vous pouvez lire plus en détail dans cet article sur CodeGym . En règle générale, les tâches ont une estimation, qui est le temps prévu nécessaire pour les terminer. Il est défini soit par vous, le développeur lorsque vous recevez la tâche, soit par le chef d'équipe, soit lors de la planification, collectivement par l'équipe de développement. Cette estimation du temps est très rarement exacte, car de nombreux facteurs différents affectent le développement de logiciels. Par exemple, si un programmeur est familier ou non avec la technologie pertinente, son expérience globale, divers pièges imprévisibles, etc. Donc, si vous n'atteignez pas toutes vos estimations de temps lors du codage, ce n'est pas la fin du monde. Ce ne sont que des estimations générales. Cela dit, tous les projets ne nécessitent pas d'estimation de temps. Personnellement, je trouve qu'il est beaucoup plus facile de s'en passer, surtout lorsque le Premier ministre ne me harcèle pas plusieurs fois par jour avec la question "Où sont vos estimations de temps ?" Donc, vous obtenez une tâche,Prêt pour révision " dans Jira et priez pour que vos modifications de code ne soient pas renvoyées pour révision avec des commentaires.

3. Rédaction d'épreuves

Le reviewer, c'est-à-dire la personne qui vérifie votre code, aime la fonctionnalité que vous avez implémentée, mais il a une question à vous poser : où sont les tests associés ? Elle vous renvoie donc la tâche pour révision. Les tests sont une partie essentielle de toute application Java. En exécutant des tests, vous pouvez immédiatement identifier les endroits où l'application ne fonctionne pas correctement. Par exemple, un développeur apporte des modifications dans une partie du système, ce qui entraîne des changements de comportement dans une autre partie, mais il ne l'a pas remarqué lors du codage. En exécutant les tests, il pourra voir que certains tests ont échoué, c'est-à-dire qu'ils n'ont pas produit les résultats attendus. Cela lui indique que quelque chose est cassé ailleurs dans le système. Sachant cela, il ne validera pas les changements de rupture sur le serveur et continuera plutôt à travailler sur le débogage de son code. Oui, peu de développeurs aiment écrire des tests, mais on ne peut nier les avantages qu'ils apportent au développement de logiciels. Les clients eux-mêmes indiquent souvent le niveau de couverture des tests qu'ils souhaitent maintenir (par exemple, 80%). Cela signifie que vous devez savoirles différents types de tests et être capable de les écrire. Les développeurs Java écrivent principalement des tests unitaires et des tests d'intégration, tandis que les tests plus étendus (de bout en bout) sont gérés par des experts en assurance qualité et en automatisation des tests.

4. Recherche et correction de bogues

C'est également une tâche très courante et fréquente pour les développeurs Java. Le travail principal des experts en assurance qualité et en automatisation des tests consiste à détecter les bogues. En d'autres termes, ils recherchent les endroits où le programme ne se comporte pas correctement, puis ils créent des tâches dans Jira et les attribuent à quelqu'un. Par exemple, à un chef d'équipe, qui, à son tour, décide à quels développeurs les affecter, en fonction de leur charge de travail et de leur familiarité avec les parties pertinentes du système. Après cela, le développeur assigné recherche la cause première du bogue, passant des heures dans un débogueur, en utilisant la description du bogue fournie par les experts QA pour reproduire les conditions dans lesquelles le bogue se produit. Une fois que le développeur a trouvé le bogue et l'a corrigé, il envoie le correctif pour examen. Parfois, le développeur est incapable de reproduire le bogue, il renvoie donc la tâche à l'expert QA avec un commentaire explicatif. Il semble que cela ne devrait pas prendre très longtemps pour trouver et corriger un bogue, mais il y a quelques nuances. Tout dépend principalement de la connaissance que le développeur a de cette section du code, de son expérience et de ses connaissances théoriques. Parfois, un bogue peut être trouvé et corrigé en 20 minutes, et parfois cela peut prendre trois jours. Cela signifie que ce type de tâche est particulièrement difficile à estimer à l'avance, à moins que le développeur, à la lecture de la description, comprenne immédiatement le quoi, où et comment du bogue. Dans ce cas,

5. Revue de code

Comme mentionné ci-dessus, dès que vous avez terminé une tâche, elle doit être envoyée pour révision. S'il réussit l'examen, il entre dans la branche principale. Si ce n'est pas le cas, il est renvoyé au développeur avec des commentaires qui doivent être traités. Bien sûr, vous comprenez que votre code est entièrement vérifié par d'autres développeurs, et non par une puissance élevée. Cela dit, tout le monde n'est pas autorisé à effectuer des révisions de code - seuls les développeurs les plus expérimentés et endurcis par la pratique du monde réel, qui peuvent faire la différence entre un bon code et un mauvais code. Les révisions de code sont généralement effectuées à l'aide d'un outil d'assistance tel que Crucible. Les réviseurs parcourent le code et, si nécessaire, laissent des commentaires sur certaines lignes. Il peut y avoir différents types de commentaires. Par exemple, certains sont critiques. S'ils ne sont pas traités, le réviseur n'autorisera pas la validation du code. D'autres commentaires sont, par exemple, de simples remarques sur l'approche choisie. Ceux-ci, le développeur peut les écouter, en prendre note ou les ignorer. Une équipe peut créer ses propres règles et procédures pour les revues de code, se mettre d'accord sur ce à quoi il faut prêter attention et ce qui ne l'est pas, sur le délai à allouer pour effectuer une revue de code, etc. L'expérience seule ne suffit pas pour mener une revue : vous avez encore besoin de beaucoup développer vos compétences techniques et de lire divers livres (par exemple, "Clean Code").

6. Analyse des codes

Étant donné que plusieurs personnes qui pensent différemment écrivent simultanément du code pour le projet, leur code et leurs approches seront différents. Et avec le temps, tout se transforme peu à peu en désordre. Pour améliorer le code, des tâches sont parfois créées pour, par exemple, analyser un certain module ou l'ensemble de l'application, rechercher et noter les lacunes, puis créer ultérieurement une tâche de refactorisation basée sur cette analyse. Une telle analyse est également utile dans les situations où, lorsque le développement a commencé, l'équipe ne pouvait pas voir de solutions plus simples et plus concises, mais elle les voit maintenant. Par exemple, la logique est souvent dupliquée dans certaines méthodes. En conséquence, il peut être extrait dans une méthode distincte, qui peut ensuite être réutilisée plusieurs fois. Ou peut-être qu'une classe est devenue trop gonflée, ou qu'un code est devenu difficile à maintenir ou obsolète, ou... Les tâches d'analyse permettent d'améliorer la qualité du code et de l'application. Cela dit, pour moi, analyser une grande quantité de code peut être ennuyeux.

7. Code de refactorisation

La partie suivante de l'analyse de code est la refactorisation. Le code peut être obsolète, obsolète, mal écrit, difficile à lire, etc. Vous devez toujours rechercher la perfection (bien qu'elle n'existe pas) et le code à jour, en supprimant tout ce qui est superflu, car le superflu ne fait que créer de la confusion et interfère avec la capacité de voir ce que fait le code. Il va sans dire qu'il est peu probable que vous voyiez ces tâches au début d'un projet : vous les rencontrez à des stades ultérieurs de développement lorsque l'application est peaufinée et perfectionnée. Ici, il peut être approprié de consulter des collègues sur ce qu'ils feraient et sur les pièges qu'ils voient. Au fond, ces tâches sont similaires au développement de nouvelles fonctionnalités. Par exemple, supposons que vous receviez une tâche pour modifier certaines fonctionnalités sans modifier son comportement. Pour ce faire, vous supprimez l'ancien code, écrivez le vôtre et vérifiez les tests. Si vous avez tout fait correctement, sans apporter de modifications aux tests, ils devraient tous passer comme avant. Une fois que tout dans le code est comme il se doit, nous l'envoyons pour un examen et allons siroter un café :)

8. Rédiger des documents

Imaginez que vous êtes un nouveau développeur sur un projet de développement logiciel à long terme. Vous devez vous familiariser avec la base de code ou effectuer une tâche spécifique, par exemple, diagnostiquer un bogue. Comment allez-vous naviguer dans le projet ? Harceler vos coéquipiers toutes les cinq minutes ? Et s'ils sont occupés ou c'est le week-end, et alors ? C'est précisément la raison pour laquelle nous avons une documentation — pour qu'une personne qui ne connaît pas le code puisse entrer, trouver la page pertinente et comprendre rapidement ce qui se passe dans la partie de l'application qui l'intéresse. Mais quelqu'un doit créer la documentation, haha. Si un projet a une documentation que les développeurs doivent prendre en charge, lorsqu'ils implémentent une nouvelle fonctionnalité, ils la décrivent et mettent à jour la documentation avec toute modification ou refactorisation du code. Vous pouvez également avoir des situations où un employé distinct - un rédacteur technique - est embauché pour rédiger, maintenir et superviser la documentation. Si un tel spécialiste est disponible, la vie des développeurs ordinaires est un peu plus facile.

9. Diverses réunions

Une grande partie du temps des développeurs est consacrée à diverses réunions, négociations et planifications. L'exemple le plus simple est la réunion debout quotidienne, où vous devez rapporter ce que vous avez fait hier et ce que vous allez faire aujourd'hui. De plus, vous devrez avoir des appels téléphoniques en tête-à-tête, par exemple avec des testeurs, afin qu'ils puissent démontrer/expliquer les nuances de la reproduction d'un bogue, ou discuter des subtilités et des exigences avec un analyste commercial ou parler de problèmes organisationnels. avec un MP. Cela signifie que même si un développeur peut être un introverti qui préfère la solitude, il doit toujours être capable de trouver un terrain d'entente avec d'autres personnes (enfin, au moins un peu). Plus le rang d'un développeur est élevé, plus il doit consacrer de temps à la communication et moins il passe de temps à écrire du code. Un responsable de développement peut passer la moitié, voire plus, de sa journée de travail sur des conversations et des réunions seules et peut écrire du code moins souvent (ce qui peut lui faire perdre un peu de ses prouesses en matière de codage). Mais si vous aimez simplement parler, vous pourriez, en tant que chef d'équipe, passer à la gestion et oublier complètement l'écriture de code, à la place, vous passeriez toute la journée à communiquer avec diverses équipes, clients et autres gestionnaires.

10. Mener/réussir des entretiens

Si vous travaillez pour une entreprise d'externalisation ou de sous-traitance, vous devrez souvent passer des entretiens externes, où vous devrez vous "vendre" au client (vous pouvez être interviewé par une personne travaillant pour le client), ainsi que des entretiens internes à gravir les échelons au sein de l'entreprise. J'appellerais cela une bonne opportunité de croissance car les entretiens fréquents vous obligeront à garder vos connaissances pointues : vous ne deviendrez pas rouillé et mou. Après tout, si vous devenez mou en informatique, vous pouvez complètement tomber hors du champ. Au fur et à mesure que vous deviendrez un développeur plus expérimenté, vous pourrez vous retrouver de l'autre côté de la table, menant des entretiens plutôt que de les passer. Croyez-moi, vous serez très surpris lorsque vous le regarderez de cette position, car poser les questions de l'entretien peut être plus effrayant que d'y répondre. Vous devez avoir votre propre stratégie d'entretien, une liste de questions et du temps pour poser des questions sur tous les sujets nécessaires en une heure. Et après cela, vous êtes responsable de fournir des commentaires qui influenceront la décision d'embauche et si le candidat reçoit une offre ou une promotion attendue depuis longtemps. Ou, vous pourriez permettre à une candidate manifestement faible d'obtenir un poste pour lequel elle n'est pas qualifiée, et on pourrait alors vous demander, "comment pourriez-vous lui permettre d'être embauchée avec ce niveau de connaissances" ? Ainsi, lorsque vous êtes sur la sellette lors d'un entretien, gardez à l'esprit que la personne en face de vous est également confrontée à un défi et peut être stressée. vous êtes responsable de fournir des commentaires qui influenceront la décision d'embauche et si le candidat reçoit une offre ou une promotion attendue depuis longtemps. Ou, vous pourriez permettre à une candidate manifestement faible d'obtenir un poste pour lequel elle n'est pas qualifiée, et on pourrait alors vous demander, "comment pourriez-vous lui permettre d'être embauchée avec ce niveau de connaissances" ? Ainsi, lorsque vous êtes sur la sellette lors d'un entretien, gardez à l'esprit que la personne en face de vous est également confrontée à un défi et peut être stressée. vous êtes responsable de fournir des commentaires qui influenceront la décision d'embauche et si le candidat reçoit une offre ou une promotion attendue depuis longtemps. Ou, vous pourriez permettre à une candidate manifestement faible d'obtenir un poste pour lequel elle n'est pas qualifiée, et on pourrait alors vous demander, "comment pourriez-vous lui permettre d'être embauchée avec ce niveau de connaissances" ? Ainsi, lorsque vous êtes sur la sellette lors d'un entretien, gardez à l'esprit que la personne en face de vous est également confrontée à un défi et peut être stressée. Tout entretien est stressant à la fois pour le candidat et pour l'intervieweur. Nous finirons probablement ici. Merci à tous ceux qui ont lu cet article. Laissez un like et continuez à apprendre Java :)