Helló! A nevem Alekszej Pjankov, a Sportmaster cég vezető programozója vagyok. Azonnal elmondom, hogy a „vezető” nem azt jelenti, hogy „a legfontosabb programozó”, nem, ez csupán egy elnevezés, egy kedves fordítás a „Senior+” számára.
A Sportmaster cégnél 2012 óta dolgozom, és ez idő alatt a fejlesztőcsapatunk rengeteg technikailag érdekes megoldást készített. De ma inkább arról szeretnék beszélni, hogy hogyan gondolkodtunk bizonyos, egyértelműtlen helyzetekben.
Ebben a cikkben nem lesznek konkrét technikai megoldások (vagy bármilyen technikai dolog), amelyeket csak úgy átemelhetnél a projektedbe. Inkább a végzett munkánkról való reflexióról van szó. Voltak különleges pillanatok, amelyek hatással voltak ránk csapatként — összekovácsoltak, edzettek és próbára tettek minket. Ezekről a pillanatokról, a csapatmunkánk légköréről, a buktatóinkról és egy sor pszichológiai csapdáról, amelyekbe néha magunkat tereljük, szeretném ma elmesélni.
2012-től fogom kezdeni.
2012-ben érkeztem a fő célommal, hogy dolgozzak a zászlóshajónk honlapján. Akkoriban ez egy „Frankenstein szörny volt”: a csapat egy része a régi rendszerünkkel dolgozott, ami nem nagyon bírta a terhelést (Bitrix), míg a csapat másik része (ahová én is tartoztam) megpróbálta bevezetni az új rendszert, amelyet a „Mivel ez a legdrágább e-kereskedelem a világon, ezért választottuk” kritériummal választottunk. Valójában „megpróbáltuk bevezetni” — mert a rendszer kétségbeesetten ellenállt, és minden egyes megoldani kívánt problémához feltétlenül érkezett egy „meglepetés” válaszként. Rengeteget dolgoztunk, de a lépések csak csiga ütemben haladtak.
Számomra az utolsó cseppet az jelentette, amikor megismertem egy módszer kódját a "világ legdrágább e-kereskedelmében", amikor több órányi koncentrált munka egy zavaros hibán arra vezetett, hogy az ok valahol egy custom-tagben rejtőzött, ami a HTML generálásakor működik a JSP-ben. Ennek a custom-tagnek a feladata, hogy megjelenítse valamilyen mennyiségek összegét. Ez nem rossz, ennek a custom-tagnek ez a célja. De a meglepetés abban rejlik, hogy közben módosulnak bizonyos adatok az adatbázisban, ami kihat a következő oldalak viselkedésére, és ha megnyomjuk az F5-öt – a hívás megismétlődik, ami megsérti az adatok konzisztenciáját. Ráadásul ez úgy sérti meg, hogy csak néhány lépés után, a sorozat 3. oldalán jelentkezik. Nem állok ellen, hogy egy ilyen "művész-ninja" legyen a csapatban és a kódjával fenntartja a kollégák figyelmét. De így, a legdrágább rendszer könyvtárában!
Ez pénteken történt. A szombatot és vasárnapot kollégámmal az irodában töltöttük azzal a céllal, hogy tisztázzuk, milyen feladatokat állít a vállalkozás a rendszer elé ma, és milyen feladatokat találhatunk ki egy év múlva. Ennek megfelelően, hogyan oldanánk meg ezeket, ha nem lennénk a legdrágább és legbosszantóbb rendszer keretei közé szorítva.
Megmondtuk – megcsináltuk. Készítettünk egy pilotot, amelyben megteremtettük az új Sportmaster weboldal fejlesztésének alapját. Ezek közül sok ötlet megmaradt, és most aktívan forognak az oldalon.
A pilot szakaszai és időkeretek
2 nap. Készítettünk egy mikroprototípust – a hétvégén átállítjuk az adatbázisunkat ElasticSearch-ra, és facettás keresést indítunk. Voila! Abban a vásárolt rendszerben ez a beállítás 2 hétig tartott. Itt mindez gyakorlatilag pár óra alatt megvalósult! Ráadásul gyorsabban is működik. Ez pedig többszörösen gyorsabb.
2 hét. "Felezünk" prototípust, hozzáadunk funkcionalitást az ésszerű személyre szabott megjelenítéshez.
Például, ha a felhasználónak több kedvezménye és akciója van, ami éppen rá vonatkozik – akkor a termékek keresési eredményeiben pontosan azt az árat kell megjeleníteni, amelyet a lehető legkedvezőbb módon, az összes elérhető kedvezménnyel alkalmazva kaphat.
A kedvezményekkel nem olyan egyszerű a helyzet. Például vettem egy sílécet, és most a sapkára 40%-os kedvezmény van, de a teljes rendelésre vonatkozó 10%-os welcome kedvezmény érvényét veszti. Igen, ez egy valódi eset 🙂 És hogy egy ilyen akciót beállítsunk a vásárlási rendszerben, három konzultációs díjat fizettünk a beszállítónak, aminek eredményeként sok példát kaptunk más kedvezmények létrehozására. Nagyon diplomatikus, és figyelembe véve a konzultációk költségeit — gazdaságilag nagyon jól jártunk.
Részletes bemutatót mutattunk be az üzletnek. Megígérték, hogy gyorsan összerakják a pilotot, és azonnal munkához láttak.
2 hónap. A pilot projekt — élő weboldalként készítjük el, katalógus kereséssel. A keresés facettekre van bontva, a keresési eredmények — személyre szabott kedvezményekkel, a pilot majdnem úgy néz ki, mint a Sportmaster weboldala, és ugyanazokat a termékeket töltöttük fel. Édes !
Hozzáadjuk főnökünk «Красноречие:100» prezentációját, és a bemutató az üzletnek sikeresen lezajlik! Szabad kezet kapunk az eCommerce-platform kifejlesztésére.
Ez azt jelenti, srácok, hogy megtartjátok a csapatot, srácok, megtartjátok a költségvetést. Klassz, ugye?
2 év. A weboldal élesbe állítása. Igen, hosszú idő volt. Amit akkor tudtunk, azt csak prototípus méretében próbáltuk ki. Két ember könnyen képezhet jól működő csapatot. A feladatok, amelyeket „pipálva” végeztünk — lényegében apróbb tökéletesítések voltak a „Hello World” új technológiákban. Könnyen generáltunk új hipotéziseket, gyorsan teszteltük őket, nem ragaszkodtunk hozzájuk, és ezért sajnálkozás nélkül „megöltük” őket. Amikor már 10-en voltunk, az inerciánk folytán extrapoláltuk a munkánk sebességét a többiekre. És olyan határidőket ígértünk, amelyek a csodálatos elképzeléseinket szorozták meg az entuziazmusunkkal.
Ismerős helyzet? 🙂
Akkor már tudjátok, mi fog történni tovább?
Csalóda №1. „Szuper-extrapolátor”
Nyilvánvaló, hogy az új technológiák nagyon jól néznek ki a prezentációkban, és remekül teljesítenek a „Hello World” alkalmazási szintjén. De a valóság általában kissé messzebb van ettől.
Szóval. Fogtuk a könyvtárat, és rengeteg alkalmazásra szánt kódot írtunk. Az egységteszteket tehernek érezzük (mi ugye menők vagyunk, és szuperszónikus sebességgel dolgozunk, a kód modern és egyéb). Folyamatosan módosítjuk és csiszoljuk az API-t menet közben — hát, itt komolyan nem lehetnek tesztek. És mindezt a „szuper-optimalizáltuk a fejlesztési folyamatot” zászlaja alatt (igen, most ezt még leírni is félelmetes).
Aztán minden meglehetősen nyilvánvaló.
Új verziót vezetünk be a uat-ra. Az üzlet emberei élénken indulnak, hogy teszteljék az egészet és gombokat nyomogassanak. Néha meglehetősen kreatívan nyomogatnak – valami kiesik. Itthon lenne a helye, hogy megtudjuk, mit tettek ezért. De a monitor másik oldalán nem egy megszállott tesztelő áll, aki elmondja neked a környezet összes jellemzőjét a régió időjárásának figyelembevételével, hanem az üzleti megrendelő. Neki csak annyit mond, hogy „nem működik”. Ez pedig azt jelenti, hogy elégedetlen. Kérdezd meg őt, és ő ijedt elégedetlen!
Ahhoz, hogy reprodukálni tudjuk a hibát, menni kell és mindenhol próbálkozni. Természetesen egyetlen panaszt sem hagytunk figyelmen kívül, és mindent kijavítottunk. Elhagytuk a tervezett feladatokat, de „tüzet oltottunk”.
Így kiásottuk magunknak a következő gödröt.
Csapda №2. „Szakember”
Megérkezett hozzád egy nem éppen kellemes hiba. Elkezded kideríteni. Nem sikerül – düh – újabb próbálkozás – megint kudarc – mindent pontosítasz, amit csak lehet – ismét nem az – gondolsz arra, hogy már régi vagy, és mindenkinek gyereke és jelzáloga van – újra próbálkozol – megint nem sikerül. Néhány csésze kávé után, és minden megismétlődik. 12-14 óra folyamatos munka – szinte már normának számít. És amikor már minden a határra megy – bum, rávilágítás!
Lehetséges, hogy kívülről a nap hatékonyságának értékelése jól és helyesen látszik. De belül – ez változó lehet.
Az én esetemben az ilyen munkáról alkotott benyomás tartalmazta: „Jó vagyok, menő vagyok, megoldottam”. Nem mindig tudatosan, de tudattalanul – mindig!
És ennek hatása alá kerülsz, nem viccelek. Kiderül, hogy a sikeresség belső metrikái az eredményről az erőfeszítések számának és azon teljesítmények szintjére tolódnak, amelyeket véghez vittél, hogy mennyire szenvedtél, miközben próbáltad megoldani a feladatot.
Valószínűleg ez a legrosszabb csapda.
Tovább könnyebb és szórakoztatóbb lesz 🙂
Csapda №3. „A Hello world ereje”
A technológiai stackünk abban az időszakban: ElasticSearch, Hazelcast, Pentaho, freemarker (és ellenőrzött Java, Spring, Tomcat, nginx). A Freemarker nem túl informatívan adta meg a hibajelentéseket. Viszont az ElasticSearch, Hazelcast, Pentaho többször is javításra szorult – tehetségesen találtuk meg azokat az eseteket, amelyekben nem úgy működtek, ahogy a dokumentáció előírta.
A könnyű indulás és az új technológia használatával elérhető gyors eredmények jó dolog, de ez eufóriát kelt és csökkenti az éberséget. Mert az új technológia hibákat tartalmaz, mindenképpen tartalmaz hibákat. És ha még nem írtak róluk — örülj, mert neked kell az elsőként találkoznod olyan hibákkal, amelyeket feltétlenül meg fogsz találni és guglizni vagy a SO-n keresgélni fogsz. Természetesen a "hibás" dolgokat megbízható termékekben is megtalálhatod, de az újakban ez sokkal egyszerűbb.
Malgrája a nehézségeket, sikerült bevezetnünk a termelésbe. Igen, akadozásokkal. Igen, nem túl stabilan. De összességében — katasztrófák nélkül.
Azt mondhatom, hogy ismét kiemelem azokat a csapdákat, amelyek torzítják a munka folyamatának egészséges észlelését.
- "Extrém extrapolátor". A jelenlegi sikerek hatására boldogan extrapoláljuk a fejlesztési sebességet a közelgő projektekre.
- "Sztakhanovista". Kihajtjuk magunkból a maximumot, elégedettek vagyunk, de észre sem vesszük, hogy az általunk megoldott problémák a mi személyes hibáink/lemaradások/elhanyagolások következményei. Munkák, amelyeket nem végeztek el.
- "Hello world ereje". Sietünk, hogy az összes legújabb és legérdekesebb dolgot bevezethessük a termelésbe.
Miért sikerült mindez
Természetesen nem soroltam fel az összes hibát, amelyet ez idő alatt elkövettünk, de a leggyakoribbakat, amelyek bármelyik projekt esetén valószínűek lehetnek. Az ilyen hibák rögzítése segít elkerülni őket a jövőben.
Egy kicsit arról, hogyan sikerült létrehoznunk egy ilyen mini-startupot a cégen belül és meggyőznünk a vállalatot, hogy a már megvásárolt rendszerről átálljon egy saját, nem saját kezűleg írt megoldásra.
0. számú feltétel. Egészséges klíma a cégnél. Ez nem csak a munkavállalók "lángoló szemei" és a stresszes környezetben való kommunikációs készségekről szól, hanem minden interakcióról.
1. számú feltétel. Higgy abban, amit csinálsz. Komolyan, nem hiszem, hogy lett volna bármilyen esélyünk, ha csak a pilóta projektekkel foglalkozunk, anélkül, hogy a megvásárolt rendszert "a legapróbb részletekig" megértettük volna — vagyis megállva tudva, hogy ez a rendszer jobb és legyőz minket.
Amit tettünk: 1) megértettük a megvásárolt rendszert, és ennek segítségével megoldottuk az üzleti igényeket 2) összeállítottuk a feladatok listáját, amelyek most nemcsak a jelenben, hanem a közeljövőben is létezni fognak 3) kiválasztottuk a legjobban megfelelő megoldást. És akkor, a megoldásunk értékelése — szakértők értékelése volt.
Adnának nekünk valamit, ha csak úgy jönnénk, és azt mondanánk: "srácok, minden hülyeség, nem akarunk ezzel foglalkozni, és úgy döntöttünk, hogy az elejétől kezdjük?" Valószínűleg nem. Ráadásul olyan formában kapnánk választ, amit jól megjegyzünk 🙂
2. feltétel. Az első lépést kicsiben tesszük. Generálunk egy első hipotézist és ellenőrizzük. Ezt akár a saját időnkből is elkölthetjük. Ha nem akarod az idődet pazarolni — akkor valószínűleg nem is érdemes belefogni. Ha pedig nem akarsz egy kis hipotézist ellenőrizni, hanem rögtön valami nagyszerűt és fényeset akarsz csinálni — tartsák távol magukat az ilyen emberektől!
Szerencsénk volt, és az első hipotézisünk működött. De ez nem mindig van így. Például egy következő projektben, amikor az adminisztrációt népszerűsítettük egy hasonló pilot keretein belül, csak a 18. verzió működött. Az első 17 megközelítés pocsék volt. Egyébként az adminisztráció létrehozásának történetében a cselekményfordulatok a brazil sorozatok szintjén voltak, mert a csapat tagjai akkor már veteránok voltak, igazi "törzskönyv szerinti" szakemberek.
3. feltétel. Készítünk egy MVP-t és keressük a fájdalmakat a döntéshozó arcán. Persze, már az is röntgentartalmú rémületet tükrözhet az arcán, hogy harmincadszor hozol neki valami ötletet. De mindenesetre. És mindenképpen meg kell mutatnunk, hogyan oldjuk meg a problémáit a termékünkkel.
4. feltétel. Gyorsan készítünk egy pilótát, ami úgy néz ki, kb. mint a végtermék. Minden nagyon jól megcsinálni — csábító, de beleütközhetünk a perfekcionizmusba, amely miatt ahelyett, hogy egy pilótát akarnál bemutatni, már egy tökéletes termék pilóta verzióját akarod. Pedig ilyen nem létezik. Szóval, csak készíts valamit, akár botokból is.
5. feltétel. A termék. A projekt nő, pénzügyek érkeznek, tapasztalt szakemberek érkeznek.
Ha klasszikus startup vállalkozó vagy, ez az a pillanat, amikor gyorsan le kell lépned. Mert a könnyű repkedés a legmagasabb szinteken és a folyamat általános kedvességének érzése gyorsan eloszlik.
A piacra lépés — az igazi terhelésekkel való szembesülés, integráció tucatnyi rendszerrel, és amikor új funkciót hozol létre, egyidejűleg, a támogatás keretében, a régi verziókat is javítod. Mindez sokkal komolyabb kihívások, mint egy ötlet kitalálása és egyetlen ügyfélprobléma megoldása.
Ezek a kihívások, és a készségek fejlődése pontosan ezen a szakaszon történik.
Köszönjük, hogy elolvasta. Boldog új kódot!
Forrás: habr.com
