Здравейте! Казвам се Алексей Пьянов, главен програмист в компанията Спортмастер. Ще кажа веднага, че "главен" не означава "най-важният от всички програмисти", не, това е само наименование, един очарователен превод за "Senior+".
В компанията Спортмастер работя от 2012 година и през това време нашият екип за разработка е създал много решения, интересни от техническа гледна точка. Но днес бих искал да говоря за нашата работа с акцент предимно върху начина, по който разсъждавахме в определени нееднозначни ситуации.
В тази статия няма да има конкретни технически решения (да не говорим вообще за нещо техническо), които да се хващат и прилагат в проектите ви. По-скоро — това е рефлексия върху извършената работа. Имаше особени моменти, които ни повлияха като екип — сплоти ни, закали ни и ни подложи на изпитание. За тези моменти, за атмосферата на работа в екипа, за нашите подхлъзвания и редица психологически капани, в които понякога сами се улавяме, ще се опитам да разкажа днес.
И ще започна точно от 2012 година.
Постъпих през 2012 с основна цел за онова време — работа върху нашия флагмански сайт. Тогава това беше "монстър Франкенщайн": част от екипа работеше с нашата стара система, която не справяше добре с натоварванията (Bitrix), а в другата част на екипа (където бях и аз) се опитвахме да внедрим нова система, която бяхме избрали по критерия "Ако е най-скъпата e-commerce в света, вземаме я". Именно "опитвахме се да внедрим" — защото системата яростно се съпротивляваше, и за всеки момент, с който успявахме да се справим, задължително възникваше "сюрприз" в отговор. Работехме много, но напредвахме със скоростта на охлюв.
Лично за мен последната капка беше запознанството с кода на един метод в тази „най-скъпа e-commerce система в света“, когато няколко часа концентрирана работа над заплетен бъг доведоха до това, че причината беше открита някъде в custom-tag, който се задействува при генериране на HTML в JSP. Задачата на този custom-tag е да покаже сумата на някакви величини. Това не е лошо, за това е предназначен custom-tag. Но неочакваността се криеше в това, че при това се променят някои данни в базата, на които е привързано поведението на следващите страници, и ако натиснете F5 — повикването се повтаря, което нарушава консистентността на данните. И то нарушава по такъв начин, че се проявяваше само след няколко стъпки, на третата страница от последователността. Не, нямам нищо против такъв „мастър-нинджа“ да бъде в екипа и с кода си да поддържа вниманието на колегите в тонус. Но не така, в библиотеката на най-скъпата система!
Това беше в петък. А събота и неделя прекарахме с колегата в офиса с цел да разберем какви задачи бизнесът поставя пред системата точно днес и какви задачи може да измисли след година. Съответно, как бихме ги решавали, ако не бяхме затворени в ограниченията на тази най-скъпа и най-раздразнителна система.
Казано — направено. Направихме пилотен проект, в който бихме заложили основите за разработване на новия сайт на Спортмастер. Много от тези идеи намериха приложение и в момента активно се работи по тях на сайта.
Етапи на пилота и времеви рамки
2 дни. Направихме микропрототип — през уикенда прехвърляме нашата база в ElasticSearch, правим фасетно търсене. Вуа-ля! В онова купено решение такава настройка „отне“ 2 седмици. А тук — буквално за няколко часа! И работи по-бързо. Всъщност, по-бързо с порядък.
2 седмици. „Режем“ прототип, добавяме функционалности за адекватно персонализирано извеждане.
Например, ако потребителят има няколко отстъпки и промоции, които са актуални именно за него — тогава в резултатите от търсенето на продукти трябва да се покаже именно онази цена, която може да се получи, използвайки всички налични предимства по най-изгодния начин.
С акциите не е толкова просто. Например, купих ски, сега на шапка има 40% отстъпка, но в същото време се отменя welcome-отстъпката от 10% за цялата поръчка. Да-да, това е реален случай 🙂 И за да настроим такава акция в покупната система, бяха платени 3 консултации с доставчика, в резултат на които получихме много примери как да направим различни други акции. Много дипломатично и, като се вземе предвид цената на консултациите — икономически много добре.
Показахме подробна демонстрация на бизнеса. Обещаха бързо да съберат пилот и веднага започнаха с работата.
2 месеца. Пилотният проект — правим го под формата на жив сайт с търсене по каталога. Търсенето с фасети, резултатите от търсенето — с персонализирани отстъпки, пилотът изглежда почти като сайт Спортмастера, а и стоките са същите. Супер!
Добавяме „Красноречие:100“ на нашия шеф и презентацията за бизнеса минава на Ура! Получаваме карт-бланш да разработим eCommerce платформа сами.
А това означава, гледайте, момчета, екипа, гледайте, момчета, бюджета. Яко, нали!
2 години. Извеждане на сайта в продукция. Да, дълго. Всичко, което умяхме тогава, пробвахме само в мащаба на прототипа. Двама души лесно образуват слажен екип. А задачите, които „отключвахме“ — по същество бяха малки допълнения „Hello World“ в нови технологии. Лесно генерирахме нови хипотези, бързо бяхме готови да ги проверим, не успявахме да се привържем и затова без съжаление ги „убивахме“. Като станахме 10 души, по инерция екстраполирахме нашата скорост на работа на всички останали. И обещахме срокове за изпълнение на задачи, които равняват представата за прекрасното, умножена по нашия ентусиазъм.
Звучи познато? 🙂
Така че, вече знаете какво ще стане след това?
Капан №1. „Екстраполатор-крут“
Ясно е, че новите технологии изглеждат много добре в презентации и отлично се представят в приложения от типа „Hello World“. Но реалността обикновено е малко по-далеч от това.
Така че. Взимаме библиотеката, пишем куп приложение код. Юнит тестовете ги считаме за бреме (все пак ние сме крут и работим на свръхзвука тук, кодът е съвременен и т.н.). Непрекъснато променяме и доработваме API в движение — какви тестове, сериозно. И всичко това под знамето „круто оптимизирахме процеса на разработка“ (да, сега дори е страшно да се описва).
А след това всичко е доста очевидно.
Изпускаме нов билд на uat. Ребята от бизнеса с ентусиазъм започват да тестват всичко и да натискат бутони. Понякога натискат доста творчески — нещо пада. Тук би трябвало да отидем и да разберем какво е направено. Но от другата страна на монитора не е опитен тестер, който ще ти изкара всички характеристики на средата с оглед на времето в региона, а бизнес клиент. Той просто казва: „не работи“. А това означава, че е недоволен. Попитай го — и той ще бъде ужасен недоволен!
Следователно, за да възпроизведеш бъг, трябва да отидеш и да твърдиш чрез проба и грешка. Разбира се, не сме пренебрегнали нито една оплакване и сме поправяли всичко. Изоставихме планираните задачи, но „гасихме пожара“.
Така изкопахме следващата ямка.
Капан №2. „Стахановец“
Появява се неприятен бъг. Започваш да разбираш. Не се получава — гняв — опитваш се да разбереш отново — нов провал — уточняваш всичко, което може — пак не е това — мислиш за това, че вече си стар и всички имат деца и ипотека — опитваш отново — отново не е това. Няколко чаши кафе и всичко се повтаря. 12-14 часа работа на ред — почти като норма. И ето, когато всичко е на ръба — бац, прозрение!
Може би, отстрани, оценката за ефективността на такъв ден изглежда добре и правилно. Но от вътре — може да бъде различно.
В моя случай впечатлението от такова работене включваше „Аз съм страхотен, справих се“. Не винаги съзнателно, но подсъзнателно — винаги!
И на това се пристрастяваш, без шеги. Оказва се, че вътрешните метрики за успех се преместиха от резултата на количеството положени усилия и нивото на подвизите, които си извършил, колко много си страдал, опитвайки се да решиш задачата.
Вероятно, това е най-ужасният капан.
По-нататък ще бъде по-лесно и забавно 🙂
Капан №3. „Силата на Hello world“
Нашият стек технологии от този период: ElasticSearch, Hazelcast, Pentaho, freemarker (и проверените Java, Spring, Tomcat, nginx). Freemarker не даваше много информативни съобщения за грешки. А ElasticSearch, Hazelcast, Pentaho се налагаше да ги патчим няколко пъти — умело намирахме случаи, в които те не работеха както е зададено в документацията.
Лесен старт и бързи предимства от новата технология - това е добре, но те въвеждат в еуфория и намаляват бдителността. Защото новата технология съдържа бъгове, задължително съдържа бъгове. И ако още не са написани за тях - радвай се, именно ти ще станеш този пионер, който ще намери нещо невярно и ще отиде да търси в Google или в Stack Overflow. Разбира се, "невярното" може да се намери в доказани продукти, но в новите - това е много по-лесно.
Несмотря на всички сложности, ние успяхме да излезем в продукция. Да, с забавяния. Да, не е много стабилно. Но като цяло - без катастрофи.
И отново ще подчертая капаните, в които се изкривява здравословното възприятие на работния процес.
- "Екстраполатор-крутыш". Под впечатление от текущите успехи, ние радостно екстраполиране скоростта на разработването на предстоящите проекти.
- "Стахановец". Работим на износ, доволни сме от себе си, но не забелязваме, че проблемите, които решаваме - са следствия от нашите собствени грешки / пропуски / пренебрежения. Работи, които не трябва да бъдат извършени.
- "Силата на Hello world". Бързаме да внедрим в продукцията всичко ново и интересно.
Защо всичко стана
Разбира се, изброих не всички грешки, които имахме за това време, но най-общите, вероятни за всеки проект от всякакъв вид. Такава фиксация на грешките помага да се избегнат в бъдеще.
Няколко думи за това как успяхме да създадем такъв мини-стартап в компанията и да убедим бизнеса да се откаже от вече закупената система в полза на нещо самоописано.
Условие №0. Здравословен климат в компанията. Това не е само "горящите очи" на служителите и комуникацията в стресови условия на печене на бисквитки, не. Става дума за всички взаимодействия.
Условие №1. Да вярваш в това, което правиш. Сериозно, не мисля, че бихме имали някакъв шанс, ако се захванем с пилота, без да сме проучили покупната система "до болтика" - тоест, отстъпвайки и подсъзнателно знаейки, че тази система е по-добра и ще ни надмине.
Какво направихме: 1) разгледахме покупната система, с нея решихме основните заявки от бизнеса 2) съставихме списък с задачи, които не само съществуват в момента, но и ще бъдат актуални в обозримо бъдеще 3) подбрахме решение, което е най-подходящо. И след това, нашата оценка на решението беше оценка на експерти.
Бихте ли ни дали нещо, ако просто дойдохме и казахме, моля, "хора, всичко е глупост, не искаме да се занимаваме с това и решихме да започнем от нулата"? Вряд ли. Освен това, отговорът вероятно щеше да бъде изразен по такъв начин, че да остане добре запомнен 🙂
Условие №2. Първата стъпка направете малка. Генерирайте първата хипотеза и я проверете. Можете да отделите за това и своето лично време. Ако не искате да губите времето си, по-добре изобщо не се захващайте с такова дело. А ако не искате да проверите малка хипотеза, а искате веднага да направите нещо страхотно и блестящо, дръжте се далеч от такива хора!
Случи ни се късмет и първата ни хипотеза сработи. Но това не се случва винаги. Например, в един от следващите проекти, когато промотирахме админ панела в рамките на подобен пилот, нашата 18-та версия сработи. Първите 17 подхода бяха напразни. Между другото, в историята със създаването на админ панела сюжетните обрати бяха на нивото на бразилските сериали, защото екипът беше съставен от момчета, които вече бяха ветерани, истински "опитни съкровища".
Условие №3. Правим MVP и търсим проблемите на лицето, взимащо решения. Разбира се, на лицето му може да се отразява ужас само от факта, че в тридесетия път му представяте някаква идея. Но все пак. И задължително показваме как точно решаваме неговите проблеми с продукта си.
Условие №4. Бързо създаваме пилот, който изглежда приблизително като крайния резултат. Да направите всичко напълно страхотно е примамливо, но можете да се сблъскате с перфекционизма, поради което вместо пилот ще искате да покажете вече идеалната версия на продукта. А такива неща не съществуват. Затова просто направете нещо, дори и то да е от пръчки.
Условие №5. Продукт. Проектът расте, получава финанси, идват специалисти с солиден опит.
И ако сте класически стартапер, това е моментът, когато трябва да бягате с възможно най-голям риск. Защото лесните полети на височина и чувството за обща благост бързо могат да се разсеят.
Изходът в продукция е сблъсък с реални натоварвания, интеграция с десетки системи, а когато създавате нова функционалност, работите паралелно, за да усъвършенствате старите версии. Всичко това е много по-сериозно предизвикателство, отколкото да измислите идея и да решите дори добре, но само един проблем на клиента.
Тези предизвикателства и растежът на уменията се случват именно на този етап.
Благодаря, че прочетохте. Щастлив нов код!
Източник: habr.com
