Hej! Mit navn er Alexey Pjankov, jeg er hovedprogrammer i Sportmaster. Jeg vil sige med det samme, at "hoved" ikke betyder "den vigtigste af alle programmere", nej, det er kun et navn, en charmerende oversættelse for "Senior+".
Jeg har arbejdet i Sportmaster siden 2012, og i løbet af denne tid har vores udviklingsteam skabt mange interessante tekniske løsninger. Men i dag vil jeg gerne tale om vores arbejde med fokus på, hvordan vi tænkte i visse tvetydige situationer.
Denne artikel vil ikke indeholde specifikke tekniske løsninger (eller overhovedet noget teknisk), som man bør tage og implementere i sine projekter. Snarere er det en refleksion over det arbejde, vi har udført. Der var særlige øjeblikke, der påvirkede os som team — samlede os, hærdede os og testede os på vores styrker. Om disse øjeblikke, om atmosfæren i teamet, om vores faldgruber og en række psykologiske feller, som vi nogle gange selv falder i, vil jeg forsøge at fortælle i dag.
Jeg vil starte netop fra 2012.
Jeg kom i 2012 med det primære mål for den tid — at arbejde på vores flagskibswebsted. På det tidspunkt var det en "Frankenstein-monster": en del af teamet arbejdede med vores gamle system, som ikke klarede belastningerne særlig godt (Bitrix), mens en anden del af teamet (hvor jeg også var med) forsøgte at implementere et nyt system, som vi valgte efter kriteriet "Da det er den dyreste e-commerce i verden, tager vi den". Det var faktisk "forsøgte at implementere" — fordi systemet gjorde voldsom modstand, og til hvert problem, vi fik løst, opstod der altid en "overraskelse" som svar. Vi arbejdede meget, men gjorde fremskridt i sneglefart.
For me, the last straw was encountering the code of a method in this "most expensive e-commerce in the world," when several hours of focused work on a convoluted bug led to the discovery of the cause somewhere in the custom-tag that executes during the HTML generation in JSP. The purpose of this custom-tag is to display the sum of certain values. That's fine; that's what custom-tags are for. But the surprise lay in the fact that during this process, some data in the database was altered, which affects behavior on subsequent pages, and if you press F5 — the call repeated, disrupting data consistency. Moreover, it disrupted it in such a way that it only manifested after several steps, on the 3rd page of the sequence. No, I don't mind having such a "master ninja" in the team keeping his colleagues alert with his code. But to have it this way, in the library of the most expensive system!
It was Friday. And we spent Saturday and Sunday in the office with the goal of figuring out what tasks the business is currently setting for the system today and what challenges it might come up with in a year. Accordingly, how we would solve them if we hadn't been constrained by the framework of this most expensive and infuriating system.
Done. We created a pilot project laying the foundation for the development of the new Sportmaster website. Many of these ideas have taken root, and their continuation is actively running on the site right now.
Pilot stages and timelines
2 days. We created a micro-prototype — over the weekend, we migrated our database to ElasticSearch, implementing faceted search. Voila! In that very purchased system, such a setup took 2 weeks. Here, it was done in just a couple of hours! And it works faster, significantly so.
2 weeks. We are "chop-chopping" the prototype, adding functionality for adequate personalized output.
For example, if a user has several discounts and promotions that are specifically relevant to them — then the search results for products need to display exactly the price that can be obtained by applying all available perks in the most beneficial way.
Med kampagner er alt ikke så enkelt. For eksempel, hvis du køber ski, får du nu 40% rabat på en hat, men samtidig annulleres velkomstrabatten på 10% på hele ordren. Ja, det er en reel case 🙂 Og for at indstille en sådan kampagne i købesystemet blev der betalt for 3 konsultationer med leverandøren, hvor vi fik mange eksempler på, hvordan man kan lave forskellige andre kampagner. Meget diplomatisk, og i betragtning af omkostningerne til konsultationerne — en rigtig god besparelse.
Vi viste virksomheden en detaljeret demo. Vi lovede hurtigt at samle et pilotprojekt og gik straks i gang.
2 måneder. Pilotprojektet — vi laver det i form af en live hjemmeside med søgning i kataloget. Søgning med facetfilter, søgeresultaterne viser personlige rabatter, piloten ser næsten ud som Sportmaster's hjemmeside, og vi har endda uploadet de samme varer. En kæmpe succes!
Vi tilføjer 'Rhetoric:100' fra vores afdelingsleder, og præsentationen for virksomheden går igennem med bravour! Vi får frie hænder til selv at udvikle eCommerce-platformen.
Og det betyder, hold fast, drenge, hold styr på budgettet. Fedt, ikke?
2 år. Lancerer hjemmesiden i produktion. Ja, det tog lang tid. Alt hvad vi dengang kunne, forsøgte vi kun i prototypens omfang. To personer kan let danne et velfungerende team. Og de opgaver, vi 'fik klaret' — det var stort set blot små justeringer af 'Hello World' i nye teknologier. Vi genererede let nye hypoteser, testede dem hurtigt, og da vi ikke nåede at forpligte os, 'dræbte' vi dem uden fortrydelse. Da vi blev 10 personer, ekstrapolerede vi instinktivt vores arbejdshastighed til alle de andre. Og vi lovede opgavetidslinjer, der var lig med vores forestilling om det perfekte ganget med vores entusiasme.
Kender du det? 🙂
Så, ved du allerede, hvad der kommer næste?
Fælde nr. 1. 'Ekstrapolatoren'
Det er klart, at nye teknologier ser meget flotte ud i præsentationer og viser sig godt i eksempler af typen 'Hello World'. Men virkeligheden ligger normalt lidt længere væk.
Sådan er det. Vi tager et bibliotek og skriver en masse anvendelseskode. Unit-tests ser vi som en byrde (vi er jo seje og arbejder i superhastighed, koden er moderne osv.). Vi ændrer og opdaterer API'erne undervejs — hvad skal der være af tests, seriøst. Og alt dette under overskriften 'vi har optimeret udviklingsprocessen' (ja, det er endda skræmmende at beskrive nu).
Og så bliver alt ret åbenlyst.
Vi ruller en ny build ud på UAT. Folkene fra forretningen går energisk i gang med at teste og trykke på knapperne. De trykker nogle gange ret kreativt — noget falder ud. Her burde man gå hen og finde ud af, hvad der er blevet lavet for at løse det. Men der på den anden side af skærmen sidder ikke en fræk tester, der kan give dig alle specifikationer for miljøet med hensyn til vejret i regionen, men en kunde fra forretningen. Han mener bare, "det virker ikke." Og det betyder, at han er utilfreds. Spørg ham — og han vil værre utilfreds!
For at kunne reproducere fejlen, skal man gå ud og trykke sig frem ad alle muligheder. Selvfølgelig har vi ikke overset nogen klager, og vi har fikset alle problemstillinger. Vi droppede planlagte opgaver, men "slukkede ilden."
Så vi gravede en ny fælde.
Fælde nummer 2. "Stakhanovets"
Der frustrerer en ubehagelig fejl dig. Du begynder at finde ud af det. Det fungerer ikke — vrede — forsøger at finde ud af det igen — ny skuffelse — spørger alt hvad du kan — igen ikke det rigtige — tænker på, at du allerede er gammel og har børn og realkreditlån — prøver igen — stadig ikke rigtigt. Et par kopper kaffe senere, og det hele gentager sig. 12-14 timers sammenhængende arbejde — næsten som normen. Og så, når alle er på kanten, bang, en åbenbaring!
Måske, set fra siden, er bedømmelsen af effektiviteten af en sådan dag synlig og korrekt. Men indefra kan det være anderledes.
I mit tilfælde indeholdt indtrykket af sådan arbejde "Jeg er fantastisk, jeg er sej, jeg har løst det." Ikke altid bevidst, men ubevidst — altid!
Og det bliver man afhængig af, uden at spøge. Det ender med, at de interne målinger for succes forskydes fra resultatet til mængden af anvendte kræfter og niveauet for de bedrifter, du har opnået, hvor meget du har lidt, mens du forsøgte at løse opgaven.
Det må være den mest forfærdelige fælde.
Det bliver lettere og sjovere herfra 🙂
Fælde nummer 3. "Kraften i Hello world"
Vores teknologistak i den periode: ElasticSearch, Hazelcast, Pentaho, freemarker (og velkendte Java, Spring, Tomcat, nginx). Freemarker gav ikke særlig informative fejlmeddelelser. Men ElasticSearch, Hazelcast, Pentaho skulle vi patch'e flere gange — vi fandt talentfuldt sager, hvor de ikke fungerede som angivet i dokumentationen.
En nem start og hurtige fordele ved at bruge ny teknologi er godt, men de kan føre til eufori og sænke årvågenheden. For ny teknologi har fejl, det har bestemt fejl. Og hvis de ikke er blevet rapporteret endnu - glæd dig, det er dig, der står over for at finde noget skævt og skal til at google eller søge hjælp på SO. Selvfølgelig kan 'skævt' findes i etablerede produkter, men i nye er det meget lettere.
På trods af alle udfordringer, nåede vi ud i produktion. Ja, med lag. Ja, ikke særlig stabilt. Men samlet set - uden katastrofer.
Så lad mig endnu engang påpege de fælder, hvor det sunde syn på arbejdsprocessen forvrænges.
- «Ekstrapolator-geniet». Under indtrykket af de nuværende succeser går vi fremad og ekstrapolerer glædeligt udviklingshastigheden til kommende projekter.
- «Stakhanovets». Vi arbejder til det yderste, er tilfredse med os selv, men bemærker ikke, at de problemer, vi løser, er konsekvenserne af vores egne fejl/mangler/forvildelser. Works not to be done.
- «Kraften i Hello World». Vi haster med at implementere alt det nyeste og mest interessante i produktion.
Hvorfor det lykkedes
Selvfølgelig har jeg ikke nævnt alle de fejl, vi har haft i denne tid, men de mest almindelige, der er sandsynlige for ethvert projekt. Denne registrering af fejl hjælper os med at undgå dem i fremtiden.
Lidt om, hvordan vi overhovedet lykkedes med at skabe sådan en mini-startup inden for virksomheden og overbevise forretningen om at skifte fra det allerede købte system til noget selvudviklet.
Betingelse №0. Et sundt klima i virksomheden. Det handler ikke kun om de „brændende øjne“ fra medarbejderne og kommunikation i stressede forhold til produktionen af småkager, nej. Det handler om al interaktion.
Betingelse №1. At tro på det, man gør. Seriøst, jeg tror ikke, vi ville have haft nogen chance, hvis vi havde startet piloten uden at have undersøgt det købte system „til bolten“ - det vil sige, tilbageholdende og ubevidst vidende, at dette system er bedre og vil overgå os.
Hvad vi gjorde: 1) Vi forstod det købte system, og ved hjælp deraf løste vi de vigtigste anmodninger fra forretningen 2) Vi udarbejdede en opgaveliste, som ikke blot er aktuel nu, men også vil være det i overskuelig fremtid 3) Vi fandt en løsning, som passer bedre. Og så var vores bedømmelse af løsningen en vurdering af eksperterne.
Ville de give os noget, hvis vi bare kom og sagde: "fyre, alt er skidt, vi vil ikke beskæftige os med det og har besluttet at starte fra bunden"? Sandsynligvis ikke. Og svaret ville komme i en form, der ville være svært at glemme 🙂
Betingelse nr. 2. Vi tager det første skridt lille. Vi genererer den første hypotese og tester den. Man kan bruge sin egen tid på det. Hvis man ikke ønsker at bruge sin tid — så er det slet ikke værd at tage fat på sådan et projekt. Og hvis man ikke ønsker at teste en lille hypotese, men hellere vil gøre det stort og flot med det samme — så hold dig væk fra sådanne personer!
Vi var heldige, og den allerførste hypotese fungerede. Men det sker ikke altid. For eksempel i et af de følgende projekter, hvor vi promoverede adminpanelet i rammerne af et lignende pilotprojekt, virkede kun den 18. mulighed. Og de første 17 tilgange til problemet var spildt. I øvrigt, i historien om oprettelsen af adminpanelet var plotvendingerne på niveau med brasilianske sæbeoperaer, fordi holdet bestod af fyre, der på det tidspunkt allerede var veteraner, ægte "gamle ræve".
Betingelse nr. 3. Vi laver MVP og identificerer smertepunkterne hos beslutningstageren. Selvfølgelig kan der allerede være et udtryk af rædsel i hans ansigt bare ved det faktum, at du for den tredive gang præsenterer ham for en eller anden idé. Men alligevel. Og vi viser absolut, hvordan vi løser hans problemer med vores produkt.
Betingelse nr. 4. Vi laver hurtigt en prototype, der ser omtrent ud som det endelige resultat. At gøre alt virkelig fantastisk er fristende, men man kan støde ind i perfektionisme, som kan føre til, at man vil vise en pilotversion af et allerede perfekt produkt. Det findes ikke. Derfor skal du bare lave det, selv hvis det kun er med klodser.
Betingelse nr. 5. Produktet. Projektet vokser, får finansiering, der kommer specialister med solid erfaring.
Og hvis du er en klassisk startup-grundlægger, så er det det øjeblik, hvor du skal tage flugten. Fordi lette flyvninger højt oppe og følelsen af generel harmoni hurtigt forsvinder.
At gå i produktion — det er at møde reelle belastninger, integration med et dusin systemer, og når du skaber nye funktioner, så arbejder du samtidig på at vedligeholde de gamle versioner. Alt dette er udfordringer, der er meget mere alvorlige end blot at finde på en idé og løse, om end godt, blot et enkelt problem for en kunde.
Det er her udfordringerne og udviklingen af færdighederne sker.
Tak for at læse med. Happy New Code!
Kilde: habr.com
