Ciao! Mi chiamo Alexey Pyankov e sono il programmatore principale dell'azienda Sportmaster. Dico subito che 'principale' non significa 'il più importante tra tutti i programmatori', no, è solo un titolo, una traduzione affascinante per 'Senior+'.
Lavoro in Sportmaster dal 2012 e, nel corso degli anni, il team di sviluppo ha realizzato molte soluzioni interessanti dal punto di vista tecnico. Oggi, però, vorrei raccontare del nostro lavoro con più attenzione su come abbiamo ragionato in situazioni ambigue.
In questo articolo non troverai soluzioni tecniche specifiche (e nemmeno qualcosa di tecnico) da prendere e applicare nel tuo progetto. Piuttosto, sarà una riflessione sul lavoro svolto. Ci sono stati momenti speciali che ci hanno influenzato come team: ci hanno uniti, temprati e messi alla prova. Di questi momenti, dell'atmosfera lavorativa nel team, dei nostri errori e di alcune trappole psicologiche in cui a volte ci cadiamo, cercherò di parlare oggi.
E comincerò proprio dal 2012.
Sono arrivato nel 2012 con l'obiettivo principale di lavorare sul nostro sito di punta. All'epoca era un "mostro di Frankenstein": una parte del team lavorava con il nostro vecchio sistema, che faceva fatica a gestire i carichi (Bitrix), mentre un'altra parte del team (incluso me) cercava di implementare un nuovo sistema, scelto con il criterio "Se è il più costoso e-commerce al mondo, lo prendiamo". Ebbene, "cercavamo di implementare" — perché il sistema resisteva strenuamente, e ogni volta che riuscivamo a risolvere un problema, ne emergeva inevitabilmente un altro "sorpresa". Lavoravamo molto, ma avanzavamo alla velocità di una tartaruga.
Per me, l'ultima goccia è stata scoprire il codice di un metodo in questo "e-commerce più costoso al mondo", quando diverse ore di lavoro concentrato su un bug complesso hanno rivelato che la causa si trovava in un custom-tag, che viene eseguito durante la generazione dell'html in jsp. Lo scopo di questo custom-tag è visualizzare la somma di alcune grandezze. Questo è positivo, perché a questo serve il custom-tag. Ma la sorpresa è emersa dal fatto che, nel farlo, alcuni dati nel database venivano modificati, il che influenzava il comportamento delle pagine successive; e se si premeva F5, la chiamata si ripeteva, compromettendo la coerenza dei dati. Inoltre, il problema si manifestava solo dopo alcuni passaggi, alla terza pagina della sequenza. No, non sono contrario a che un simile "master-ninja" faccia parte del team e mantenga alta l'attenzione dei colleghi. Ma non in questo modo, in una libreria del sistema più costoso!
Era venerdì. Sabato e domenica io e un collega li abbiamo trascorsi in ufficio per capire quali compiti il business ci pone davanti oggi e quali potrebbero presentarsi fra un anno. Di conseguenza, come potremmo affrontarli, se non fossimo costretti a usare questo sistema costoso e frustrante.
Detto-fatto. Abbiamo realizzato un pilota, nel quale abbiamo posto le basi per lo sviluppo del nuovo sito di Sportmaster. Molte di queste idee sono state accolte e ora il loro proseguimento è attivo sul sito.
Fasi del pilota e tempistiche
2 giorni. Abbiamo creato un micro-prototipo: nel fine settimana trasferiamo il nostro database in ElasticSearch e realizziamo una ricerca per faccette. Voilà! Nella stessa costosa piattaforma, questa configurazione richiedeva 2 settimane. Qui, però, è stata completata in poche ore! E funziona anche più velocemente. Anzi, è più veloce di un ordine di grandezza.
2 settimane. Stiamo sviluppando il prototipo, aggiungendo funzionalità per una presentazione personalizzata adeguata.
Ad esempio, un utente ha diverse sconti e promozioni a lui dedicate — in questo caso, nei risultati di ricerca per i prodotti deve essere visualizzato esattamente il prezzo che si può ottenere applicando tutti i vantaggi disponibili nel modo più vantaggioso.
Con le promozioni non è così semplice. Ad esempio, ho acquistato degli sci, ora c'è uno sconto del 40% sul berretto, ma così facendo si annulla lo sconto di benvenuto del 10% su tutto l'ordine. Sì, è un caso reale 🙂 E per impostare una tale promozione nel sistema d'acquisto, sono state pagate 3 consulenze con il fornitore, grazie alle quali abbiamo ricevuto molti esempi su come realizzare diverse altre promozioni. Molto diplomatico e, considerando il costo delle consulenze, economicamente molto vantaggioso.
Abbiamo mostrato un demo dettagliata all'azienda. Abbiamo promesso di allestire rapidamente un pilota e siamo subito passati all'azione.
2 mesi. Il progetto pilota — lo realizziamo sotto forma di un sito web live con ricerca nel catalogo. Ricerca con faccette, risultati di ricerca — con sconti personalizzati, il pilota sembra quasi un sito di Sportmaster, e abbiamo caricato gli stessi prodotti. Fantastico!
Aggiungiamo «Krasnorechie:100» del nostro capo reparto, e la presentazione all'azienda va a gonfie vele! Ci danno carta bianca per sviluppare noi stessi la piattaforma eCommerce.
E questo significa, tenete duro, ragazzi, tenete duro, ragazzi, il budget. È fantastico, giusto!
2 anni. Rilascio del sito in produzione. Sì, è stato lungo. Tutto ciò che sapevamo fare all'epoca l'abbiamo provato solo in scala prototipale. Due persone formano facilmente una squadra affiatata. E anche le attività che 'spuntavamo' erano, per lo più, piccole rifiniture di 'Hello World' con nuove tecnologie. Generavamo facilmente nuove ipotesi, le testavamo rapidamente, non riuscivamo ad affezionarci e quindi le 'uccidevamo' senza rimpianti. Quando siamo diventati 10, per inerzia abbiamo estrapolato la nostra velocità di lavoro su tutti gli altri. E abbiamo promesso scadenze eque, pari alla nostra idea di bellezza moltiplicata per il nostro entusiasmo.
Situazione familiare? 🙂
Allora, sai già cosa succederà dopo?
Trappola n. 1. «L'extrapolatore straordinario»
È chiaro che le nuove tecnologie sembrano fantastiche nelle presentazioni e si comportano alla grande nelle applicazioni di tipo «Hello World». Ma la realtà di solito è un po' diversa da questo.
Ecco come funziona. Prendiamo la libreria, scriviamo una marea di codice applicativo. I test unitari li consideriamo un peso (siamo fighi e lavoriamo a supervelocità, il codice è moderno e così via). Cambiamo e perfezioniamo costantemente l'API al volo — seriamente, chi ha bisogno di test? E tutto questo sotto la bandiera "abbiamo ottimizzato il processo di sviluppo" (sì, adesso è persino spaventoso descriverlo).
E poi tutto è piuttosto ovvio.
Distribuiamo una nuova build su UAT. I ragazzi del business si affrettano a testare e premere i pulsanti. A volte premono in modo piuttosto creativo — qualcosa si rompe. Qui sarebbe il caso di andare a scoprire cosa è stato fatto. Ma dall'altra parte dello schermo non c'è un tester scrupoloso, pronto a darti tutte le caratteristiche dell'ambiente tenendo conto delle condizioni climatiche della regione, bensì il committente del business. Per lui, semplicemente "non funziona". E questo significa che è insoddisfatto. Se lo chiedi, lui dirà che è molto insoddisfatto!
Allora, per riprodurre il bug, bisogna andare e provare a toccare tutto a caso. Certo, non abbiamo trascurato nessuna lamentela e abbiamo sistemato tutto. Abbiamo abbandonato le attività programmate, ma "abbiamo spento il fuoco".
Così abbiamo scavato un'altra buca.
Trappola n. 2. "Stakhanovista"
Un bug poco piacevole è arrivato. Cominci a indagare. Non funziona — rabbia — provi di nuovo a risolverlo — ennesima delusione — chiedi tutto ciò che puoi — di nuovo non è giusto — pensi che ormai sei vecchio e tutti hanno figli e mutui — riprovi — di nuovo non è giusto. Dopo alcune tazze di caffè, tutto si ripete. 12-14 ore di lavoro di fila — quasi normale. E quando ormai tutti sono al limite — ecco, un'illuminazione!
Forse, dall'esterno, la valutazione dell'efficacia di una giornata del genere è chiara e corretta. Ma da dentro — può essere diverso.
Nel mio caso, la sensazione di questo lavoro includeva "Sono fantastico, sono forte, ce l'ho fatta". Non sempre consapevolmente, ma inconsapevolmente — sempre!
E ci si abitua, senza scherzi. Di conseguenza, le metriche interne di successo si spostano dal risultato al numero di sforzi compiuti e al livello di prodezze che hai realizzato, quanto hai sofferto nel tentativo di risolvere il problema.
Probabilmente, questa è la trappola più terribile.
Dopo sarà più facile e divertente 🙂
Trappola n. 3. «Il potere di Hello world»
Il nostro stack tecnologico di quel periodo: ElasticSearch, Hazelcast, Pentaho, freemarker (e provate Java, Spring, Tomcat, nginx). Freemarker forniva messaggi di errore non molto informativi. Tuttavia, abbiamo dovuto applicare patch a ElasticSearch, Hazelcast e Pentaho diverse volte — trovavamo abilmente casi in cui non funzionavano come specificato nella documentazione.
Un avvio facile e rapidi vantaggi dall'uso di una nuova tecnologia vanno bene, ma introducono euforia e abbassano la guardia. Perché una nuova tecnologia contiene bug, li contiene sempre. E se non sono stati ancora scritti — godi, tocca a te diventare il pioniere che sicuramente troverà qualcosa di storto e andrà a cercare su Google o su SO. Certo, 'storto' può essere trovato anche in prodotti collaudati, ma nei nuovi è molto più semplice.
Nonostante tutte le difficoltà, siamo arrivati in produzione. Sì, con dei lag. Sì, non molto stabile. Ma in generale — senza catastrofi.
Quindi ribadisco ancora una volta le trappole in cui viene distorta una sana percezione del processo di lavoro.
- «Estraibilitá sorprendente». Impressionati dai successi attuali, andiamo avanti ed estendiamo con gioia la velocità di sviluppo ai progetti futuri.
- «Sostituto». Lavoriamo fino all'esaurimento, soddisfatti di noi stessi, ma non ci accorgiamo che i problemi che risolviamo sono conseguenze dei nostri errori personali / delle nostre mancanze / delle nostre negligenze. Lavori da non fare.
- «Il potere di Hello World». Ci affrettiamo a implementare in produzione tutto ciò che è nuovo e interessante.
Perché è andato tutto bene
Certo, non ho elencato tutti gli errori che abbiamo commesso nel tempo, ma solo i più comuni, probabili per progetti di qualsiasi specificità. Tale registrazione degli errori aiuta a evitarli in futuro.
Un po' su come siamo riusciti a creare una mini-startup all'interno dell'azienda e convincere il business a passare da un sistema già acquistato a qualcosa di personalizzato.
Condizione n. 0. Un clima sano in azienda. Non si tratta solo di avere «occhi brillanti» nei dipendenti e di comunicabilità in condizioni di stress nella raccolta di biscotti, no. Riguarda tutte le interazioni.
Condizione n. 1. Credere in ciò che si fa. Seriamente, non penso che avremmo avuto alcuna possibilità se avessimo fatto un pilota senza smontare il sistema acquistato «fino all'ultima vite» — cioè, ritirandoci e sapendo in modo subconscio che quel sistema è migliore e ci batterà.
Cosa abbiamo fatto: 1) abbiamo esaminato il sistema di acquisto, utilizzandolo per risolvere le principali richieste del business 2) abbiamo redatto un elenco di compiti che non solo esistono ora, ma ci saranno anche nel prossimo futuro 3) abbiamo trovato la soluzione più adatta. E quindi, la nostra valutazione della soluzione è stata una valutazione degli esperti.
Ci darebbero qualcosa se ci presentassimo e dicessimo, 'ragazzi, tutto fa schifo, non vogliamo occuparci di questo e abbiamo deciso di fare tutto da zero'? Probabilmente no. E la risposta sarebbe stata formulata in modo tale da rimanere ben impressa 🙂
Condizione n. 2. Iniziamo con un piccolo passo. Generiamo la prima idea e verifichiamola. È possibile dedicare a questo anche il proprio tempo personale. Se non si vuole spendere tempo personale, allora non vale nemmeno la pena di impegnarsi in una questione del genere. E se non si vuole verificare una piccola ipotesi, ma si preferisce fare qualcosa di fantastico fin da subito — state lontani da queste persone!
Siamo stati fortunati, e la prima ipotesi ha funzionato. Ma non è sempre così. Ad esempio, in uno dei progetti successivi, quando abbiamo promosso l'interfaccia di amministrazione all'interno di un pilota simile, solo il diciottesimo tentativo ha dato risultati. I primi diciassette approcci sono stati vani. A proposito, nella storia della creazione dell'interfaccia di amministrazione, le svolte della trama erano da telenovela brasiliana, perché la squadra era formata da ragazzi già esperti, dei veri "veterani".
Condizione n. 3. Creiamo un MVP e cerchiamo le difficoltà dell'interlocutore decisionale. Certo, il suo volto potrebbe già riflettere orrore al solo pensiero che stai per proporgli un'idea per la trentesima volta. Ma lo facciamo comunque. E mostriamo sempre come risolviamo i suoi problemi con il nostro prodotto.
Condizione n. 4. Creiamo rapidamente un pilota che sembra circa il risultato finale. È allettante fare tutto in modo perfetto, ma si può cadere nel perfezionismo, il che significa che invece di un pilota si desidera mostrare una versione pilota di un prodotto già ideale. Ma non esistono prodotti così. Quindi, fai almeno qualcosa di semplice.
Condizione n. 5. Prodotto. Il progetto cresce, ottiene finanziamenti e arrivano specialisti con esperienza solida.
E se sei un classico imprenditore, questo è il momento in cui devi andare via con decisione. Perché il volo leggero tra le nuvole e la sensazione generale di benessere si dissipano rapidamente.
Il passaggio alla produzione è un confronto con carichi reali, integrazione con decine di sistemi, e quando crei nuove funzionalità, allo stesso tempo, nel contesto del supporto, sviluppi anche le versioni precedenti. Tutto ciò rappresenta sfide molto più serie rispetto all'ideare un'idea e risolvere magari bene, ma solo un problema del cliente.
Queste sono sfide, e la crescita delle competenze avviene proprio in questa fase.
Grazie per aver letto. Happy New Code!
Fonte: habr.com
