Salut Je m'appelle Alexey Pyankov, je suis le programmeur en chef de Sportmaster. Je dirai tout de suite que "principal" ne signifie pas "le plus important de tous les programmeurs", non, c'est juste un nom, une charmante traduction pour "Senior +" ".
Je travaille chez Sportmaster depuis 2012, et pendant ce temps, l'équipe de développement a pris de nombreuses décisions intéressantes d'un point de vue technique. Mais aujourd'hui, je voudrais parler de notre travail en insistant davantage sur la façon dont nous avons raisonné dans certaines situations ambiguës.
Cet article n'aura pas de solutions techniques spécifiques (et en fait quelque chose de technique) qui devraient être saisies et appliquées dans votre projet. Il s'agit plutôt d'une réflexion sur le travail accompli. Il y a eu des moments si spéciaux qui nous ont influencés en tant qu'équipe - ralliés, tempérés et testés pour la force. J’essaierai de vous parler de ces moments, de l’atmosphère de travail en équipe, de notre râteau et de plusieurs pièges psychologiques dans lesquels nous nous enfonçons parfois.
Et je vais commencer en 2012.
Je suis arrivé en 2012 avec l'objectif principal à l'époque - travailler sur notre site Web 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), dans une autre partie de l'équipe (où j'inclus), ils ont essayé de mettre en œuvre un nouveau système, qui a été choisi selon le critère "Une fois c'est le commerce électronique le plus cher du monde, nous le considérons. " Ce sont eux qui ont «essayé de mettre en œuvre» - parce que le système résistait désespérément, et à chaque instant où il s'est avéré être réglé, il y a eu une «surprise» en réponse. Ils travaillaient beaucoup, mais avançaient à la vitesse d'un escargot.
Pour moi personnellement, la dernière goutte a été de se familiariser avec le code d'une méthode dans ce "commerce électronique le plus cher du monde", lorsque plusieurs heures de travail concentré sur un bug compliqué ont conduit au fait que la raison a été trouvée quelque part dans la balise personnalisée, qui fonctionne lorsque génération html en jsp. La tâche de cette balise personnalisée est d'afficher la somme de certaines valeurs. Ce n'est pas mauvais, les balises personnalisées sont destinées à cela. Mais la surprise s'est cachée dans le fait que certaines données de la base de données changent, le comportement des pages suivantes y est lié, et si vous appuyez sur F5, l'appel se répète, cela viole la cohérence des données. De plus, il violait de telle manière qu'il n'apparaissait qu'après quelques étapes, sur la 3ème page de la séquence. Non, cela ne me dérange pas qu'un tel "maître ninja" était dans l'équipe et avec son code a soutenu l'attention de collègues en bonne forme. Mais juste comme ça, dans le système le plus cher!
C'était vendredi. Et un collègue et moi avons passé samedi et dimanche au bureau pour déterminer quelles tâches l'entreprise pose pour le système aujourd'hui et quelles tâches il peut proposer en un an. En conséquence, comment pourrions-nous les résoudre si nous n'étions pas conduits dans le cadre de l'utilisation de ce système le plus cher et le plus rentable.
Aussitôt dit, aussitôt fait. Nous avons réalisé un projet pilote dans lequel nous avons jeté les bases du développement du nouveau site Web Sportmaster. Beaucoup de ces idées ont pris racine et en ce moment leur continuation tourne activement sur le site.
Phases pilotes et délais
2 jours Nous avons fait un microtrototype - au cours du week-end, nous dépassons notre base dans ElasticSearch, nous faisons une recherche à facettes. Woah la! Dans le même système acheté, un tel paramètre «a mangé» 2 semaines. Et ici - en seulement quelques heures! Oui, et cela fonctionne plus rapidement. Et plus vite sur commande.
2 semaines. Nous voyons un prototype, ajoutant des fonctionnalités pour une livraison personnalisée adéquate.
Par exemple, l'utilisateur a plusieurs remises et promotions qui sont pertinentes spécifiquement pour lui - puis dans les résultats de la recherche sur les produits, vous devez afficher exactement le prix qui peut être obtenu en utilisant tous les petits pains disponibles de la manière la plus rentable.
Avec les stocks, tout n'est pas si simple. Par exemple, j'ai acheté des skis, maintenant il y a une remise de 40% sur un chapeau, mais en même temps, une remise de bienvenue de 10% sur toute la commande est annulée. Oui, oui, c'est un vrai cas :) Et afin de mettre en place une telle promotion dans le système d'achat, 3 consultations avec le fournisseur ont été payées, à la suite de quoi nous avons eu de nombreux exemples de comment faire différentes autres promotions. Très diplomatique et, compte tenu du coût de la consultation, très bon sur le plan économique.
A montré à l'entreprise une démo détaillée. Ils ont promis de monter rapidement le pilote et se sont immédiatement mis au travail.
2 mois. Projet pilote - nous le réalisons sous la forme d'un site en direct avec une recherche dans l'annuaire. Recherche avec facettes, résultats de recherche - avec des remises personnelles, le pilote ressemble presque au site d'un Sportmaster, et nous avons rempli les mêmes produits. Ma chérie!
Nous ajoutons le "Eloquence: 100" de notre chef de département, et la présentation à l'entreprise a lieu le Hourra! Ils nous donnent carte blanche pour développer nous-mêmes la plateforme de commerce électronique.
Et cela signifie, gardez, les gars, l'équipe, gardez, les gars, le budget. Cool!
2 ans Retrait du site en production. Oui, longtemps. Tout ce que nous savions alors, nous n'avons essayé qu'à l'échelle du prototype. Deux personnes forment facilement une équipe soudée. Et les tâches que nous avons «cassées» - en gros, ce sont de petites dopila de «Hello World» dans les nouvelles technologies. Nous avons facilement généré de nouvelles hypothèses, les avons rapidement testées, n'avons pas eu le temps de nous y attacher et donc, sans regrets, elles les ont «tuées». Lorsque nous sommes devenus 10 personnes, nous avons extrapolé l'inertie de notre vitesse de travail à tout le monde. Et ils ont promis de tels délais pour la tâche, qui sont égaux à l'idée du beau, multipliés par notre enthousiasme.
Une situation familière? :)
Alors, savez-vous déjà ce qui va se passer ensuite?
Piège n ° 1. "Résistant à l'extrapolation"
Il est clair que les nouvelles technologies ont l'air très cool dans les présentations et montrent d'excellents résultats dans l'application de la catégorie «Hello World». Mais la réalité est généralement un peu plus éloignée de cela.
Alors voilà. Nous prenons la bibliothèque, écrivons un tas de code d'application. Nous considérons les tests unitaires comme un fardeau (nous sommes cool et nous labourons sur supersonique ici, le code est moderne et ainsi de suite). Nous changeons et modifions constamment l'API sur la route - eh bien, quel genre de tests sont là, sérieusement. Et tout cela sous la bannière de "coolly optimized the development process" (oui, maintenant c'est même effrayant de le décrire).
Et puis tout est assez évident.
Nous déployons une nouvelle construction sur uat. Les gars de l'entreprise vont joyeusement tester tout cela et appuyer sur les boutons. Parfois, ils exercent une pression assez créative - quelque chose tombe. Ensuite, allez découvrir ce qu'ils ont fait pour cela. Mais de l'autre côté du moniteur n'est pas un testeur fastidieux qui vous présente toutes les caractéristiques environnementales, en tenant compte des conditions météorologiques de la région, mais le client est en faillite. Il "ne fonctionne tout simplement pas". Donc, il est malheureux. Demandez-lui - et il sera terriblement malheureux!
Ensuite, afin de reproduire le bogue, vous devez vous lancer dans tout. Bien sûr, nous n'avons pas ignoré une seule plainte et tout réglé. Ils ont jeté les tâches prévues, mais "éteint l'incendie".
Nous nous sommes donc creusés le trou suivant.
Piège numéro 2. "Stakhanovets"
Vous n'avez pas eu le bug le plus agréable. Vous commencez à comprendre. Cela ne fonctionne pas - la colère - une tentative de régler à nouveau - une autre déception - vous spécifiez tout ce que vous pouvez - encore une fois pas que vous pensez que vous êtes déjà vieux et que vous avez tous des enfants et une hypothèque - vous essayez à nouveau - pas encore. Quelques tasses de café et tout se répète. 12-14 heures d'affilée est presque la norme. Et maintenant, quand tout est déjà à sa limite - bang, inspiration!
Peut-être, de l'extérieur, l'évaluation de l'efficacité d'une telle journée est bien et correctement visible. Mais de l'intérieur - cela peut être différent.
Dans mon cas, l'impression d'un tel travail était «j'ai fini, je suis cool, je me suis retiré». Pas toujours consciemment, mais inconsciemment - toujours!
Et asseyez-vous dessus, sans blague. Il s'avère que les métriques internes de la réussite du mouvement sont déplacées du résultat au nombre d'efforts appliqués et au niveau de ce que vous avez accompli, combien vous avez souffert, en essayant de résoudre le problème.
C'est probablement le pire piège.
De plus, ce sera plus facile et plus amusant :)
Piège numéro 3. "La puissance de Hello world"
Notre pile technologique de cette période: ElasticSearch, Hazelcast, Pentaho, freemarker (et Java, Spring, Tomcat, nginx). Freemarker n'a pas signalé les messages d'erreur de manière très informative. Mais ElasticSearch, Hazelcast, Pentaho ont dû être corrigés plusieurs fois - nous avons trouvé avec talent des cas dans lesquels ils ne fonctionnaient pas comme spécifié par la documentation.
Un démarrage facile et un pain d'épice rapide grâce à l'utilisation de nouvelles technologies sont bons, mais ils introduisent l'euphorie et réduisent la vigilance. Parce que la nouvelle technologie contient des bogues, elle contient nécessairement des bogues. Et si vous n'avez pas encore écrit à leur sujet - réjouissez-vous, c'est à vous de devenir le pionnier qui ramasse de toute façon quelque chose de tordu et va sur Google ou SO. Bien sûr, le «tordu» peut être trouvé dans des produits éprouvés, mais dans les nouveaux, c'est beaucoup plus facile.
Malgré toutes les difficultés, nous sommes entrés en production. Oui, avec des retards. Oui, pas très stable. Mais dans l'ensemble - pas de catastrophe.
Au total, je note encore une fois des pièges dans lesquels une perception saine du processus de travail est faussée.
- "Résistant à l'extrapolation" . Impressionnés par les succès actuels, nous allons extrapoler joyeusement la vitesse de développement aux projets à venir.
- "Stakhanovets . " Nous travaillons pour l'usure, nous sommes satisfaits de nous-mêmes, mais nous ne remarquons pas que les problèmes que nous résolvons sont la conséquence de nos erreurs / lacunes / négligences personnelles. Travaux à ne pas faire.
- "La puissance de Hello world . " Nous nous empressons de présenter tous les produits les plus récents et les plus intéressants en production.
Pourquoi ça a marché
Bien sûr, je n'ai pas énuméré toutes les erreurs que nous avons eues pendant cette période, mais les plus courantes, probables pour un projet de toute spécificité. Cette correction d'erreurs permet de les éviter à l'avenir.
Un peu sur la façon dont nous avons généralement réussi à créer une telle mini-startup au sein de l'entreprise et à convaincre l'entreprise de passer du système déjà acheté à quelque chose de son genre.
Condition n ° 0 . Un climat sain dans l'entreprise. Ce n'est pas seulement les «yeux brûlants» des employés et la sociabilité dans des conditions stressantes d'extraction des cookies, non. Il s'agit de toutes les interactions.
Condition n ° 1 . Croyez en ce que vous faites. Sérieusement, je ne pense pas que nous aurions au moins une certaine chance si nous devions prendre un pilote sans avoir à comprendre le système acheté "au boulon" - c'est-à-dire prendre du recul et savoir inconsciemment que ce système est plus frais et est occupé par nous.
Ce que nous avons fait: 1) comprendre le système d'achat, avec cela résolu les demandes de base de l'entreprise 2) compilé une liste de tâches qui non seulement existeront maintenant, mais le seront dans un avenir prévisible 3) ont sélectionné une solution qui fonctionne le mieux. Et puis, notre évaluation de la décision - c'était une évaluation d'experts.
Voudraient-ils nous donner quelque chose si nous venions juste et disions: "les gars, toutes ces ordures, nous ne voulons pas nous en occuper et décider de faire notre truc à partir de zéro"? À peine. Et la réponse aurait été reçue sous une forme dont on se souvient bien :)
Condition n ° 2 . La première étape est petite. Nous générons la première hypothèse et vérifions. Vous pouvez y consacrer votre temps personnel. Si vous ne voulez pas perdre votre temps, alors vous ne devriez pas du tout prendre une telle chose. Et si vous ne voulez pas tester une petite hypothèse, mais voulez le faire immédiatement cool et brillant, éloignez-vous de telles personnes!
Nous avons eu de la chance et la toute première hypothèse a fonctionné. Mais cela ne se produit pas toujours. Par exemple, dans l'un des projets suivants, lorsque l'administrateur a été promu dans le cadre d'un projet pilote similaire, seule la 18e option a fonctionné pour nous. Et les 17 premières approches du projectile ont été perdues. Soit dit en passant, dans l'histoire de la création de la zone d'administration, les rebondissements étaient au niveau de la série brésilienne, car l'équipe était composée de gars, à l'époque déjà des vétérans, de vrais «bourreaux râpés».
Condition n ° 3 . Nous faisons du MVP et recherchons la douleur chez le décideur. Bien sûr, l'horreur peut déjà se refléter sur son visage du fait que vous lui apportez une sorte d'aventure pour la trentième fois. Mais quand même. Et assurez-vous de montrer comment nous résolvons exactement ses problèmes avec notre produit.
Condition n ° 4 . Sur le genou, nous faisons rapidement un pilote qui ressemble à quelque chose comme le résultat final. Rendre tout vraiment cool est tentant, mais vous pouvez rencontrer le perfectionnisme, à cause de quoi il s'avère qu'au lieu d'un pilote, vous voulez montrer une version pilote d'un produit déjà idéal. Mais ils n'existent pas. Faites donc au moins des bâtons.
Condition n ° 5 . Produit. Le projet grandit, obtient des financements, les experts ont une solide expérience.
Et si vous êtes une startup classique, c'est le moment même où vous devez blâmer avec un coup de sifflet. Parce que les vols légers au sommet et un sentiment de bonté générale de ce qui se passe sont rapidement dispersés.
Entrer dans le produit est une collision avec des charges réelles, une intégration avec une douzaine de systèmes, et lorsque vous créez de nouvelles fonctionnalités, vous finalisez les anciennes versions dans le cadre de la maintenance. Tous ces défis sont beaucoup plus sérieux que de proposer une idée et de les résoudre, quoique bien, mais juste un problème client.
Ce sont des défis, et la croissance des compétences - se produit précisément à ce stade.
Merci d'avoir lu. Bon nouveau code!