Dès que le développeur entre dans l'entreprise et reçoit la tâche, il s'avère le plus souvent qu'il doit rejoindre le projet commun d'une équipe et ne pas écrire son code à partir de zéro.
Tout code a sa propre logique, basée sur certains principes, il y a des modèles et des technologies caractéristiques de l'équipe à laquelle le programmeur s'est joint. Mais comment commencer rapidement à comprendre le projet de quelqu'un d'autre, malgré le fait qu'il soit à peine petit, et souvent il n'y a pas de documentation du tout, ou est-il insuffisant et inexact?
Nous vous rappelons: pour tous les lecteurs de «Habr» - une remise de 10 000 roubles lors de l'inscription à un cours Skillbox en utilisant le code promo «Habr».
Skillbox recommande: Le cours en ligne Frontend Developer Profession .
En fait, la meilleure documentation est le code lui-même et ceux qui ont créé ce code (à condition qu'ils soient encore quelque part à proximité et n'aient pas quitté l'entreprise). Comment puis-je réduire le temps au minimum et me rendre rapidement au travail en apportant ma contribution?
J'ai rencontré à plusieurs reprises cette situation au cours des 15 dernières années de mon travail de programmeur, et voici mes réflexions à ce sujet.
Buts et objectifs du projet
La première chose à faire est de passer un peu de temps à comprendre quelle (s) tâche (s) l'application pour laquelle vous créez du code effectue. Il s'agit d'un défi mondial; après l'avoir résolu, vous ferez face à tout le reste.
Vous ne pouvez pas travailler sur un projet sans savoir pourquoi il est nécessaire. Une compréhension commune vous permettra de comprendre rapidement les petites choses. De plus, votre propre travail sera effectué plus harmonieusement avec le reste de l'équipe. Brique par brique - c'est ainsi que la maison est construite.
L'architecture
Après avoir appris la tâche principale, consacrez-vous à l'analyse de l'exécution du code et de sa logique.
L'architecture de certains projets est assez compliquée, surtout si les technologies de base de ces projets ne vous sont pas très familières. Au tout début, essayez de trouver de la documentation technique (ou demandez à vos collègues à ce sujet) afin de voir la logique de base.
En gardant à l'esprit la structure du projet, vous pourrez commencer à travailler plus rapidement, et afin de ne pas interférer avec le fonctionnement de toutes les autres parties dans lesquelles d'autres membres de l'équipe sont impliqués.
Le projet peut contenir des fragments qui violent la logique générale, mais, connaissant l'idée et l'architecture, vous pouvez résoudre le problème, réorganiser ou changer les "briques" afin qu'elles s'intègrent parfaitement dans le bâtiment général.
Patterns
Il existe un grand nombre de modèles que les développeurs utilisent lors de l'écriture de code. Ce sont des schémas structurels, «comportementaux», technologiques et autres. Tous aident à définir les moyens de résoudre les problèmes courants lors de la conception de programmes.
Comprendre quels modèles sont utilisés dans votre projet actuel aidera, au niveau de la classe, à comprendre comment les fonctions doivent être intégrées dans le code. En conséquence, vous serez en mesure de créer un code cohérent qui correspondra à la logique et aux modèles généraux, ce qui conduira finalement à un nombre beaucoup plus petit de commentaires sur le code, à une meilleure compréhension de celui-ci et à l'élimination rapide des erreurs si nécessaire.
Après avoir un peu travaillé sur le projet, vous serez en mesure de comprendre en un coup d'œil quelles sections de code s'intègrent dans la structure globale, et ce qui nécessite une refactorisation.
Lignes directrices
La plupart des équipes ont certaines règles, ou plutôt un ensemble de règles selon lesquelles chacun agit. Il ne s'agit pas seulement des principes généraux du travail, mais aussi de l'utilisation des classes et des niveaux d'application. Si les représentants de l'équipe sont guidés par les mêmes directives, alors le code développé est plus facile à comprendre et à lire.
Très probablement, l'équipe que vous rejoignez a également des directives que vous devez apprendre. Tout d'abord, ils concernent le langage de programmation, qui est le principal pendant le développement.
Vous pouvez demander où obtenir toutes les informations sur le projet, son architecture, ses modèles et ses directives. Il existe plusieurs méthodes pour obtenir le nécessaire, à l'exception de celles qui ont déjà été exprimées ci-dessus:
- Recherchez toute information, même celle qui peut être considérée comme non pertinente; Construisez votre propre base de connaissances des termes, abréviations et concepts courants utilisés par votre équipe.
- Une fois cette base de données prête, vous pourrez discuter de toutes les questions qui vous intéressent avec le chef de projet, puisque vous parlez déjà la même langue.
- De plus, il convient de discuter avec les architectes d'application et les chefs d'équipe de l'architecture globale de votre projet. Essayez ensuite d'en savoir plus sur cette architecture et les techniques d'optimisation de code qui lui sont associées. Si vous voyez quelque chose qui, à votre avis, viole la logique générale de l'application, assurez-vous d'en discuter avec le chef d'équipe.
- Découvrez auprès de vos coéquipiers quels modèles et règles sont utilisés au cours du travail sur le code - à la fois lors de l'écriture et lors de la maintenance future. Une fois que vous connaissez les principaux points, comparez ce qui fonctionne le mieux et agissez en conséquence à l'avenir.
- Essayez de nettoyer une section de code des problèmes potentiels et réels - cela vous aidera à mieux comprendre le projet et son code. Qu'est-ce que votre équipe utilise pour nettoyer le code?
De manière générale, la refactorisation est la meilleure occasion d'engager votre équipe dans une discussion sur les lignes directrices à réviser et celles à utiliser à l'avenir.
Partagez vos propres développements avec l'équipe, participez activement aux réunions de travail, discutez des problèmes actuels, de l'architecture de l'application et de ses éléments, modèles et autres points importants. Les réunions de travail peuvent être un moyen fiable d'obtenir des informations supplémentaires; cela vaut la peine de parler de leurs observations / réalisations, de ce qui peut être utile à tout le monde.
En conséquence, vous pouvez non seulement commencer rapidement à travailler, mais aussi rejoindre l'équipe, devenant son participant irremplaçable en peu de temps.
Bien sûr, vous rencontrerez des personnes avec lesquelles il est difficile de communiquer; il y aura des problèmes avec le code. Mais cela arrive presque toujours - il y a des équipes où tout est parfait, mais elles sont peu nombreuses.
Skillbox recommande: