Syndrome de plomberie: règles de code héritées pour les tests

Beaucoup sont tombés sur un nouveau venu qui est venu au projet et a déclaré que "tout doit être refait de toute urgence". Et certains ont dit ou pensé. Il s'agit du «syndrome de la plomberie»: un comportement caractérisé par une volonté de tout faire à sa manière, «correctement», lorsque l'on travaille sur un nouveau projet ou lors d'un passage à un nouvel emploi. Ainsi, le code, les technologies ou les outils existants doivent être réécrits, de préférence "pour eux-mêmes". Le sujet serait banal s'il n'était pas répété si souvent d'un projet à l'autre, à chaque nouveau recrutement.

Plus le projet «vit» longtemps, plus il accumule un code «historique» hérité et plus les chances de rencontrer les yeux brûlants d'un plombier atteint du «syndrome» sont élevées. Dans cet article, je voudrais vous dire à quels principes Parallels adhère (immédiatement, le spoiler est le principe de "ne pas nuire"), et ce que nous faisons si nous décidons de "tout refaire" après tout. Bien qu'en général, nous pensons que ce syndrome doit être traité et que l'utilisation de l'héritage est parfois même utile, car elle vous permet de libérer le produit à temps et de ne pas perdre de temps à développer vos technologies.

Lorsque vous travaillez avec des «programmes à longue durée de vie», un pourcentage suffisamment important est le code hérité. Par exemple, Parallels Desktop est en cours de développement depuis plus de 15 ans. Chaque année, l'équipe s'agrandit, de nouvelles personnes viennent, regardent ce qui est écrit et déclarent: "Tout est tordu, arrachons les mains du programmeur et réécrivons tout." Une situation familière?

Avant de commencer à dire si le code hérité est bon ou mauvais, je voudrais décider des concepts de qui comprend cela et quoi. Deux définitions sont généralement utilisées: la première est un code qui n'est pas couvert par les tests. Du point de vue des tests automatiques, tout le code n'est pas couvert par les tests. Le deuxième code hérité est le code dont vous avez hérité. Quand vous devez comprendre comment cela fonctionne, mais personne à qui demander. Et vous devez vous en préoccuper vous-même.

Sagesse renforcée

I. Le meilleur est l'ennemi du bien. Si le code ou le système hérité exécute toutes les fonctionnalités nécessaires avec une qualité acceptable, alors vous n'avez pas besoin de l'améliorer, il est préférable de diriger votre énergie bouillante vers quelque chose de plus utile.

II. De l'important et du nouveau, choisissez l'important, de l'égal choisissez le nouveau. Si le code hérité contient des fonctionnalités importantes et n'est pas couvert par des tests, vous devez y prêter une attention maximale, à la fois en termes de traitement du code et en termes de couverture avec des tests. Si le code hérité et les nouvelles fonctionnalités sont d'égale importance, vous devez vous concentrer sur les nouvelles fonctionnalités (développement et tests).

III. Si l'ancien ne peut pas être amélioré, construisez-en un nouveau à proximité, puis jetez l'ancien. Si le code hérité est nécessaire mais impossible à modifier, utilisez l'ancien code jusqu'à ce que vous écriviez et déboguez le nouveau. Lorsque le nouveau code fonctionne, l'ancien peut être jeté.

Que faire

Étape 1. Nous regardons qui a dit
1. Pigiste . Le plus souvent, les personnes qui n'ont aucune expérience de rejoindre un grand projet depuis le côté rejettent complètement le code. Par exemple, j'ai moi-même d'abord travaillé en freelance, écrit des projets à partir de zéro et, comme de nombreux développeurs similaires, j'ai développé une habitude assez stable - de faire exactement la façon dont je me sens à l'aise.

2. Peu expérimenté . Parfois, de telles déclarations indiquent un manque de qualification de la personne elle-même dans le domaine: il ne connaît pas l'histoire du projet, et, par exemple, que cette construction «terrible» (à son avis) était le résultat de personnes tombant sur des bugs externes dans le processus de développement systèmes et a commencé à les contourner. En conséquence, il y avait une sorte de spaghetti de patchs et de béquilles interconnectés pour ces bugs. Une telle connaissance de tous les pièges existants chez l'homme de l'extérieur ne peut pas être en principe.

3. D'Artagnan . Le plus souvent, cela se produit avec des ingénieurs qui n'ont pas d'expérience de produit et d'expérience dans de grands projets qui ne comprennent pas quel prix ils obtiennent. Un homme frappe sa poitrine avec son talon et dit qu'il le fera avec brio, fraîchement et en seulement une semaine, mais il peut se tromper profondément sur ses capacités, et parce qu'il manque complètement des points tels que les tests et l'intégration dans le plus grand système existant.

4. Spécialiste hautement qualifié. Le seul type de «candidats» que vous devriez écouter, bien que se précipitant pour refaire sur ses conseils, ne vaut toujours pas la peine avant la fin de l'étape 2. Il est possible que nous ayons un professionnel ultra-classe et il peut vraiment prouver que nous ne le faisons pas donc, et peut faire mieux. Mais le fait est que je n'ai rencontré aucune personne de niveau supérieur avec de telles déclarations. Lorsqu'une personne atteint un tel niveau, elle peut déjà imaginer le projet dans son ensemble et comprend toutes les lacunes de la méthode «révolutionnaire».

Étape 2. Faire valoir son argument
La première chose dont une personne a besoin pour arrêter et analyser ses arguments. Cet essai doit être initié par le chef d'équipe. Avec la mise en garde que le "syndrome de plomberie" n'a pas commencé à souffrir une personne qui est venue elle-même chef d'équipe. Ensuite, l'analyse du vol est le travail du chef de projet, bien que, franchement, un chef d'équipe mature n'initie jamais une modification complète sans argumentation sérieuse.

Quels arguments échoueront:
"Nous écrirons le nôtre, avec des échecs et des poètes"
Le plus souvent, si un produit est depuis longtemps sur le marché, il fonctionne déjà en quelque sorte. Il a déjà montré que, malgré la nature terrible de ce qui est sous le capot, il fonctionne. Par exemple, nous avons Parallels Desktop (une solution pour exécuter Windows et d'autres systèmes d'exploitation sur un Mac sans redémarrer), et parfois vous pouvez entendre des débutants: "d'une manière ou d'une autre, vous êtes trop compliqué ici, écrivons ma machine virtuelle." Et comme de telles choses, en principe, ne peuvent pas être faites tout de suite, quand une personne dit cela, elle est soit hors sujet, soit non seule. Il faut lui donner une première expérience dans le projet et comprendre pourquoi il a été ainsi mis en œuvre dès le début.

"C'est moche."
Le problème est que souvent une personne n'a pas d'autres arguments. "Pas technologiquement avancé", "fait sur une ordure", "pourquoi il est écrit en C, il est maintenant à la mode d'écrire en Go." Ce ne sont pas des arguments pour refaire le système. Parce que lorsque vous allez au-delà de votre seul morceau de code, vous commencez à réaliser que votre reprise peut être pire que ce qu'elle était avant. Il peut sembler plus joli à l'intérieur et fonctionner plus lentement, ce qui est inacceptable pour le produit. Je ne l'ai pas vu dans Parallels, mais dans l'entreprise précédente, nous avons dû vivre pleinement toutes les conséquences de cette étape. Nous avons décidé qu'une famille de pilotes pour certains équipements était laide, et nous avions besoin d'une conception plus élégante et étendue qui serait plus facile à entretenir et à ajouter de nouvelles fonctionnalités. Ils ont écrit de nouveaux et beaux pendant un an et demi, mais au final, cela s'est avéré tout aussi horrible et n'a donné aucun avantage. Et le coût des ressources s'est avéré très important: deux développeurs ont englouti une entreprise et demi de travail.

Pourquoi est-il préférable de ne pas toucher au code à long terme d'un grand projet

Vous pouvez même tuer votre projet
Où est la garantie que vous écrirez à nouveau quelque chose et que cela fonctionnera correctement? Après tout, ce n'est pas encore le cas. D'un point de vue commercial, vous devez vivre de nos jours et assurer la continuité des revenus.

Vous pouvez casser des béquilles
Dans tout projet, il y a une chose telle que kludge (mieux connu sous le nom de «béquille»), et de nombreuses choses non documentées. Oui, il existe une telle méthodologie de développement, lorsque la documentation est rédigée pour la première fois, puis que le développement est strictement suivi, mais elle s'est toujours montrée dans les années 90 comme trop inertielle pour les tâches commerciales. Peut-être que de cette façon, vous pouvez fabriquer une fusée, c'est-à-dire dans des processus où le développement dure depuis plusieurs décennies, cela est justifié, car il y a de gros risques de déviations. Et même là, vous devez apporter des modifications lors de vos déplacements.

Et du point de vue du développement commercial des logiciels, il n'y a pas tellement de temps pour d'abord tout prendre en compte dans la documentation, puis le faire. Et il s'avère que tous les produits contiennent une grande quantité de données non déclarées. A rencontré une sorte de problème environnemental, par exemple, du fer a travaillé pour contourner la spécification, a fait un tour de travail pour cela. Dans de nombreux cas, s'il s'agissait d'un changement relativement mineur, il est souvent oublié et ne se reflète pas dans la documentation. C'est juste coincé dans le code, et le plus souvent - avec une sorte de petit commentaire sensé, malheureusement.

Et cela commence: jetons toutes ces béquilles, car il n'est pas clair que cela gâche le code. Et ils ne pensent pas à quoi cela mènera. Par exemple, lorsque nous avons fait l'un de nos correctifs pour le noyau Linux, alors au même endroit une telle béquille a frappé: c'était très moche et en même temps assez mal décrit. Et puis dans la discussion, ils ont appris: certains équipements sans cet entrepôt ne fonctionnent pas. Oui, il n'est plus produit, mais les utilisateurs l'ont toujours et cela fonctionne. Et la perte de prise en charge de ce matériel va à l'encontre de la philosophie de la communauté Linux. J'ai dû réécrire notre code pour que cette solution de contournement soit préservée en tête-à-tête, et après cela, tout le monde était satisfait.

Vous pouvez gaspiller des ressources
Un exemple d'un tel gaspillage de ressources est donné ci-dessus. Il faut comprendre que toute révolution conduit à une guerre civile, à une certaine période de dégradation de la situation, où rien ne fonctionnera.

Vous pouvez perdre l'initiateur et le projet
Le syndrome de plomberie touche principalement les nouveaux employés. Il convient de rappeler que ces personnes sont à risque car elles peuvent quitter l'entreprise pendant la période d'essai (ce n'est pas pour rien qu'elles disent que la période d'essai n'est pas seulement pour la personne, mais aussi pour l'entreprise). L'homme a eu carte blanche, il a commencé à le refaire, puis a déclaré qu'il n'aimait pas le café dans l'entreprise et est parti. C'est une situation très dangereuse. Il s'avère qu'il n'y a rien de nouveau, mais l'ancien est déjà cassé. Ensuite, quelqu'un (et en aucun cas un passionné) devra le mettre en forme.

Que faire lorsque la décision de ne pas refaire la décision est évidente et que la personne «brûle d'une idée»?

Laisser le temps de se refroidir et de réfléchir
Il suffit de donner du temps à la personne qui est venue à un grand projet existant pour mieux se connaître. Car lorsqu'une idée vient d'une personne qui travaille depuis longtemps dans une entreprise et spécifiquement avec ce produit, alors ses initiatives seront prises beaucoup plus au sérieux et seront analysées par ses arguments. Vous devez lui expliquer que vous ne devez pas jeter dans une zone avec laquelle vous n'êtes pas encore suffisamment familier et ne connaissez pas la situation actuelle. Il est douteux qu'une personne qui vient d'arriver, après avoir regardé le code, puisse expliquer avec raison pourquoi tout va mal et pourquoi il faut le changer.

Si une personne refuse un tel refus ou offre beaucoup, alors c'est l'occasion de noter que, peut-être, ce développeur n'est pas prêt à travailler en équipe et des difficultés de communication peuvent survenir avec lui (et c'est un facteur très important pour nous). Depuis lors, le chef d'équipe devra travailler séparément, en «mode manuel». Peut-être qu'une telle personne devrait reconsidérer son point de vue sur sa carrière et se lancer en indépendant, où vous pouvez tout faire «au besoin».

Diriger son énergie dans une direction différente
La plupart des gros produits ont toujours des goulots d'étranglement et des problèmes qui surviennent régulièrement, car tout change à l'extérieur. Bien que, à mon avis, il est toujours très dangereux de laisser une nouvelle personne accéder au code jusqu'à ce qu'il travaille pendant quelques mois avec le débogage de petits bugs, se familiarise avec le code existant et prouve son niveau de compétence.
Il est possible de lui confier une tâche dans le cadre de certains projets parallèles, afin qu'il puisse y mettre ses nouvelles informations et voir ce qui se passe. Il est prévu qu'il existe de tels créneaux dans les ressources, car il y a un nombre limité de tâches, ici, comme dans une entreprise de capital-risque, j'ai investi dans 100 entreprises et j'ai reçu des retours sur une.

Quand vous avez encore besoin de refaire

Le produit meurt dans les conditions existantes
L'argument pour refaire - si l'environnement externe a tellement changé que le produit existant a cessé de fonctionner. Par exemple, quand ils ont sorti un nouveau système d'exploitation, vers lequel les utilisateurs ont commencé à basculer en grande quantité, mais dans ce système d'exploitation, quelque chose a été changé pour que votre produit, qui fonctionnait bien sous les versions précédentes, cesse de fonctionner ou qu'il devienne complètement gênant pour l'utilisateur de l'utiliser. Ou lorsque la plate-forme meurt - par exemple, d'une ancienne, vous pouvez citer BeOS, sous lequel ils ont beaucoup travaillé avec des produits multimédias, par exemple, de la musique composée. Le système est mort, et comme il était assez distinctif, les codes de celui-ci n'ont pratiquement pas été transférés à d'autres systèmes. Avec BeOS OS lui-même, la même chose s'est produite: il y avait des ordinateurs Atom qu'ils visaient, puis le fabricant a cessé de libérer ces processeurs, et les personnes qui ont écrit pour cet ordinateur se sont pratiquement retrouvées sans rien. Et ils ont été forcés de s'adapter de toute urgence à Intel, ce qui s'est avéré mal pour eux - la niche était occupée et un autre OS y régnait. Et afin de prolonger au moins d'une certaine façon leur vie, ils ont dû la refaire sérieusement dans le sens d'une amélioration de la portabilité et ainsi de suite.

Le syndrome de plomberie a fonctionné: étapes de remodelage

Il faut faire évolutivement et en parallèle, sans casser le système. Le processus et les étapes de l'altération varient selon que nous modifions le produit dans son ensemble ou une partie importante de celui-ci. Si tout le produit, c'est en fait le début d'un nouveau projet à partir de zéro. Mais dans la plupart des cas, ils changent encore de partie, car dans le premier cas, plus d'un an s'écoulera avant que la nouvelle base de code ne gagne en stabilité et en conformité avec les qualités des consommateurs afin de satisfaire au moins le niveau qu'elle était.

Si vous remplacez le composant, il est conseillé de le faire: si l'interface externe ne nécessite pas de modifications, nous faisons tranquillement la deuxième implémentation. Il convient de retrouver immédiatement les lignes de démarcation: ici l'ancien reste, mais ici il est déjà possible de refaire, trouver des points d'entrée. Et donc, en gardant l'interface, changez le remplissage.

C’est comme avec une voiture, dans laquelle ils ont décidé de remplacer le moteur à essence par un moteur électrique. Pour l'utilisateur, peu de choses ont changé: la même carrosserie, les quatre roues et le volant restent. Et sous le capot, tout le reste peut être.

Si vous parvenez à trouver un tel point de division, vous pouvez refaire évolutivement et toute personne qui se tient à ce point de division peut même ne pas remarquer les changements (sauf, espérons-le, un meilleur travail). Et puis dans le processus de commutateur de test interne et enregistrez le produit. Malheureusement, cela est loin d'être toujours possible, puis une altération peut conduire à un désastre.

Ou cette option: l'interface est fixe, l'implémentation est terminée, puis l'interface commence à changer de manière itérative.

Il est logique de commencer une altération sérieuse des branches latérales et jusqu'à ce qu'elle ait un aspect fini, elle ne s'intègre pas au produit principal. Même en ce qui concerne les sous-systèmes, c'est pire si sous ce nom nous avons commencé à faire quelque chose de complètement nouveau et que l'équipe s'est séparée, alors il n'y a plus de produit du tout.

Au lieu d'une conclusion

Un garçon est né avec une noix au lieu d'un nombril. Et il demandait périodiquement à ses parents pourquoi il y avait une noix. Les parents ont promis de lui en parler à l'occasion de son 14e anniversaire. Le gars a eu 14 ans. Puis il est de nouveau allé voir son père et sa mère et lui a demandé pourquoi il avait un écrou au lieu d'un nombril. Les parents ont promis de lui en parler quand il aura 18 ans. À 18 ans, il a demandé à nouveau, puis ils lui ont dit qu'il y avait une île tropicale sur laquelle poussait un palmier et sous ce palmier un tronc était enterré. Il y a des réponses à toutes ses questions. Le gars a économisé de l'argent pendant longtemps et s'est toujours empoisonné sur cette île. J'ai trouvé un palmier, creusé un coffre dans lequel se trouvait une clé. Sans hésitation, il a dévissé l'écrou avec la clé trouvée et son cul est tombé. Moralité: parfois, vous n'avez tout simplement pas besoin de chercher des aventures sur le cinquième point.