De nombreux projets avec lesquels j'ai travaillé, de grands projets, se sont transformés en héritage, démêlant les barbes, et par conséquent, le développement est devenu extrêmement difficile. Il y avait des moments où les projets venaient de mourir en raison de la difficulté infernale de faire des changements. Aujourd'hui, je vais vous parler de mon expérience de travail avec des projets et pourquoi je vous écris tout cela. Tout est très subjectif, bien sûr.
Donc, j'ai travaillé, et j'ai essayé, comme un marin qui veut ratisser l'eau et empêcher le bateau de couler, mais la qualité du projet a régulièrement décliné, et il y avait plusieurs raisons.
Vous les reconnaîtrez facilement, ce sont des patients réguliers, je vais juste vous les rappeler:
- L'architecture est boiteuse, il est difficile de mettre en place une nouvelle solution
- Erreurs de codage
- Il n'y a pas de test automatique
En conséquence, selon les résultats du développement du projet au cours des 1 à 2 premières années, un mélange d'héritage, de code de merde, de tunnels enchevêtrés avec des passages secrets et de peintures rupestres ala "fonctionne comme ça, pourquoi je ne sais pas" est obtenu.
Je ne m'attarde pas beaucoup là-dessus, c'est le sujet n ° 1 du refactoring, donc directement aux conclusions que j'ai tirées.
Le produit développé est une expertise collective
Si l'équipe a 1 méga-développeur, vraiment pompé, fonctionne bien, alors lui seul ne le nettoiera pas, car l'équipe fait constamment des erreurs et entraînera invariablement le projet vers le bas.
Vous pouvez, bien sûr, essayer de confier à l'équipe actuelle une tâche de refactoring, puis ceux qui l'ont soudé refont leur propre résultat de travail, et donneront la même chose, enfin, peut-être un peu mieux que la première fois.
Par conséquent, vous ne devriez pas vous attendre à une mise à niveau radicale de la qualité sans une mise à niveau d'équipe.
C'est un cercle vicieux numéro 1 - l'expertise de l'équipe ne suffit pas, mais la refactorisation commence et, attention, les mêmes posons qui l'ont écrit le font.
Alternativement, vous pouvez mettre un bon lead qui effectuera un examen et nettoiera ces erreurs (bien qu'il essaiera de le faire), mais à la fin cela se terminera par un mal de tête pour ceux qui travaillent mal, puis soit le remplacement des développeurs, soit eux-mêmes partiront, et, encore une fois remplacera les développeurs.
Ce sera une sorte de sélection naturelle sur le projet.
Les gens ont peur de changer le code
Bienvenue, c'est une session de psychologie pour les programmeurs.
Les programmeurs ont vraiment peur de changer le code, et ils peuvent être compris:
- Pas assez de tests ou pas
- Le fonctionnement du code n'est pas clair
- Les dates sont le
- Pas de ressources
- La direction ne comprendra pas (normal, mais si la direction est en feu, tout ira bien)
En conséquence, l'ancien code hérité déroutant qui traîne le projet vers le bas est perçu comme "il vaut mieux ne pas toucher", et par conséquent, ce "ne pas toucher" dure éternellement et, pire encore, vous oblige à écrire du code d'une certaine manière, causant d'autres problèmes techniques qui puis ils abaissent également le projet.
Nous prenons un projet, du code merdique, des peurs d'équipe, le multiplions par le temps, et nous avons une énorme dette technique, qui résiste et ne permet pas à l'équipe de bouger normalement et de développer le projet rapidement.
Le projet commence à s'effondrer, les délais sont perturbés, les nouvelles fonctionnalités deviennent énormément plus chères pour le projet, les développeurs commencent à être nerveux, certains partent, les nouveaux sont plus difficiles à trouver, vous voyez l'idée ...
Donc, je pense que c'est le problème n ° 1, la peur du code et des risques.
Par expérience, il a été observé que si vous laissez une dette technique, alors c'est une bombe potentielle, ou du moins un râteau. Laissez-les 100, 1000, et vous obtiendrez un champ de mines, sur lequel non seulement aller (développer le projet), vous ne pourrez pas ramper.
Par conséquent, le seul moyen d'économiser la vitesse moyenne de développement du projet et de ne pas faire baisser la qualité est, grâce au capuchon, de faire attention à la qualité, au refactor.
Le feu du Conseil, tout le monde le sait, mais en fait la liste ci-dessus n'a été nulle part, donc vous ne pouvez pas simplement la prendre et la refactoriser, car vous obtenez un projet qui s'effondre, mais pourquoi?
Comme il n'y a pas de tests, le fonctionnement du code n'est pas clair et, par conséquent, au lieu de modifier les dessins et l'assemblage de la voiture, il s'avère que Vasya et Petya ont pris une meuleuse, ont scié Solaris et l'ont remis à Tavria, mais cela ne va pas. Pourquoi? - oh, mais parce que nous ne savions pas à propos de cette influence / comportement / tâches
Oui, vous pouvez refactoriser sans tests, puis stabiliser, mais de nombreux scripts utilisateur ou scripts d'exécution de code nécessaires peuvent être perdus, ou la stabilisation peut prendre très longtemps.
Par conséquent, un autre cercle vicieux - vous ne pouvez pas laisser le code seul, mais vous ne pouvez pas non plus le refactoriser, pour ainsi dire, car les risques sont énormes.
Il s'avère que nous n'avons pas besoin de Legacy, mais s'en débarrasser est effrayant et dangereux, donc les équipes laissent souvent Legacy comme "l'option la moins dangereuse" afin d'obtenir une solution encore plus dangereuse pour le projet plus tard.
Les tests sont la clé
Il s'avère que pour déverrouiller le refactoring et le sécuriser, vous devez d'abord couvrir tous les cas avec des tests, puis lorsque nous coupons notre Solaris et l'assemblons à Tavria, le soudage s'arrêtera et dira "Bonjour, nous avons besoin d'un Solaris, vous avez foiré ici."
Les tests vous permettent d'éviter les erreurs lors du refactoring, c'est-à-dire sécurisez-le, puis vous pouvez couper le projet comme vous le souhaitez et selon vos besoins sans craindre que les risques ne fonctionnent et qu'il y ait des problèmes.
Par conséquent, nous obtenons une chaîne:
Tests -> Refactoring -> Adieu barbe et héritage
Cela semble simple, beau, mais en pratique, il y a peu de tests. Ou cela n'arrive pas du tout, et il y a plusieurs raisons à cela, comme d'habitude:
- Les développeurs considèrent les tests comme un sujet distinct et n'investissent pas dans les évaluations, ils écrivent séparément du développement. C'est encore plus difficile si la direction du projet le pense et veut couper les tests pour respecter les délais.
- Les tests sont du temps, et le projet doit être remis maintenant, il n'y a pas de temps pour écrire des tests pour nous (c'est, en théorie, la même chose que le point numéro 1)
- Le projet / composant est simple, pourquoi y a-t-il des tests, tout est extrêmement simple et y fonctionne?
- Nous allons d'abord écrire le code, puis nous le couvrirons de tests. Mais non, nous ne l'avons pas compris, le projet ne s'est pas arrêté, il n'y avait pas de temps. Cette tâche se trouve donc dans la boîte noire pour toujours.
Il y a en fait un million de raisons, mais le fait est que cela bloque le refactoring et, par conséquent, empêche la qualité de grandir.
Par conséquent, les tests sont une tâche critique, et sans eux, le développement de haute qualité à long terme du projet sera considérablement difficile, voire impossible.
Que faire, Houston?
J'écris cet article uniquement parce que tout le monde ne le comprend pas, et il y a au moins quelqu'un qui le lira et qui voudra écrire des tests, refactoriser, ce qui signifie que je n'ai pas écrit cet article en vain.
Donc, le devoir de tout le monde - prenez un module, un composant, quelque chose mal écrit, trouvez-y que vous aimeriez refactoriser, écrivez des tests pour ce module ou composant, et refactorisez.
En conséquence, vous comprendrez que les tests sont:
- Une façon d'apprendre le code. Cela peut même être beaucoup plus efficace que de simplement le lire.
- La stabilité
- L'ancien code peut vraiment être remanié et la qualité du projet peut être améliorée
J'ai tout écrit en un seul souffle, très subjectivement, et peut-être que je me trompe, c'est juste mon expérience. Peut-être que je viens de tomber sur de tels projets, je ne sais pas, mais l'information est toujours utile, et si vous réfléchissez après l'avoir lu, c'est aussi bien.
Je souhaite à tous un bon code, des tests et une amélioration de la qualité - c'est pourquoi nous sommes embauchés, travaillons bien.
PS Si vous le souhaitez, écrivez votre expérience de refactoring dans les commentaires, tout le monde sera intéressé.