Comment vivre et se développer sur des projets avec l'histoire. Qu'est-ce qui donne au développeur l'expérience de travailler avec une grande base de code et pourquoi il n'est pas nécessaire de s'efforcer de tout réécrire à partir de zéro, même si vous le souhaitez vraiment.
Contenu
- À qui est destiné ce texte
- Ce que vous pouvez apprendre d'un projet d'histoire
- Quelles questions poser lors d'un entretien
- Conseils pour ceux qui viennent de commencer à travailler avec un projet hérité
- Brièvement
Je suis Pavel Novikov, je suis impliqué dans le développement d'applications mobiles "MyOffice Documents" et "MyOffice Mail". Il s'agit d'une application de collaboration avec des documents et un client de messagerie, qui a commencé à être créée en 2013, afin qu'ils puissent être appelés projets avec une grande base de code, où il y a une place, y compris l'héritage.
L'expérience décrite ici ne s'applique pas seulement au travail sur des applications mobiles et s'adapte au développement d'applications en général.
Clause de non-responsabilité pour les plus petits
Dans cet article, j'ai rassemblé des réflexions sur mon travail basées sur l'expérience que j'ai à ce jour. Tous les articles de ce type sont toujours très subjectifs. Je suis sûr qu'il y a des gens avec des expériences qui contredisent mes observations. Je serais heureux de discuter de ces écarts dans les commentaires.
À qui est destiné ce texte
Le texte est destiné à la fois à ceux qui se considèrent au niveau Junior et à ceux qui entrent dans la catégorie Moyen / Senior.
Il y a beaucoup à apprendre en travaillant sur des projets de longue durée à tous les niveaux de développement. Pour être sur la même longueur d'onde dans la compréhension des niveaux, lisez les articles de Vastrika: Login et K - Team . J'aime sa catégorisation des niveaux de développeur, et je m'y tiendrai à l'avenir.
Dans le bloc suivant, nous analyserons brièvement quelle est l'utilité de chacun des niveaux sur des projets longs.
Junior
La tâche des développeurs juniors est de maximiser le développement des compétences techniques. Tout est utilisé: langages, frameworks, bibliothèques, approches de développement, etc. Sur n'importe quel projet avec une équipe solide, vous pouvez apprendre à résoudre différents problèmes.
Mais sur les projets matures, d'une part, vous aurez l'occasion de plonger plus profondément dans n'importe quel domaine et, d'autre part, vous serez en mesure d'étudier des exemples de décisions réussies et infructueuses. Apprendre des erreurs des autres coûte cher. Surtout s'il y a des collègues plus expérimentés à proximité qui peuvent vous expliquer en détail la signification de ces erreurs et comment vous pouvez les éviter.
Milieu
La tâche du développeur intermédiaire est d'augmenter son autonomie. Vous devez devenir un membre de l'équipe à qui vous pouvez faire confiance pour presque toutes les tâches du projet. Cela signifie que plus les tâches d'un projet sont variées, plus vous avez de zones de croissance potentielles.
Sénior
Le travail du développeur principal est de bien comprendre que vous n'êtes pas payé pour le code, mais pour résoudre des problèmes. Parfois (encore plus souvent jusqu'à présent) en écrivant du code, parfois en gérant d'autres développeurs, parfois en communiquant avec des non-développeurs. Les projets arrivés à maturité ne sont qu'une réserve de tâches qui peuvent et doivent être résolues.
Ensuite, j'entrerai plus en détail sur certaines des choses que vous pouvez apprendre des projets existants.
Et ici Legacy?
Vous devez d'abord comprendre la terminologie. Le concept d '«héritage» a acquis une connotation négative depuis longtemps, mais à quoi sert exactement le code hérité?
Michael Feathers, fondateur de R7K Research & Conveyance, soutient que le code hérité est un code non couvert par les tests. L'avantage de cette approche est qu'à première vue, elle se veut objective. Mais en réalité, il peut y avoir deux scénarios:
- Il y a des tests, mais ils sont mal écrits: déroutants, fragiles, pas visiblement structurés.
- Aucun test, mais le code est très bien conçu. Cela permet de le changer de manière relativement sûre et, dans ce cas, cela vous permettra d'écrire rapidement des tests pour celui-ci à l'avenir.
Un autre regard sur l'héritage du développeur Dro Helper (Dror Helper): n'est plus conçu - continuellement patché et piraté ("Legacy code - code - code qui est constamment cassé et soutenu avec des béquilles au lieu de le développer") ...
Le développeur Web Nicolas Carlo pense que le code hérité est un code inconfortable avec lequel travailler.
De tout cela, nous pouvons conclure que l'héritage est plutôt une caractéristique subjective du code. Le code lui-même peut ou non fonctionner, mais il deviendra hérité lorsqu'un développeur apparaîtra qui ne pourra pas le modifier efficacement.
Une autre caractéristique relativement objective pour évaluer Legacy est la réponse à la question "Y a-t-il des dépendances non prises en charge dans le projet?" Le code ne peut être généré que par certaines versions de compilateur obsolètes spécifiques. Ou les auteurs eux-mêmes ont patché une bibliothèque externe, qui fait maintenant partie du projet principal. Dans ce cas, en effet, le projet devient spécifique et des efforts supplémentaires sont nécessaires pour le soutenir.
En général, si le projet a plus de six mois, il contiendra probablement un héritage.
Que pouvez-vous apprendre d'un projet d'histoire?
Donc, vous avez pris une décision et obtenu un emploi dans une entreprise où le code était déjà écrit avant vous et où beaucoup d'autres choses se passaient. J'ajouterai que vous n'avez pas besoin de vous rendre dans un nouvel endroit pour mettre à jour vos profils. L'héritage est le plus probable dans chaque projet, il vous suffit de savoir comment l'évaluer. Et ce dont je parle peut certainement s'appliquer aux choses sur lesquelles vous travaillez actuellement.
Dans quels domaines le pompage sera-t-il également utile pour vous et pour le projet? Ici, vous devez comprendre que la situation dans laquelle vous développez où le projet fait mal est un environnement idéal pour une croissance mutuelle. Parce que si vous vous développez en travaillant sur des choses de gauche, cela peut être un plus pour vous personnellement, mais en même temps, il sera difficile d'expliquer pourquoi l'entreprise devrait vous aider.
Analyser le projet
La première chose que vous pouvez apprendre d'un projet patrimonial est de l'analyser. Disons que vous êtes arrivé à un projet où il y a des lacunes dans la documentation, ou il n'y en a pas du tout. Dans ce cas, vous n'aurez que le code source du projet, il est donc essentiel de pouvoir l'analyser et comprendre rapidement sa structure et son essence. Ceci est important car plus tôt vous apprendrez à y naviguer, plus tôt vous commencerez à profiter du projet.
La chose la plus importante que je puisse recommander pour une compréhension plus approfondie de l'analyse du projet est de lire le livre "Un travail efficace avec le code hérité" de Michael Feathers. Elle est vieille et célèbre. Il décrit un grand nombre de pratiques pour travailler avec du code hérité.
Une autre astuce consiste à visiter le site Web Comprendre le code hérité .... Ceci est un blog dédié à un sujet - travailler avec l'héritage. Il est important que vous puissiez vous y abonner à la newsletter. Je suis sûr que de nombreux développeurs Android connaissent les mailings Android Weekly et Kotlin Weekly. Le bulletin d'information ULC est également très utile. Ce n'est pas intrusif, avec des articles pratiques sur la refactorisation et le codage.
Refactoriser
Les projets hérités sont un excellent endroit pour mettre en pratique vos compétences de refactoring. Vous arrivez à un projet qui a très probablement des problèmes, et vous devez non seulement le changer, mais aussi l'améliorer, le développer et voir de nouvelles fonctionnalités. La qualité et l'efficacité de la refactorisation (rapidement et avec peu de régressions) détermineront à quel point vous êtes utile et bon développeur.
Dans un projet mature avec une culture d'ingénierie saine, la refactorisation doit faire partie intégrante du développement.
Vous devriez aimer le produit sur lequel vous travaillez. Parfait si vous pouvez l'utiliser vous-même. Dans ce cas, vous aurez une motivation interne pour travailler sur l'amélioration de sa qualité pendant longtemps.
Concevoir et construire l'architecture
Ce point découle du précédent - vous aurez inévitablement besoin de pomper dans la conception et l'architecture logicielles. Avec la bonne culture de développement, vous n'aurez pas à prendre de décisions architecturales majeures dans des délais serrés. Vous aurez le temps de concevoir l'architecture et il sera de votre responsabilité de bien le faire. Qu'est-ce que je recommande toujours ici? Lire des livres.
Je trouve que les livres sont tout aussi importants que d’autres sources d’information. Plus vous acquérez d'expérience dans les livres, plus vous comprendrez rapidement comment résoudre les problèmes courants. Il existe toujours des solutions typiques aux problèmes typiques / typiques que l'on peut trouver dans les livres. Travailler avec tout type d'héritage implique également de résoudre des problèmes typiques.
(Robert C Martin). « », « »
(Martin Fowler). «. »
UML — .
PlantUML (PUML) — , UML-. git, , .
Lorsque vous travaillez avec un produit que vous ne comprenez pas parfaitement, vous devrez en quelque sorte apprendre à évaluer le travail à effectuer. Et vous aurez toujours quelque chose que vous ne connaissez pas, des écueils.
La capacité de décomposer une tâche vaste et complexe en un ensemble de petites pièces interconnectées est une compétence très précieuse. Une façon de le développer est de travailler rétrospectivement en continu sur les erreurs de décomposition et d'estimation. Au cours du processus d'analyse, vous pouvez créer une liste de contrôle à partir des erreurs courantes. À l'avenir, il pourra vous aider à éviter à nouveau ces erreurs.
Automatiser et pouvoir appliquer CI / CD
Vous devez comprendre ce qui arrive à votre code depuis le moment où vous l'écrivez jusqu'au moment où il atteint l'appareil de l'utilisateur. Et vous aurez la possibilité d'automatiser et de CI / CD pour personnaliser, maintenir et améliorer. Dans les entreprises où il n'y a pas d'équipe d'infrastructure dédiée, ces opérations peuvent et doivent (j'en suis convaincu) être décidées par les membres de l'équipe de développement de base. Les outils modernes (cloud CI, Docker) ne sont pas incroyablement complexes, mais ils simplifient grandement la vie de l'équipe. Vous pouvez faire beaucoup de bien pour elle si vous maîtrisez ces compétences.
Communiquer
Plus vous avez de responsabilités, plus vous aurez à communiquer avec de personnes. Le développement logiciel a depuis longtemps cessé d'être le lot des individus: presque tous les grands projets sont réalisés par des équipes. Encore une fois, plus vous apprenez à interagir efficacement avec ceux qui vous entourent, plus vous pouvez apporter d'avantages.
Vous devrez communiquer avec des personnes plus intelligentes et plus expérimentées que vous. Dans les grands projets, il y a toujours des «anciens» dont on peut apprendre beaucoup. De plus, vous rencontrerez des gens plus bêtes que vous. La bonne nouvelle est que vous vous trompez probablement sur vos capacités mentales - il est très utile de pouvoir corriger de telles erreurs de perception.
Je crois que le développement des compétences en communication peut être réduit au développement d'un sentiment d'empathie. Mieux vous apprenez à comprendre les motivations et les objectifs des personnes qui vous entourent, plus vite vous pouvez leur devenir utile. Par exemple, lorsque vous expliquez à une entreprise les avantages de la refactorisation et du travail sur la dette technique, vous devez utiliser des termes commerciaux et non des termes de programmeur. Idée apparemment évidente, mais j'ai vu à plusieurs reprises comment certaines personnes intelligentes communiquent avec d'autres personnes intelligentes et ne peuvent pas se comprendre.
Quelles questions poser lors d'un entretien
Ici, je partirai des questions que je poserais avant d'aller travailler sur un projet que je connais peu.
Comment fonctionne le workflow et pourquoi exactement
Habituellement maintenant, ils travaillent sur des systèmes Scrum ou Kanban. Mais en même temps, ils les adaptent souvent pour eux-mêmes: "ils ont pris le meilleur, ont jeté le superflu". La question est: qu'est-ce qu'ils ont jeté exactement et qu'ont-ils laissé? Parce que le guide Scrum, sur la base duquel le processus de développement est construit, a des pratiques assez intéressantes et utiles.
Ils ont un sens lorsqu'ils sont appliqués, premièrement, consciemment, et deuxièmement, tous sont appliqués. Parce qu'ils constituent un tel système qui se contrôle et vous permet d'améliorer de manière itérative non seulement le projet, mais également vos propres processus.
Par exemple, si l'équipe travaille sur Scrum, je demanderais ce qui a été discuté lors de la dernière rétrospective. Dans quelle mesure l'équipe est-elle active lors de cette réunion? Les problèmes soulevés sont-ils traités?
Autre question intéressante pour moi sur les processus internes: comment se déroule la revue de code dans l'équipe? Existe-t-il des règles internes pour mener un examen qui peuvent aider à réduire son temps? Existe-t-il une base de connaissances commune où les résultats des holivars sont saisis afin de ne pas les satisfaire à chaque fois?
Comment fonctionne la planification, qui est impliqué et dans quelle mesure l'équipe est active
C'est une question que je poserais pour voir à quel point la culture d'ingénierie est forte au sein de l'équipe. Il y a une option lorsque seul le chef d'équipe planifie et que l'équipe est de son côté.
Une autre option est lorsque toute l'équipe participe à la planification. Et quand une tâche vient, il est entrepris de la peindre par quelqu'un qui a suffisamment d'expertise en la matière. Et puis ils discutent tous et prennent une décision. Cela rend l'équipe plus auto-organisée et le flux de travail plus agréable.
Combien de personnes dans l'équipe ont une vue d'ensemble
Deux extrêmes sont possibles ici. Le premier extrême se produit lorsque vous rejoignez une équipe qui travaille sur un produit depuis 2 à 4 ans. Si en même temps l'équipe n'a pas beaucoup changé, mais s'est seulement élargie, c'est très bien, car vous aurez toujours des personnes vers qui vous pouvez demander de l'aide. Ils pourront vous suggérer quelque chose, expliquer la raison, vous raconter l'histoire du projet. Connaître le contexte et pourquoi tout est organisé de cette manière et pas autrement est très important.
Le deuxième extrême est lorsque vous arrivez dans une équipe qui n'a aucun de ceux qui étaient au départ. Par exemple, le projet a été gelé, il n'a pas été gelé et une grande base de code est restée. Vous ne pouvez pas réécrire à partir de zéro. En conséquence, il est nécessaire de restaurer le développement. Autrement dit, vous obtenez un projet dans lequel vous devrez tout déterrer à nouveau.
Sur la base de ces informations, vous serez en mesure de prendre une décision plus éclairée quant à savoir si vous voulez y aller ou non, et peut-être surestimer certaines de vos exigences pour les propositions auxquelles vous devez répondre.
Comment est maintenu l'arriéré de la dette technique
Il y a des problèmes dans n'importe quel projet et il est important de comprendre comment l'équipe travaille avec eux. J'ai très bien écrit sur le travail avec la dette techniqueAlexanderlebedevdans l'article «Les Lannisters paient toujours leurs dettes! (et technique aussi) " .
Si l'équipe connaît les problèmes, mais ne sait pas comment travailler avec eux de manière systématique, c'est un mauvais signe. Mais vous pouvez voir cela et comme une opportunité de devenir la personne qui aidera à résoudre ces problèmes.
Conseils pour ceux qui viennent de commencer à travailler avec un projet hérité
Résistez à la tentation de vous précipiter pour tout réécrire à partir de zéro
Une situation courante: vous commencez à travailler sur une application existante et constatez que tout est "mal" fait. Et avec ce "pas si", vous devez travailler plus loin. C'est un désir tout à fait naturel dans ce cas - de le reprendre et de le réécrire à nouveau. C'est une réaction normale.
Je pense que c'est basé sur le refus de répondre des erreurs des autres. Après tout, si après vos modifications de nouveaux défauts apparaissent, vous devrez le découvrir. Il vaut mieux alors le réécrire complètement, et tout ira bien.
Si vous remarquez que vous avez de telles pensées, posez-vous quelques questions:
y a-t-il vraiment suffisamment de problèmes dans le code, ou vous ne le comprenez tout simplement pas encore?
Êtes-vous sûr de comprendre exactement tous les points d'intégration du code réécrit?
Connaissez-vous suffisamment bien le projet pour prédire avec précision le temps de travail à venir?
Bien que je sois convaincu que l'intention de se précipiter immédiatement pour tout réécrire à partir de zéro est une mauvaise idée. Les améliorations doivent être itératives et gérables.
Une fois que j'ai été témoin du moment où l'équipe a dit: «C'est de la connerie, réécrivons», ils ont copié pendant six mois et n'ont pas réécrit. En conséquence, une situation assez intéressante s'est développée lorsque le projet a dû être à nouveau mené à partir de zéro, pour recruter une nouvelle équipe, car l'ancienne équipe était tombée. Essayez d'éteindre cette envie complètement naturelle de tout refaire à partir de zéro.
Prédire les changements de projet
Vous devez apprendre à être un peu un oracle. En travaillant sur un projet pendant une longue période, vous apprendrez à comprendre sa composante produit, à comprendre l'entreprise, comment ce projet gagne, comment il vit. Cela vous donnera l'occasion d'évaluer la perspective à long terme des décisions que vous prenez.
C'est une compétence très utile, car c'est une mauvaise situation lorsque le product owner vient vers vous et vous demande de faire quelque chose de simple de son point de vue. Par exemple, ajoutez un nouveau critère pour trier la liste. Et de votre côté, cela signifiera que vous devrez réécrire tout ce composant. Cela ne serait pas arrivé si vous aviez pensé à l'avance que différentes manières de trier cette liste sont une fonction parfaitement logique. Bien qu'on ne lui ait pas demandé de le faire en premier lieu.
N'allez pas aux extrêmes et essayez de toujours prendre les décisions les plus universelles. Il s'agit d'un chemin direct vers le dépassement du temps et les problèmes avec un soutien supplémentaire pour de telles solutions. L'intérêt de cette compétence est précisément de trouver un équilibre.
Faire des recherches
Lorsque vous travaillez sur un long projet, il est important de savoir dans quelle mesure l'entreprise fait confiance à l'équipe. Avant de développer une fonctionnalité majeure, nous menons définitivement une recherche complète sur le sujet. Cela peut ressembler à un capitaine de capitaine, mais je connais des cas où des gens se sont immédiatement précipités dans le maelström avec leur tête, et des tâches apparemment simples se sont transformées en de longues refactorisations qui auraient pu être évitées simplement en faisant des recherches avant le développement.
Prenez le temps de documenter
Documentez ce que vous négociez, documentez les processus, l'architecture des documents. Ici, j'essaie d'adhérer à l'approche selon laquelle si vous ne l'écrivez pas, vous n'êtes pas d'accord. Parce que dans les projets qui durent plus de six mois, il devient essentiel d'apprendre à ne pas perdre d'informations.
Lorsque vous prenez une décision architecturale, cela vous semble évident. Pourquoi l'expliquer en quelque sorte? Six mois ou un an plus tard, des problèmes surgissent dans cette solution architecturale. Et vous pensez: «Pourquoi ai-je accepté cela? Quel était le contexte? " Apprendre à rédiger ces décisions architecturales est un excellent investissement et jouera entre vos mains à l'avenir.
Les enregistrements de décision d'architecture sont l'un des moyens de conserver ces enregistrements.... Son idée principale est que pour chaque solution architecturale non triviale, vous devez créer un fichier avec plusieurs éléments: titre, date, contexte, description de la solution, conséquences attendues. Ce fichier est stocké avec le code et ne change pas après sa création. Sa principale valeur est que lorsque viendra le temps de changer cette solution architecturale, il sera beaucoup plus facile de comprendre la motivation qui y a conduit.
Brièvement
- Un projet avec une histoire est un bon endroit pour qu'un développeur se développe s'il s'intéresse non seulement à l'écriture de code, mais également à des tâches qui aideront à se développer non seulement en tant que programmeur.
- Dans les projets avec un arrière-plan, ce n'est pas le code qui crée le problème, mais les gens, c'est-à-dire une telle gestion lorsqu'ils exigent de vous quelque chose de très rapide et constant comme dans le développement de jeux, par exemple.
- . , , , .
GDG.