Bonjour ! Je m'appelle Alexey Pyankov, je suis le développeur principal chez Sportmaster. Je peux vous dire tout de suite que « principal » ne signifie pas « le plus important de tous les développeurs », non, c'est juste un titre, une charmante traduction pour « Senior+ ».
Chez Sportmaster, je travaille depuis 2012, et pendant ce temps, l'équipe de développement a réalisé de nombreuses solutions intéressantes d'un point de vue technique. Mais aujourd'hui, je voudrais parler de notre travail en mettant l'accent sur la manière dont nous avons réfléchi dans certaines situations ambiguës.
Cet article ne contiendra pas de solutions techniques concrètes (ni même quelque chose de technique) à saisir et à appliquer dans votre projet. Plutôt, il s'agit d'une réflexion sur le travail accompli. Il y a eu des moments particuliers qui ont affecté notre équipe — qui nous ont unis, renforcés et mis à l'épreuve. Je vais essayer de parler de ces moments, de l'atmosphère de travail en équipe, de nos écueils et d'un certain nombre de pièges psychologiques dans lesquels nous nous enfermons parfois.
Et je vais commencer précisément par l'année 2012.
Je suis arrivé en 2012 avec l'objectif principal à l'époque — travailler sur notre site phare. À l'époque, c'était un « monstre de Frankenstein » : une partie de l'équipe travaillait avec notre ancien système, qui ne gérait pas très bien les charges (Bitrix), tandis qu'une autre partie de l'équipe (y compris moi) tentait d'implémenter un nouveau système que nous avions choisi sur le critère « Puisque c'est le plus cher e-commerce du monde, nous le prenons ». C'était vraiment « tenter d'implémenter » — car le système résistait fermement, et à chaque problème que nous réussissions à résoudre, un « surprise » survenait en réponse. Nous avons beaucoup travaillé, mais avancions à la vitesse d'un escargot.
Pour moi, la goutte d'eau a été la découverte du code d'une méthode dans ce « e-commerce le plus cher au monde », où des heures de travail acharné sur un bogue complexe ont révélé que la cause se cachait quelque part dans un custom-tag, qui s'active lors de la génération de HTML dans JSP. La tâche de ce custom-tag est d'afficher la somme de certaines valeurs. C'est bien, c'est précisément à cela que ce custom-tag est destiné. Mais la surprise résidait dans le fait que cela modifiait certaines données dans la base de données, influençant le comportement des pages suivantes, et si l'on appuyait sur F5, l'appel se répétait, ce qui compromettait la cohérence des données. Cela se manifestait de manière si perverse que cela n'apparaissait qu'après plusieurs étapes, à la troisième page de la séquence. Non, je ne suis pas contre un tel « maître ninja » dans l'équipe, qui garde l'attention de ses collègues. Mais pas comme ça, dans la librairie du système le plus coûteux !
C'était un vendredi. Nous avons passé le samedi et le dimanche au bureau avec mon collègue pour comprendre quelles tâches l'entreprise attendait du système aujourd'hui et quelles tâches elle pourrait imaginer dans un an. Par conséquent, comment les résoudrions-nous si nous n'étions pas coincés dans les limites de ce système le plus coûteux et le plus frustrant.
Dit et fait. Nous avons réalisé un pilote, dans lequel nous avons jeté les bases du développement du nouveau site de Sportmaster. Beaucoup de ces idées ont pris vie et leur poursuite est actuellement activement mise en œuvre sur le site.
Étapes du pilote et délais
2 jours. Nous avons réalisé un micro-prototype - durant le week-end, nous transférons notre base vers ElasticSearch et créons une recherche facettée. Voilà ! Dans ce système acheté, un tel paramétrage a pris 2 semaines. Ici, c'est littéralement en quelques heures ! Et cela fonctionne même plus rapidement. En fait, c'est beaucoup plus rapide.
2 semaines. Nous développons un prototype, ajoutant des fonctionnalités pour un affichage personnalisé adéquat.
Par exemple, si un utilisateur a plusieurs réductions et promotions qui lui sont spécifiquement destinées, alors il faut afficher dans les résultats de recherche sur les produits le prix qu'il peut obtenir en utilisant tous les avantages disponibles de la manière la plus avantageuse.
Avec les promotions, ce n'est pas si simple. Par exemple, j'ai acheté des skis, et maintenant j'ai une remise de 40 % sur le bonnet, mais cela annule la remise de 10 % de bienvenue sur toute la commande. Oui, c'est un vrai cas 🙂 Et pour configurer une telle promotion dans le système d'achat, nous avons payé 3 consultations avec le fournisseur, au cours desquelles nous avons reçu de nombreux exemples de différentes promotions à réaliser. Très diplomatiquement et, compte tenu du coût des consultations, c'est une bonne économie sur le plan économique.
Nous avons présenté une démonstration détaillée au client. Ils ont promis de rapidement monter un pilote et se sont immédiatement mis au travail.
2 mois. Le projet pilote — nous le réalisons sous la forme d'un site web vivant avec recherche dans le catalogue. Recherche avec facettes, résultats de recherche — avec des remises personnalisées, le pilote ressemble presque à un site de Sportmaster, et nous avons utilisé les mêmes produits. Supertop !
Nous ajoutons «Красноречие:100» de notre chef de département, et la présentation pour le client se passe à merveille ! On nous donne carte blanche pour développer la plateforme eCommerce nous-mêmes.
Et cela signifie, tenez bon les gars, tenez bon les gars, le budget. C'est génial !
2 ans. Mise en production du site. Oui, cela a pris du temps. Tout ce que nous savions faire à l'époque, nous l'avons seulement essayé à l'échelle du prototype. Deux personnes forment facilement une équipe soudée. De plus, les tâches que nous « cochions » étaient en grande partie de petits ajustements de « Hello World » dans de nouvelles technologies. Nous générions facilement de nouvelles hypothèses, les testions rapidement, sans avoir le temps de nous attacher et nous les « tuions » donc sans regrets. Quand nous sommes devenus 10 personnes, nous avons par inertie extrapolé notre vitesse de travail à tous les autres. Et avons promis des délais d'exécution qui équivalent à une vision du beau multipliée par notre enthousiasme.
Situation familière ? 🙂
Alors, vous savez déjà ce qui va suivre ?
Piège n°1. « Extrapolateur super cool »
Il est clair que les nouvelles technologies ont l'air très cool dans les présentations et se comportent très bien dans des applications de type « Hello World ». Mais la réalité est généralement un peu différente.
Alors voilà. Nous prenons la bibliothèque, écrivons une tonne de code applicatif. Nous considérons les tests unitaires comme un fardeau (nous sommes géniaux et travaillons à la vitesse supersonique ici, le code est moderne et tout le reste). Nous modifions et retouchons constamment l'API à la volée — des tests ? Sérieusement, quelle blague. Et tout cela sous la bannière de « nous avons super optimisé le processus de développement » (oui, maintenant c'est même effrayant de le décrire).
Et ensuite, c'est assez évident.
Nous déployons une nouvelle version sur uat. Les gars du business sont en train de tester tout cela avec enthousiasme et d'appuyer sur les boutons. Parfois, ils le font de manière assez créative — quelque chose se casse. Il faudrait aller voir ce qui a été fait à ce sujet. Mais de l'autre côté de l'écran, ce n'est pas un testeur acharné qui va te donner toutes les caractéristiques de l'environnement en tenant compte de la météo dans la région, mais un client du business. Pour lui, c'est juste "ça ne fonctionne pas". Cela signifie qu'il est mécontent. Demande-lui et il sera terrifié mécontent !
Alors, pour reproduire le bug, il faut y aller et tout tester en passant par les différentes options. Bien sûr, nous n'avons négligé aucune plainte et nous avons tout corrigé. Nous avons laissé de côté les tâches planifiées, mais nous avons "éteint le feu".
Ainsi, nous avons creusé un nouveau trou.
Piège n°2. "Stakhanoviste"
Un bug désagréable te tombe dessus. Tu commences à creuser. Ça ne fonctionne pas — colère — tentative de comprendre encore une fois — nouvelle déception — tu vérifies tout ce que tu peux — encore pas ça — tu penses à l'avancement que tu as pris, alors que tout le monde a des enfants et un prêt — tu essaies encore — encore pas ça. Quelques tasses de café plus tard, et tout se répète. 12-14 heures de travail d'affilée — presque la norme. Et là, quand tout est presque au bout du rouleau — bam, illumination !
Peut-être qu'en externe, l'évaluation de l'efficacité d'une telle journée est clairement visible et juste. Mais de l'intérieur — cela peut être très différent.
Dans mon cas, l'impression de ce travail contenait "Je suis génial, je suis formidable, j'ai géré". Pas toujours de façon consciente, mais inconsciemment — toujours !
Et tu t'y accroches, sans blague. Il s'avère que les métriques internes de réussite se déplacent du résultat vers le nombre d'efforts fournis et le niveau des exploits que tu as réalisés, à quel point tu as souffert en essayant de résoudre le problème.
C'est probablement le piège le plus terrible.
La suite sera plus facile et plus amusante 🙂
Piège n°3. "La force Hello world"
Notre stack technologique de l'époque : ElasticSearch, Hazelcast, Pentaho, freemarker (et des classiques comme Java, Spring, Tomcat, nginx). Freemarker ne fournissait pas des messages d'erreur très informatifs. En revanche, ElasticSearch, Hazelcast et Pentaho ont dû être patchés plusieurs fois — nous avons talentueusement trouvé des cas où ils ne fonctionnaient pas comme indiqué dans la documentation.
Un démarrage facile et des résultats rapides grâce à l'utilisation d'une nouvelle technologie, c'est bien, mais cela engendre une euphorie qui peut réduire notre vigilance. Car toute nouvelle technologie comporte des bugs, elle en contient nécessairement. Et s'ils n'ont pas encore été signalés, réjouis-toi, c'est à toi de devenir le pionnier qui finira par dénicher quelque chose de défaillant et ira le googler ou chercher sur SO. Bien sûr, des « défauts » peuvent être trouvés dans des produits éprouvés, mais dans les nouveaux, c'est beaucoup plus facile.
Malgré toutes les difficultés, nous sommes arrivés en production. Oui, avec des latences. Oui, ce n'est pas très stable. Mais dans l'ensemble, cela s'est bien passé sans catastrophe.
Encore une fois, je vais souligner les pièges qui déforment une perception saine du processus de travail.
- « L'extrapolateur génial ». Impressionnés par nos succès actuels, nous extrapolons joyeusement la vitesse de développement sur les projets à venir.
- « Le Stakhanoviste ». Nous travaillons sans relâche, fiers de nous, mais nous ne réalisons pas que les problèmes que nous résolvons sont le résultat de nos erreurs/négligences personnelles. Des travaux non effectués.
- « La force de Hello world ». Nous nous dépêchons d'intégrer tout ce qui est nouveau et intéressant en production.
Pourquoi cela a fonctionné
Bien sûr, je n'ai pas mentionné toutes les erreurs que nous avons commises durant cette période, mais les plus courantes, probables pour tout projet quel qu'il soit. Cette fixation sur les erreurs aide à les éviter à l'avenir.
Un peu sur la façon dont nous avons réussi à créer un mini-startup au sein de l'entreprise et à convaincre le business de quitter un système déjà acheté pour quelque chose de fait maison.
Condition n°0. Un climat sain au sein de l'entreprise. Cela ne concerne pas seulement les « yeux brillants » des employés et la communication dans des conditions stressantes d'acquisition de cookies, non. Cela concerne toutes les interactions.
Condition n°1. Croire en ce que l'on fait. Sincèrement, je ne pense pas que nous aurions eu une chance, si nous avions fait un pilote sans démonter le système acheté « jusqu'au boulon » — c'est-à-dire, en nous retirant et en sachant inconsciemment que ce système est meilleur et nous surclasserait.
Ce que nous avons fait : 1) nous avons compris le système acheté, grâce à lui nous avons résolu les principales requêtes du business 2) nous avons établi une liste de tâches qui existent non seulement actuellement, mais aussi dans un avenir proche 3) nous avons sélectionné la solution la plus appropriée. Ainsi, notre évaluation de la solution était une évaluation d'experts.
Nous donnerait-on quelque chose si nous venions simplement et disions : « les gars, tout va mal, nous ne voulons pas nous en occuper et avons décidé de tout recommencer depuis le début » ? Peu probable. De plus, la réponse serait formulée de telle manière que cela resterait bien en mémoire 🙂
Condition n°2. Nous faisons le premier pas petit. Nous générons la première hypothèse et la testons. Vous pouvez y consacrer votre propre temps personnel. Si vous ne voulez pas perdre votre temps, alors cela ne vaut pas la peine de se lancer dans un tel projet. Et si vous ne voulez pas tester une petite hypothèse, mais préférez tout faire de manière impressionnante tout de suite, éloignez-vous de telles personnes !
Nous avons eu de la chance, et la toute première hypothèse a fonctionné. Mais cela n'arrive pas toujours. Par exemple, dans un des projets suivants, lorsque nous avons promu le panneau d'administration dans le cadre d'un pilote similaire, seule la 18ème option a fonctionné. Les 17 premières approches n'ont rien donné. À propos, l'histoire de la création du panneau d'administration a eu des rebondissements dignes de feuilletons brésiliens, car l'équipe était composée de gars, déjà vétérans à l'époque, de véritables 'pro'.
Condition n°3. Nous faisons un MVP et cherchons les douleurs du décideur. Bien sûr, son visage peut déjà exprimer l'horreur juste par le fait que vous lui apportez encore une nouvelle idée pour la trentième fois. Mais peu importe. Et nous devons absolument montrer comment nous résolvons ses problèmes avec notre produit.
Condition n°4. Nous faisons rapidement un pilote à la va-vite, qui ressemble à peu près au résultat final. Tout faire parfaitement est tentant, mais cela peut conduire au perfectionnisme, où au lieu d'un pilote, vous souhaitez montrer une version pilote d'un produit déjà idéal. Et cela n'existe pas. Alors faites-le au moins avec des bâtons.
Condition n°5. Produit. Le projet grandit, obtient des financements, des spécialistes viennent avec une solide expérience.
Et si vous êtes un startuper classique, c'est le moment où vous devez prendre la fuite. Parce que les vols légers au sommet et la sensation de bien-être général se dissipent rapidement.
Le passage à la production signifie faire face à de réelles charges, intégrer une dizaine de systèmes, et au fur et à mesure que vous créez de nouvelles fonctionnalités, vous continuez à perfectionner les anciennes versions. Tous ces défis sont bien plus sérieux que d'inventer une idée et de résoudre, même bien, un seul problème client.
Ce sont des défis, et la croissance des compétences se produit précisément à cette étape.
Merci de votre lecture. Bon nouveau code !
Source : habr.com
