Hej! Jag heter Alexej Pjanov och jag Àr huvudprogrammerare pÄ företaget Sportmaster. LÄt mig vara tydlig, 'huvud' betyder inte 'den mest avgörande av alla programmerare', nej, det Àr bara en titel, en charmig översÀttning för 'Senior+'.
Jag har arbetat pÄ Sportmaster sedan 2012, och under dessa Är har vÄrt utvecklingsteam tagit fram mÄnga intressanta tekniska lösningar. Men idag skulle jag vilja berÀtta om vÄrt arbete, med fokus snarare pÄ hur vi resonerade i vissa tvetydiga situationer.
I den hĂ€r artikeln kommer det inte att finnas nĂ„gra konkreta tekniska lösningar (eller ens nĂ„got tekniskt) som du bör ta och tillĂ€mpa i ditt projekt. Snarare Ă€r detta en reflektion över det arbete vi har gjort. Det har funnits speciella stunder som har pĂ„verkat oss som team â som har enat oss, hĂ€rdat oss och testat vĂ„r styrka. Om dessa moment, om atmosfĂ€ren i teamet, om vĂ„ra fĂ€llor och en rad psykologiska fĂ€llor som vi ibland fumlar oss in i, kommer jag att försöka berĂ€tta idag.
Och jag börjar just med 2012.
Jag kom in 2012 med huvudmĂ„let för den tiden â att arbeta med vĂ„r flaggskeppssajt. DĂ„ var det en 'Frankenstein-monster': en del av teamet arbetade med vĂ„rt gamla system, som inte riktigt klarade av belastningen (Bitrix), medan en annan del av teamet (inklusive mig) försökte implementera det nya system som valdes utifrĂ„n kriteriet 'Eftersom detta Ă€r den dyraste e-handelslösningen i vĂ€rlden, tar vi den'. Just 'försökte implementera' â eftersom systemet motstod desperat, och för varje moment vi lyckades förstĂ„, dök det alltid upp en 'överraskning' i respons. Vi arbetade mycket, men avancerade i snigelfart.
För mig var den sista droppen nĂ€r jag stötte pĂ„ koden för en metod i denna "dyraste e-commerce i vĂ€rlden", dĂ€r flera timmar av fokuserat arbete pĂ„ en komplicerad bugg ledde till att orsaken hittades nĂ„gonstans i custom-taggen, som körs vid genereringen av html i jsp. Syftet med denna custom-tag Ă€r att visa summan av vissa vĂ€rden. Det Ă€r inte dĂ„ligt, det Ă€r vad dessa custom-tags Ă€r avsedda för. Men överraskningen lĂ„g i att vissa data i databasen Ă€ndrades, vilket pĂ„verkade beteendet pĂ„ följande sidor, och om man tryckte pĂ„ F5 â sĂ„ upprepades anropet, vilket bröt konsistensen i datan. Det skedde pĂ„ ett sĂ€tt som bara blev synligt efter nĂ„gra steg, pĂ„ den tredje sidan i sekvensen. Nej, jag Ă€r inte emot att en sĂ„dan "ninja-mĂ€stare" finns i teamet och hĂ„ller kollegors uppmĂ€rksamhet pĂ„ tĂ„rna med sin kod. Men sĂ„ hĂ€r, i biblioteket av den dyraste systemet!
Det var en fredag. PÄ lördagen och söndagen spenderade jag och en kollega tid pÄ kontoret för att förstÄ vilka uppgifter affÀrerna stÀller pÄ systemet just idag och vilka uppgifter som kan tÀnkas dyka upp om ett Är. SÄledes, hur skulle vi lösa dessa uppgifter om vi inte var fast i ramen för att anvÀnda detta dyraste och mest frustrerande system.
Sagt och gjort. Vi gjorde en pilot, dÀr vi lade grunden för utvecklingen av den nya Sportmaster-webbplatsen. MÄnga av dessa idéer har fött nya liv och anvÀnds aktivt pÄ webbplatsen just nu.
Pilotsteg och tidsramar
2 dagar. Vi gjorde en mikropototyp - över helgen migrerade vi vÄr databas till ElasticSearch och implementerade facetterad sökning. Voilà ! I det köpta systemet tog den hÀr instÀllningen 2 veckor. Och hÀr - bokstavligt talat pÄ nÄgra timmar! Dessutom fungerar det snabbare. Faktiskt snabbare med en faktor.
2 veckor. Vi "skÀr" prototypen, lÀgger till funktionalitet för en adekvat personlig sökning.
Till exempel, om anvÀndaren har flera rabatter och kampanjer som Àr aktuella för honom - dÄ mÄste resultaten i produktsearchen visa precis det pris som kan erhÄllas genom att anvÀnda alla tillgÀngliga förmÄner pÄ det mest fördelaktiga sÀttet.
Det Ă€r inte sĂ„ enkelt med kampanjer. Till exempel, jag köpte skidor, nu fĂ„r jag 40% rabatt pĂ„ en mössa, men den vĂ€lkomnande rabatten pĂ„ 10% pĂ„ hela bestĂ€llningen tas bort. Ja-jo, detta Ă€r ett verkligt fall đ För att stĂ€lla in en sĂ„dan kampanj i köpsystemet betalades det för 3 konsultationer med leverantören, dĂ€r vi fick mĂ„nga exempel pĂ„ hur man kan göra olika andra kampanjer. Mycket diplomatiskt och, med tanke pĂ„ kostnaden för konsultationerna â ekonomiskt sett varit ganska bra.
Vi visade en detaljerad demo för företaget. Vi lovade att snabbt sÀtta ihop en pilot och började genast arbetet.
2 mĂ„nader. Pilotprojektet â vi gör det i form av en levande webbplats med sökfunktion i katalogen. Sökning med facetter, sökresultat â med personliga rabatter, piloten ser nĂ€stan ut som Sportmasters webbplats, och vi har Ă€ven laddat upp samma produkter. Godis!
Vi lÀgger till "Kraftfull Retorik:100" frÄn vÄr avdelningschef, och presentationen för företaget gÄr strÄlande! Vi fÄr fribrev för att utveckla eCommerce-plattformen sjÀlva.
Och det betyder, hÄll i er, grabbar, teamet, hÄll i er, grabbar, budgeten. Coolt va!
2 Ă„r. Lansering av webbplatsen. Ja, det tog tid. Allt vi kunde dĂ„ testade vi bara i omfattningen av prototypen. TvĂ„ personer bildar lĂ€tt ett samordnat team. Och de uppgifter som vi "bockade av" â var i stort sett smĂ„justeringar av "Hello World" i nya teknologier. Vi genererade lĂ€tt nya hypoteser, testade dem snabbt, hann inte fĂ€sta oss vid dem och dĂ€rför "dödade" vi dem utan Ă„nger. NĂ€r vi blev 10 personer extrapolerade vi vĂ„r arbetshastighet pĂ„ alla andra av ren tröghet. Och vi lovade tidsramar för uppgiftens genomförande som var lika med förestĂ€llningen om det perfekta multiplicerat med vĂ„r entusiasm.
KĂ€nns detta bekant? đ
SÄ, vet ni redan vad som kommer hÀrnÀst?
FĂ€lla nummer 1. "Super-Extrapolator"
Det Àr uppenbart att nya teknologier ser fantastiska ut i presentationer och fungerar utmÀrkt i applikationen av typen "Hello World". Men verkligheten ligger vanligtvis nÄgot lÀngre bort.
SĂ„ hĂ€r Ă€r det. Vi tar ett bibliotek, skriver massor av applikationskod. Enhetstester kĂ€nns som en börda (vi Ă€r ju coola och jobbar pĂ„ överskridande nivĂ„ hĂ€r, koden Ă€r modern och sĂ„ vidare). Vi Ă€ndrar och finslipar API:et i farten â men vilka tester, seriöst. Och allt detta under bannern "vi har optimerat utvecklingsprocessen" (ja, nu kĂ€nns det till och med skrĂ€mmande att beskriva det).
Och sedan Àr allt ganska uppenbart.
Vi rullar ut en ny version pĂ„ uat. Killarna frĂ„n affĂ€rssidan gĂ„r energiskt till verket för att testa allt och trycka pĂ„ knappar. Ibland trycker de ganska kreativt â nĂ„got slutar fungera. HĂ€r skulle man kunna gĂ„ och ta reda pĂ„ vad som har gjorts för detta. Men pĂ„ andra sidan skĂ€rmen finns det ingen besatt testare som kan ge dig alla miljöegenskaper med hĂ€nsyn till vĂ€dret i regionen, utan bestĂ€llaren frĂ„n affĂ€ren. Han sĂ€ger bara "det fungerar inte". Och det betyder att han Ă€r missnöjd. FrĂ„ga honom â och han kommer att vara fruktansvĂ€rt missnöjd!
DÄ, för att Äterskapa buggen, mÄste man gÄ och experimentera med allt. SjÀlvklart har vi inte ignorerat nÄgon klagomÄl och har fixat allt. Vi har avbrutit planerade uppgifter, men "slÀckt branden".
SÄ vi grÀvde oss ner i nÀsta grop.
FĂ€lla nr 2. "Stakhanovets"
En mindre trevlig bugg har dykt upp. Du börjar undersöka. Det fungerar inte â ilska â försöker förstĂ„ Ă€nnu en gĂ„ng â Ă€nnu en besvikelse â du preciserar allt som gĂ„r â fortfarande inte rĂ€tt â tĂ€nker pĂ„ att du redan Ă€r gammal och alla andra har barn och bolĂ„n â försöker igen â fortfarande inte rĂ€tt. NĂ„gra koppar kaffe senare, och allt upprepas. 12-14 timmar arbete i strĂ€ck â nĂ€stan som norm. Och precis nĂ€r allt Ă€r pĂ„ grĂ€nsen â pang, en upplysning!
Kanske, utifrĂ„n, sĂ„ kan bedömningen av effektiviteten av en sĂ„dan dag ses tydligt och korrekt. Men frĂ„n insidan â kan det vara olika.
I mitt fall innehöll intrycket av sĂ„dant arbete "Jag Ă€r bra, jag Ă€r fantastisk, jag löste det". Inte alltid medvetet, men omedvetet â alltid!
Och du blir beroende av detta, utan skÀmt. Det visar sig att interna mÀtningar av framgÄng flyttas frÄn resultatet till mÀngden anstrÀngningar som lagts ner och nivÄn av de bedrifter du har genomfört, hur mycket du har lidit för att lösa uppgiften.
Kanske Àr detta den mest fruktansvÀrda fÀllan.
Det kommer att bli lĂ€ttare och roligare framöver đ
FĂ€lla nr 3. "Kraften av Hello world"
VĂ„r teknikstack under den perioden: ElasticSearch, Hazelcast, Pentaho, freemarker (och beprövad Java, Spring, Tomcat, nginx). Freemarker gav inte sĂ€rskilt informativa felmeddelanden. Men ElasticSearch, Hazelcast och Pentaho fick vi patcha flera gĂ„nger â vi hittade pĂ„ ett talangfullt sĂ€tt fall dĂ€r de inte fungerade som dokumentationen angav.
En enkel start och snabba fördelar med anvĂ€ndning av ny teknologi Ă€r bra, men de kan ge en kĂ€nsla av eufori och minska vaksamheten. För eftersom ny teknologi har buggar, har den alltid buggar. Och om ingen har skrivit om dem Ă€nnu â var glad, just du kommer att bli den första som hittar nĂ„got felaktigt och börja googla eller frĂ„ga pĂ„ SO. SjĂ€lvklart kan "felaktigt" hittas i beprövade produkter, men i nya â Ă€r det mycket enklare.
Trots alla svĂ„righeter har vi nĂ„tt produktion. Ja, med fördröjningar. Ja, inte sĂ€rskilt stabilt. Men i stort sett â utan katastrofer.
Jag vill Ànnu en gÄng pÄpeka de fÀllor dÀr en sund uppfattning om arbetsprocessen förvrÀngs.
- âExtrapolatornâ. PĂ„verkade av nuvarande framgĂ„ngar gĂ„r vi framĂ„t och extrapolerar glĂ€djen av utvecklingshastigheten pĂ„ kommande projekt.
- âStakhanovetâ. Vi arbetar hĂ„rt, Ă€r nöjda med oss sjĂ€lva, men inser inte att problemen vi löser Ă€r konsekvenser av vĂ„ra egna misstag/brister/försummelser. Arbete som inte borde göras.
- âKraften av Hello Worldâ. Vi skyndar oss att implementera det nyaste och mest intressanta i produktion.
Varför allt gick bra
SjÀlvklart har jag inte listat alla de misstag vi hade under denna tid, men de mest allmÀnna, sannolika för projekt av alla typer. Att registrera misstag hjÀlper till att undvika dem i framtiden.
Lite om hur vi egentligen lyckades skapa en sÄdan mini-startup inom företaget och övertyga affÀrerna att lÀmna ett redan köpt system för nÄgot eget.
Villkor â0. En sund atmosfĂ€r inom företaget. Det handlar inte bara om "brinnande ögon" hos medarbetarna och deras kommunikabilitet i stressade situationer, nej. Det handlar om alla interaktioner.
Villkor â1. Att tro pĂ„ det man gör. Seriöst, jag tror inte att vi hade haft nĂ„gon chans om vi gett oss pĂ„ piloten utan att ha dykt ner i det köpta systemet "till skruven" â det vill sĂ€ga, dragit oss tillbaka och undermedvetet vetat att det systemet Ă€r bĂ€ttre och kommer att övervinna oss.
Vad vi gjorde: 1) vi satte oss in i det köpta systemet, med hjĂ€lp av det löste vi företagets huvudfrĂ„gor 2) vi gjorde en lista över uppgifter som inte bara finns nu utan kommer att finnas inom överskĂ„dlig framtid 3) vi valde en lösning som passar bĂ€ttre. Och dĂ„, vĂ„r bedömning av lösningen â var en bedömning av experter.
Skulle de ge oss nĂ„got om vi bara kom och sa "hörni, allt suger, vi vill inte brĂ„ka med det hĂ€r och har beslutat att starta om frĂ„n grunden"? Troligtvis inte. Och svaret skulle ges pĂ„ ett sĂ€tt som man minns vĂ€l đ
Villkor nr 2. Vi börjar med ett litet steg. Vi genererar den första hypotesen och testar den. Man kan ocksĂ„ anvĂ€nda sin egen tid till detta. Om man inte vill lĂ€gga tid pĂ„ det â dĂ„ bör man överhuvudtaget inte ge sig in i sĂ„nt. Och om man inte vill testa en liten hypotes, utan vill göra nĂ„got riktigt bra och blĂ€ndande direkt â hĂ„ll er borta frĂ„n sĂ„dana mĂ€nniskor!
Vi hade tur och den första hypotesen fungerade. Men sÄ Àr det inte alltid. Till exempel, i ett av de kommande projekten, nÀr vi drev adminpanelen i en liknande pilot, fungerade bara den 18:e varianten för oss. Och de första 17 tillvÀgagÄngssÀtten var helt förgÀves. Förresten, i historien om skapandet av adminpanelen var plot-twists pÄ nivÄ med brasilianska serier, eftersom teamet bestod av killar som redan var veteraner, riktiga "gamla rÀvar".
Villkor nr 3. Vi gör en MVP och identifierar smÀrtpunkter hos beslutsfattaren. SjÀlvklart kan han ha skrÀck i ansiktet redan av det faktum att ni för trettioende gÄngen kommer med en ny idé. Men hur som helst. Och vi visar absolut hur vi löser hans problem med vÄr produkt.
Villkor nr 4. Snabbt gör vi en pilotversion som ser ut ungefÀr som det slutgiltiga resultatet. Att göra allt riktigt bra Àr frestande, men man kan fastna i perfektionism, vilket resulterar i att man istÀllet för en pilot vill visa en pilotversion av redan en perfekt produkt. SÄdana finns inte. SÄ gör det i alla fall av nÄgra pinnar.
Villkor nr 5. Produkten. Projektet vÀxer, fÄr finansiering, och specialister med gedigen erfarenhet kommer in.
Och om du Àr den klassiska startupsgrundaren, dÄ Àr det just det hÀr ögonblicket dÄ du snabbt bör dra dig tillbaka. För lÀtta flygturer pÄ högsta nivÄ och kÀnslan av allmÀn vÀlbehag försvinner snabbt.
GĂ„ till produktion â det Ă€r en konfrontation med verkliga pĂ„frestningar, integration med ett tiotal system, och nĂ€r man skapar en ny funktionalitet jobbar man samtidigt med att förbĂ€ttra gamla versioner som del av underhĂ„llet. Allt detta Ă€r utmaningar som Ă€r mycket mer seriösa Ă€n att komma pĂ„ en idĂ© och lösa Ă„tminstone ett vĂ€l definierat problem för en kund.
Det hÀr Àr utmaningar, och tillvÀxt av fÀrdigheter sker just i detta skede.
Tack för att du lÀste. Happy New Code!
KĂ€lla: habr.com
