Bună! Mă numesc Alexey P'ankov, sunt programatorul principal la compania Sportmaster. Pot spune de la început că „principal” nu înseamnă „cel mai important dintre toți programatorii”, nu, este doar un nume, o traducere plăcută pentru „Senior+".
La compania Sportmaster lucrez din 2012, iar în acest timp echipa de dezvoltare a realizat multe soluții interesante din punct de vedere tehnic. Dar astăzi aș dori să povestesc despre munca noastră, punând accent pe modul în care am reflectat asupra unor situații dificile.
În acest articol nu vor fi soluții tehnice specifice (și, de fapt, nimic tehnic) pe care să le luați și să le aplicați în proiectul vostru. Mai degrabă, este o reflecție asupra muncii realizate. Au fost momente speciale care ne-au influențat ca echipă — ne-au unit, ne-au întărit și ne-au testat rezistența. Despre aceste momente, despre atmosfera de lucru în echipă, despre capcanele noastre și o serie de capcane psihologice în care ne cădem uneori singuri, voi încerca să povestesc astăzi.
Și voi începe exact cu anul 2012.
Am venit în 2012 cu scopul principal pe atunci — să lucrez la site-ul nostru emblematic. La acea vreme era un „monstru Frankenstein”: o parte a echipei lucra cu sistemul nostru vechi, care nu făcea față foarte bine sarcinilor (Bitrix), în cealaltă parte a echipei (din care făceam și eu parte) încercam să implementăm un nou sistem, pe care l-am ales pe criteriul „Dacă este cel mai scump e-commerce din lume, îl luăm”. Anume „încercam să implementăm” — pentru că sistemul se opunea cu disperare, iar pentru fiecare problemă la care reușeam să găsim o soluție, apărea cu siguranță un „surpriză” ca răspuns. Am muncit mult, dar avansam cu viteza unei melci.
Pentru mine, ultimul strop a fost întâlnirea cu codul unei metode din această „cea mai scumpă e-commerce din lume”, când câteva ore de muncă concentrată asupra unei erori complicate au dus la descoperirea că problema se afla undeva în custom-tag, care este activat în timpul generării html în jsp. Sarcina acestui custom-tag este de a afișa suma unor valori. Este bine, pentru asta este destinat acest custom-tag. Dar surpriza s-a ascuns în faptul că, în acest proces, unele date din baza de date sunt modificate, iar acest lucru afectează comportamentul pe paginile următoare, și dacă apăsați F5 — apelul se repetă, afectând consistența datelor. Și se deteriora în așa fel încât apărea doar după câteva pași, pe a 3-a pagină din secvență. Nu, nu am nimic împotriva unui „maestru-ninja” în echipă care să își mențină colegii în formă cu codul său. Dar nu așa, în biblioteca celei mai scumpe sisteme!
A fost vineri. Iar sâmbăta și duminica le-am petrecut cu un coleg în birou, având ca scop să înțelegem ce provocări are business-ul pentru sistem chiar astăzi și ce provocări ar putea imagina peste un an. Respectiv, cum le-am rezolva dacă nu am fi constrânși de utilizarea acestei celei mai scumpe și celei mai frustrante sisteme.
S-a spus — s-a făcut. Am realizat un pilot, în care am pus fundația pentru dezvoltarea noului site Sportmaster. Multe dintre aceste idei s-au concretizat și chiar acum continuarea lor este activ pe site.
Etapele pilotului și termenele limită
2 zile. Am realizat un microprototip — în weekend am transformat baza noastră în ElasticSearch, am realizat căutare facete. Voilà! În acea sistem cumpărată, o astfel de configurare a „mâncat” 2 săptămâni. Aici — literalmente în câteva ore! Și funcționează mai rapid. Mai rapid cu un ordin.
2 săptămâni. „Creăm” prototipul, adăugăm funcționalități pentru o livrare personalizată adecvată.
De exemplu, utilizatorul are mai multe reduceri și oferte care sunt valabile pentru el — atunci, în rezultatele căutării produselor, trebuie să fie afișată exact acea preț, pe care o poate obține aplicând toate beneficiile disponibile în cel mai avantajos mod.
Cu promoțiile nu e chiar atât de simplu. De exemplu, am cumpărat schiuri, acum am 40% reducere la căciulă, dar se anulează discountul de bun venit de 10% la toată comanda. Da, da, acesta este un caz real 🙂 Și pentru a configura o astfel de promoție în sistemul de achiziții, s-au plătit 3 consultanțe cu furnizorul, rezultând în multe exemple de cum să facem diferite alte oferte. Foarte diplomatic și, având în vedere costul consultanțelor — foarte bine din punct de vedere economic.
Am arătat o demo detaliată afacerii. Au promis să pregătească rapid un proiect pilot și au trecut imediat la treabă.
2 luni. Proiectul pilot — îl facem sub forma unui site live cu căutare în catalog. Căutare cu facete, rezultatele căutării — cu discounturi personale, pilotul arată aproape ca site-ul Sportmaster, iar produsele sunt exact cele pe care le-am urcat. O desfătare!
Adăugăm „Cunoaștere:100” șefului nostru de departament, iar prezentarea afacerii decurge minunat! Ni se dă liber să dezvoltăm singuri platforma eCommerce.
Asta înseamnă, păstrați-vă, băieți, echipa, păstrați-vă, băieți, bugetul. E grozav, nu?
2 ani. Lansarea site-ului în producție. Da, a durat mult. Tot ce știam atunci, am încercat doar la scala prototipului. Două persoane formează ușor o echipă bine coordonată. Iar sarcinile pe care le „bifam” — în mare parte erau mici ajustări ale „Hello World” în noi tehnologii. Generam ușor noi ipoteze, le verificam rapid, fără să ne atașăm și, prin urmare, fără regrete le „anihilam”. Când am fost 10 persoane, în mod inert, am extrapolat viteza noastră de lucru la toți ceilalți. Și am promis termene de execuție a sarcinilor, care sunt egale cu viziunea despre frumos înmulțită cu entuziasmul nostru.
O situație cunoscută? 🙂
Atunci, știți deja ce va urma?
Capcana nr. 1. „Extrapolatorul grozav”
E clar că noile tehnologii arată foarte bine în prezentări și se comportă excelent în aplicațiile de tip „Hello World”. Dar realitatea de obicei se află puțin mai departe de asta.
Așadar. Luăm biblioteca, scriem o grămadă de cod aplicativ. Considerăm testele unitare o povară (suntem grozavi și muncim la viteze supersonice, codul e modern și așa mai departe). Schimbăm constant și îmbunătățim API-ul pe parcurs — serios, ce teste să facem aici. Și toate acestea sub steagul „am optimizat procesul de dezvoltare” (da, acum e terifiant să descriu asta).
Și mai departe, totul devine destul de evident.
Lansăm o nouă versiune pe uat. Colegii din afaceri sunt foarte activi în testarea acestui lucru și în apăsarea butoanelor. Apasă uneori destul de creativ - ceva se oprește. Ar trebui să mergem să aflăm ce s-a făcut pentru asta. Dar de cealaltă parte a monitorului nu se află un tester care să îți ofere toate caracteristicile mediu, luând în considerare vremea din regiune, ci clientul din afaceri. El are pur și simplu un „nu funcționează”. Asta înseamnă că nu este mulțumit. Întreabă-l - și el va fi nemulțumit!
Atunci, pentru a reproduce bug-ul, trebuie să mergi și să verifici totul prin încercări. Desigur, nu am ignorat nicio plângere și am rezolvat totul. Am abandonat sarcinile planificate, dar „stingea incendiul”.
Așa că ne-am săpat următoarea gropiță.
Capcana nr. 2. „Stahanovistul”
Îți apare un bug neplăcut. Începi să te descurci. Nu reușești - începe supărarea - încerci din nou - doboara iar - clarifici tot ce se poate - din nou nu este corect - te gândești că ești deja bătrân și toată lumea are copii și ipoteci - încerci din nou - din nou nu este corect. Câteva căni de cafea mai târziu, și totul se repetă. 12-14 ore de muncă continuu - aproape ca o normă. Și când totul pare să fie la limita - bam, o revelație!
Poate, din exterior, evaluarea eficienței unei zile de acest gen se vede bine și corect. Dar din interior - poate fi diferit.
În cazul meu, impresia muncii de acest tip conținea „Sunt grozav, sunt fain, am reușit”. Nu întotdeauna conștient, dar inconștient - întotdeauna!
Și te atașezi de asta, fără glume. Se pare că metricile interne de succes se mută de la rezultat la cantitatea de efort depus și nivelul de acte de bravură pe care le-ai realizat, cât de mult ai suferit încercând să rezolvi o problemă.
Probabil, aceasta este cea mai înfricoșătoare capcană.
Mai departe va fi mai ușor și mai distractiv 🙂
Capcana nr. 3. „Puterea Hello world”
Tehnologiile noastre din acea perioadă: ElasticSearch, Hazelcast, Pentaho, freemarker (și Java, Spring, Tomcat, nginx bine testate). Freemarker oferea mesaje de eroare destul de puțin informative. În schimb, ElasticSearch, Hazelcast, Pentaho a trebuit să fie patch-uite de mai multe ori - am găsit cu talent cazuri în care acestea nu funcționau conform documentației.
Un început ușor și prăjituri rapide datorită utilizării unei noi tehnologii sunt grozave, dar acestea creează o stare de euforie și scad vigilența. Pentru că noua tehnologie conține erori, cu siguranță conține erori. Și dacă nu au fost încă raportate - bucură-te, exact tu ești cel care trebuie să devină pionierul care va descoperi ceva greșit și va merge să caute pe Google sau pe SO. Desigur, este posibil să găsești „greșeli” în produsele verificate, dar în cele noi este mult mai ușor.
Cu toate dificultățile, am ajuns în producție. Da, cu întârziere. Da, nu foarte stabil. Dar, în general, nu am avut catastrofe.
Deci, încă o dată, voi sublinia capcanele în care se distorsionează percepția sănătoasă a procesului de muncă.
- «Extrapolatorul cool». Sub impresia succeselor actuale, continuăm și extrapolăm cu bucurie viteza de dezvoltare pentru proiectele viitoare.
- «Stahanovistul». Lucrăm până la epuizare, suntem mulțumiți de noi înșine, dar nu observăm că problemele pe care le soluționăm sunt rezultatul greșelilor / neatențiilor / neglijențelor noastre personale. Lucruri care nu trebuie făcute.
- «Puterea Hello world». Ne grăbim să implementăm în producție tot ceea ce este nou și interesant.
De ce a funcționat totul
Desigur, nu am enumerat toate greșelile pe care le-am avut în acest timp, dar cele mai comune, probabile pentru un proiect de orice specificitate. O astfel de fixare a greșelilor ajută la evitarea lor în viitor.
Puțin despre cum am reușit să creăm un astfel de mini-startup în interiorul companiei și să convingem afacerea să renunțe la sistemul deja achiziționat pentru ceva scris de noi înșine.
Condiția nr. 0. Un climat sănătos în companie. Nu este vorba doar despre „ochii aprinși” ai angajaților și comunicabilitatea în condiții stresante de obținere a prăjiturilor, nu. Este vorba despre toate interacțiunile.
Condiția nr. 1. A crede în ceea ce faci. Serioux, nu cred că am fi avut vreo șansă, dacă ne-am fi ocupat de pilot, fără a analiza sistemul achiziționat „până la șurub” - adică, întorcându-ne și știind subconștient că acest sistem este mai bun și ne va înfrunta.
Ce am făcut: 1) ne-am lămurit cu sistemul achiziționat, folosindu-l pentru a rezolva cererile principale ale afacerii 2) am întocmit o listă de sarcini, care nu sunt doar cele de acum, ci și vor exista într-un viitor apropiat 3) am găsit soluția cea mai potrivită. Și atunci, evaluarea soluției noastre a fost evaluarea experților.
Ne-ar oferi ceva dacă am veni și am spune, de exemplu, „băieți, totul e prost, nu vrem să ne ocupăm cu asta și am decis să facem totul de la zero”? Probabil că nu. În plus, răspunsul ar veni într-o formă care ar rămâne bine întipărită în memorie 🙂
Condiția nr. 2. Facem primul pas mic. Generăm prima ipoteză și o verificăm. Poți să îți dedici și timpul personal pentru asta. Dacă nu vrei să îți pierzi timpul — atunci nu ar trebui să te apuci de așa ceva. Iar dacă nu vrei să verifici o mică ipoteză, ci vrei să faci totul din prima, cu strălucire — stai departe de astfel de oameni!
Am avut noroc și prima ipoteză a funcționat. Dar așa nu se întâmplă întotdeauna. De exemplu, în unul din proiectele următoare, când am promovat un panou de administrare în cadrul unui pilot similar, am avut succes doar cu varianta a 18-a. Primele 17 abordări au fost în van. Apropo, în povestea creării panoului de administrare, răsturnările de situație au fost la nivelul telenovelelor braziliene, deoarece echipa era formată din băieți, deja veterani, adevărați „bătrâni în ale jocului”.
Condiția nr. 3. Facem un MVP și căutăm durerea decidentului. Desigur, pe fața lui poate reflecta deja groaza că îi aduci pentru a 30-a oară o idee. Dar totuși. Și trebuie să arătăm exact cum rezolvăm problemele lui cu produsul nostru.
Condiția nr. 4. Facem rapid un pilot pe genunchi, care arată aproximativ ca rezultatul final. Să faci totul perfect - este tentant, dar poți să te împiedici de perfecționism, care va face să vrei să arăți o versiune pilot deja a unui produs ideal. Dar acestea nu există. Așa că, pur și simplu, fă ceva din bețe.
Condiția nr. 5. Produs. Proiectul crește, primește finanțare, vin specialiști cu experiență solidă.
Și dacă ești un startup-er clasic, atunci acesta este momentul în care trebuie să te retragi rapid. Pentru că zborurile ușoare pe cele mai înalte culmi și senzația de bunăstare generală se risipesc rapid.
Lansarea în producție - este o confruntare cu sarcini reale, integrarea cu zeci de sisteme, iar atunci când creezi o nouă funcționalitate, concomitent, în cadrul asistenței, îmbunătățești versiunile mai vechi. Toate acestea sunt provocări mult mai serioase decât să ai o idee și să rezolvi, chiar dacă bine, o singură problemă a clientului.
Acestea sunt provocări, iar dezvoltarea abilităților se întâmplă exact în această etapă.
Mulțumesc pentru lectură. Happy New Code!
Sursa: habr.com
