L'homme est la valeur principale de toute entreprise. Le succès de toute l'entreprise dépend de la façon dont les gens communiquent entre eux, de la façon dont ils atteignent leurs objectifs ensemble et du travail d'équipe. Le perfectionnement constant des compétences, des processus et des outils vous permet de travailler plus efficacement.
Au Marché, nous travaillons pour offrir de nouvelles fonctionnalités à nos utilisateurs le plus rapidement possible. Pour ce faire, nous étudions en permanence nos processus et optimisons toutes les étapes de la tâche. Aujourd'hui, nous parlerons aux lecteurs de Habr de l'optimisation de l'un d'entre eux, à savoir le processus de révision du code.
Vous devez d'abord imaginer quel type de flux de développement nous avons adopté:
La même chose, seulement point par point et en mots:
- Le développeur prend la tâche.
- La fait.
- Remplit Github et ouvre PR.
- Passe un examen du code.
- Collecte un support de démonstration et le donne à un testeur.
- Le testeur vérifie le support de démonstration.
- La tâche vérifiée est collectée dans la version.
- Test en version.
- Disposition sur prod.
- Test final au combat.
Par domaine de responsabilité, la tâche est divisée en plusieurs étapes:
1-5 - responsabilité du développeur;
6-7 - responsabilité du testeur;
8-10 - responsabilité du maître de publication.
Ils ont donc commencé à analyser ce qui nous prend le plus de temps. Heureusement, il existe des outils d'analyse interne. Tout le monde comptait sur ce qui prendra le plus longtemps, bien sûr, le processus de développement lui-même (le statut "In Work") ... et cela s'est avéré ainsi. Mais un moment nous a le plus surpris. La durée moyenne d'un examen est de deux semaines!
Étape 1. Analyser PR
Commençant à étudier les demandes de pull, ils ont immédiatement fait face à un fait très intéressant. Il s'est avéré que nous avons un immense cimetière de demandes de tirage non fermées. La plupart des auteurs de ces relations publiques ne travaillaient plus pour l'entreprise, mais leur héritage était toujours avec nous. Qui n'a jamais vu de dinosaures, les voici:
Ces demandes d'extraction ajoutaient du bruit et interféraient avec l'analyse correcte du temps de révision du code. Avec un esprit calme, nous les avons fermés. Il ne restait plus qu'à raconter le temps. Mais c'était encore dans les 2-3 jours. Ce n'est pas bon.
Étape 2: Démontage avec un Browner
Reviewer est un système développé dans Yandex qui appelle en RP deux personnes aléatoires ayant une expertise dans un code mutable et prenant en compte les vacances et les absences. L'analyse des RP hebdomadaires a révélé un groupe de personnes qui traînaient constamment la révision du code. Après avoir interviewé des collègues, nous avons trouvé un autre problème dans notre processus. Les collègues se sont plaints d'avoir reçu trop de demandes de tirage par jour de la part des jaloux, et ils n'avaient tout simplement pas assez de temps pour leur travail principal.
Cela ne coïncidait pas avec nos indicateurs: un ou deux RP par jour et par personne. L'étude a mené à Github, où nous avons une équipe distincte d'examinateurs. Cette équipe n'a pas été mise à jour depuis plusieurs années. Depuis lors, le nombre d'employés a doublé, mais aucun des nouveaux arrivants n'a été inclus dans l'équipe d'examinateurs. En d'autres termes, la moitié de l'équipe n'a pas du tout participé à la révision du code! Correction de ce malentendu gênant.
Étape 3. Extension des outils
À ce stade, nous avons essayé de simplifier la vie déjà simple, comme nous le pensions, des examinateurs. Les outils suivants étaient dans l'arsenal du front-end:
- vérificateurs de style de code;
- essai de fonctionnement;
- divers contrôles ringards dans PR lui-même;
- révisionniste;
- alertes sur le courrier et le traqueur de tâches
Il semblerait que tout soit là. Prenez et revoyez!
La première chose qui s'est avérée incorrecte: un processus de révision de code différent dans différents référentiels. Nous avons unifié et en même temps prouvé l'apposition d'étiquettes pour une recherche pratique des PR via l'interface Github.
La deuxième chose qu'ils ont remarquée: le courrier n'est pas le meilleur outil pour rendre rapidement compte de l'état des revues de code. Beaucoup, pour ne pas être distraits du travail, analysent son courrier plusieurs fois par jour. Les messagers sont une tout autre affaire. La réaction aux messages dans les messagers est beaucoup plus élevée. Et il a été décidé de connecter le bot à notre messager. Le bot envoie des alertes sur l'état d'une révision de code à la fois pour l'auteur de la demande d'extraction et encourage les gens à réviser. Très confortable.
Étape 4. Premier SLA
Parallèlement aux actions 2 et 3, nous avons commencé à travailler en étroite collaboration avec les employés et à expliquer que la révision du code est indissociable de la tâche elle-même. Ils ont expliqué qu'apporter à "Vérifié" est la responsabilité du développeur. De plus, la responsabilité n'est pas seulement envers les collègues, mais aussi envers les utilisateurs! Livraison rapide des fonctionnalités aux ventes - c'est ce que je voulais atteindre. Et l'équipe était sympathique au processus d'amélioration.
À ce stade, la première idée de la revue de code idéale est née. Bien sûr, tout le monde veut que cela se fasse en 5 minutes, mais ce n'est pas toujours possible. Compte tenu du fait que nous avons une équipe multirégionale (avec un décalage horaire de quatre heures), nous avons convenu que notre SLA sera d'un jour, c'est-à-dire 24 heures Ce SLA a été annoncé à tous les employés et, en se frottant les mains, a commencé à attendre les résultats.
Mais la situation n'a pas changé. Dans les meilleures semaines, la moitié des demandes de tirage tiennent sur 1 jour. Le reste est sorti pour lui.
Nous avions un petit script qui évaluait la révision du code temporel sur PR. Nous avons commencé à les blâmer quotidiennement pour tous les RP en quête de «retard». Presque tous les jours, il y en avait un paquet.
Il a fallu beaucoup de temps pour les analyser. Le plus souvent, le script lui-même calculait malhonnêtement le moment de la révision. Il n'a pas tenu compte du fait que certains RP ont été créés en dehors des heures de travail (oui, des gens courageux et qualifiés aiment travailler pendant une heure ou deux la nuit, venez chez nous pour travailler!) Tout cela nous a montré que nos outils de suivi des demandes de pull ne sont pas les plus efficaces, car ils sont malhonnêtes. Je dois trouver de nouveaux outils.
Étape 5. SLA Tracker
L'aide est venue d'où ils n'ont pas attendu. Nos collègues de Tracker ont annoncé une chose étonnante: vous pouvez maintenant installer SLA dans le Tracker lui-même. De plus, vous pouvez le configurer complètement différemment. Un certain temporisateur est activé par un événement de la tâche. Pour certains événements, il peut s'arrêter. Et arrêtez-vous à un événement. Oui, c'est ce dont nous avons besoin!
Ils ont immédiatement entamé une étude détaillée de la documentation (soit dit en passant, la voici ) et mis en place nos files d'attente (il y en a plusieurs, car il y a plusieurs référentiels). Nous réglons la minuterie pour qu'elle s'allume lors du passage à l'état "Besoin de révision du code" et se termine quand elle passe à tout autre état, sauf pour "Il y a des commentaires" - quand elle passe, la minuterie s'arrête, c.-à-d. n'a pas perdu son temps.
C'était cool aussi que la minuterie prenne en compte les heures de travail et un calendrier! Nous définissons que 9h est affecté à la révision du code, c'est-à-dire un jour ouvrable. Dans ce cas, une alerte est déclenchée 2h après le démarrage, ou si un délai de neuf heures est dépassé. Le résultat a été une sorte de surveillance honnête. Au début, nous avons activé le minuteur pour le plaisir de l'expérience, collecté un pack de bugs et exporté vers le Tracker.
Il convient de noter que le minuteur a été activé uniquement pour les tâches qui ont été créées après l'implémentation du minuteur lui-même. Par conséquent, l'effet instantané ne pouvait pas être vu. Mais déjà à ce stade, une dynamique positive a commencé. Nous avons eu l'effet un mois plus tard, lorsque le flux de nouveaux billets avec une minuterie a commencé à évincer les anciens. Il était à noter que la durée approximative de la révision du code était concentrée dans le domaine des messages de rappel, c'est-à-dire marque 2h et 9h.
Au moment d'écrire ces lignes, nous avons 415 tâches dans lesquelles le chronomètre a démarré. Parmi ceux-ci, 29 ont dépassé la frontière de neuf heures. Bien que, si vous y regardez de plus près, vous rencontrerez également de telles tâches, dont la révision du code a été achevée dans l'heure suivante. Si nous les jetons aussi, alors il reste 17 tâches. Et cela représente environ 4,1%!
Le résultat. Samouraï affûtant constamment son épée
En regardant en arrière et en rappelant toutes nos actions, une conclusion peut être tirée - tous les moyens sont bons. Toutes nos étapes ont abouti au résultat souhaité: plus de 92% des demandes de pull ont commencé à satisfaire notre SLA ! Tâches de moins en moins déchirées, la revue de code est plus rapide. Lentement, petit à petit, 75% de la révision du code a commencé à tenir en 5 heures ! Et la dynamique d'amélioration est toujours positive. En plus des indicateurs numériques, nous avons commencé à recevoir des retours plus positifs de la part des sous-traitants. Encore plus satisfait du fait que l'équipe ait réagi à tout ce processus. Même un processus tel que l'accélération de la révision des codes a encore plus rallié l'équipe. Chaque participant a commencé à comprendre la responsabilité qu'il porte devant les autres, car un code de révision rapide nous permet de bénéficier encore plus rapidement à nos utilisateurs.
Bien sûr, 9h n'est pas le rêve ultime, mais toujours le succès. Mais là-dessus, nous n'avons pas l'intention de nous arrêter. Nous continuons à surveiller le processus de révision du code et à résoudre tous les problèmes techniques et même psychologiques auxquels les employés sont confrontés afin que notre processus soit aussi productif que possible et en même temps confortable pour l'équipe.
Questions et réponses. Et si ...?
Q : Et si je pense qu'ils me regardent? À quoi sert cette minuterie?
R : Nous surveillons non pas spécifiquement pour quelqu'un, mais pour le processus. Il y a deux côtés à la demande de tirage: l'auteur et les réviseurs. Si les relecteurs font glisser le chèque, alors l'auteur souffre. D'un autre côté, il est également inhumain d'arracher immédiatement les inspecteurs du travail. Il est nécessaire de trouver un équilibre pour que les deux côtés soient confortables. La minuterie n'est pas nécessaire pour punir quelqu'un, mais pour enregistrer toutes les déviations. La plupart de ces écarts ne se produisent pas par la faute des examinateurs, mais par la faute de problèmes techniques. Le défi consiste à résoudre ces problèmes. Pour que les autres ne les rencontrent pas. Auto-amélioration continue
Q : Et que se passe-t-il s'il existe des PR complexes, plus de 100500 lignes de code et qu'il y a "changez la lettre". Où est la justice?
R : Oui, c'est vrai. Lorsque nous travaillions sur la révision du code standard, nous l'avons simplement pris le long de la limite supérieure, c'est-à-dire la révision du code des RP complexes devrait s'inscrire dans le SLA. Mais en même temps, nous n'avons aucun objectif de conduire tout le monde dans ces limites. Nous sommes toujours disposés à tirer des demandes, dans lesquelles il y a une discussion animée et utile, malgré la barre cassée en une journée.
Nous avons des plans pour les grades SLA sur les points de stockage. 1SP - 1h, 3SP - 5h, 5SP - 2d, par exemple. Heureusement, le Tracker en est déjà capable. Nous ne sommes tout simplement pas encore prêts pour cela - nous avons encore un long chemin à parcourir.