Ретроспектива на проблемите. Как собственоръчно решение се оказа по-добро от платено

Здравейте! Казвам се Алексей Пьянков, главен програмист в компанията Спортмастер. Да кажа веднага, че "главен" не означава "най-важен от всички програмисти", не, това е просто заглавие, един очарователен превод за "Senior+".

В компанията Спортмастер работя от 2012 година и през това време нашият екип по разработка е създал много решения, интересни от техническа гледна точка. Но днес бих искал да говоря за нашата работа с акцент по-скоро върху това как разсъждавахме в определени недвусмислени ситуации.

В тази статия няма да има конкретни технически решения (всъщност не и нещо техническо), което да бъде взето и приложено в проектите ви. Скорее — това е рефлексия относно направената работа. Имаха специални моменти, които повлияха на нас като екип — сплотиха, закалиха и изпитаха на здравина. За тези моменти, за атмосферата на работа в екипа, за нашите грешки и редица психологически капани, в които понякога сами попадаме, ще опитам да споделя днес.

Ретроспектива на проблемите. Как собственоръчно решение се оказа по-добро от платено

И ще започна именно от 2012 година.

Стигнах в 2012 с основната цел за онова време — работа по нашия флагмански сайт. Тогава той беше "монстрът Фроузен": част от екипа работеше с нашата стара система, която не се справяше особено добре с натоварванията (Bitrix), а друга част от екипа (в която бях и аз) се опитваше да внедри нова система, която избрахме с критерия "Ако е най-скъпата e-commerce в света, взимаме я". Всъщност "опитвахме се да внедрим" — защото системата яростно се съпротивляваше, и на всеки момент, с който успявахме да се справим, задължително се появяваше "изненада" в отговор. Работихме много, но напредвахме с бавността на охлюв.

Лично за мен последната капка беше запознаването с кода на един метод в тази "най-скъпа e-commerce в света", когато няколко часа концентрирана работа по объркващ бъг доведоха до това, че причината беше намерена някъде в custom-tag, който работи при генерирането на html в jsp. Задачата на този custom-tag е да покаже сумата на определени величини. Това не е лошо, за това custom-tag е предназначен. Но изненадата се криеше в това, че при това се променят някои данни в базата, свързани с поведението на следващите страници, и ако натиснете F5 — повикването се повтаряше, което нарушаваше консистенцията на данните. И то по такъв начин, че се проявяваше едва на третата страница от последователността. Не, не съм против да имам такъв "мастър-ниндзя" в отбора, който с кода си поддържа вниманието на колегите в тонус. Но да се случва в библиотеката на най-скъпата система!

Беше петък. А събота и неделя прекарахме с колегата в офиса с цел да разберем, какви задачи бизнесът поставя пред системата точно днес и какви задачи може да измисли след година. Съответно, как бихме ги решили, ако не бяхме принудени да използваме тази самата най-скъпа и най-дразнеща система.

Сказано — направено. Направихме пилот, в който положихме основите за разработката на новия сайт на Спортмастер. Много от тези идеи се приеха и в момента техните продължения активно функционират на сайта.

Етапи на пилота и времеви рамки

2 дни. Направихме микропрототип — през уикенда пренасочваме нашата база в ElasticSearch, правим фасетно търсене. Вуа-ля! В същата купена система такава настройка "взе" 2 седмици. А тук — буквално за няколко часа! Да не говорим, че работи по-бързо. Впрочем, бързо с порядък.

2 седмици. "Изграждаме" прототип, добавяме функционалност за адекватни персонализирани резултати.

Например, потребителят има няколко отстъпки и акции, които са валидни именно за него — тогава в резултатите от търсенето на стоки трябва да се покаже точно тази цена, която може да се получи, прилагащи всички налични бонуси по най-изгодния начин.

С акциите не е толкова просто. Например, купих ски, а сега имам 40% отстъпка за шапка, но в същото време се отменя приветствената отстъпка от 10% за цялата поръчка. Да, вярно е, това е реален случай 🙂 А за да настроим такава акция в системата за покупки, заплатихме 3 консултации с доставчика, в резултат на които получихме много примери как да реализираме различни други акции. Много дипломатично и, като се има предвид цената на консултациите — икономически това е доста добре.

Показахме на бизнеса подробна демонстрация. Обещахме бързо да съберем пилот и веднага започнахме работа.

2 месеца. Пилотният проект — правим го като жив сайт с търсене по каталог. Търсене с фасети, резултатите от търсенето — с персонализирани отстъпки, пилотът изглежда почти като сайта на Спортмастера, а и стоките, които качихме, са същите. Сладко!

Добавяме «Красноречие:100» на нашия шеф на отдела и презентацията за бизнеса преминава с успех! Дават ни карт бланш да разработим платформата за електронна търговия сами.

А това означава, запазете екипа, момчета, запазете бюджета, готино, нали!

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 трябваше да се патчират многократно — умело намирахме случаи, в които работеха различно от посоченото в документацията.

Лек старт и бързи успехи от използването на новата технология — това е добре, но те създават еуфория и намаляват бдителността. Защото новата технология съдържа бъгове, задължително съдържа бъгове. И ако за тях още не е писано — радвай се, точно на теб ти предстои да бъдеш този първоходец, който със сигурност ще открие нещо криво и ще започне да търси информация в Гугъл или на SO. Разбира се, „кривото“ може да бъде намерено и в проверени продукти, но в новите — това е много по-лесно.

Ретроспектива на проблемите. Как собственоръчно решение се оказа по-добро от платено

Въпреки всички трудности, ние излязохме в продукция. Да, с лагове. Да, не толкова стабилно. Но общо взето — без катастрофи.

И така, отново ще посоча капаните, в които се изкривява здравото восприятие на работния процес.

  1. „Екстраполятор-крутиша“. Под впечатлението на текущите успехи продължаваме и радостно екстраполираем скоростта на разработка за предстоящите проекти.
  2. „Стахановец“. Работим на износ, доволни сме от себе си, но не забелязваме, че проблемите, които решаваме — това е резултат от нашите лични грешки/недочети/пренебрежения. Работи, които не следва да бъдат извършвани.
  3. „Сила Hello world“. Бързаме да внедрим в продукция всичко най-ново и интересно.

Защо всичко проработи

Разбира се, изброих не всички грешки, които имахме през това време, но най-общите, вероятни за проект с всякаква специфика. Тази фиксация на грешките помага да се избягват в бъдеще.

Няколко думи за това как успяхме да създадем такъв мини-стартап в рамките на компанията и да убедим бизнеса да се откаже от вече закупената система в полза на нещо собственоръчно написано.

Условие №0. Здравословен климат в компанията. Това не са само „горящите очи“ на служителите и комуникативността в стресови условия на печалба, не. Това е за всички взаимодействия.

Условие №1. Да вярваш в това, което правиш. Наистина, не смятам, че бихме имали шанс, ако бяхме започнали пилот, без да разберем закупената система „до последния винт“ — т.е. отстъпвайки и подсъзнателно знаейки, че тази система е по-добра и ще ни победи.

Какво направихме: 1) разгледахме закупената система, с нея решихме основните запитвания от бизнеса 2) съставихме списък на задачите, които не само съществуват в момента, но ще се появят и в обозримото бъдеще 3) подбрахме решение, което подхожда най-добре. И така, нашата оценка на решението — беше оценка от експертите.

Ще ни дадат ли нещо, ако просто дойдем и кажем: „Ребята, всичко е на кукуруз, не искаме да се занимаваме с това и решихме да започнем от нула”? Малко вероятно. И получаваме отговор в такава форма, че добре да се запомни 🙂

Условие №2. Първата стъпка е малка. Генерираме първата хипотеза и я проверяваме. Може да отделите и своето лично време за това. Ако не искате да губите времето си, значи по-добре не се захващайте с това. А ако не искате да проверявате малка хипотеза, а искате веднага да направите нещо страхотно и с блясък — дръжте се на далеч от такива хора!

Ни повезе, и проработи най-първата хипотеза. Но това не става винаги. Например, в един от последващите проекти, когато популяризирахме администраторския панел в рамките на подобен пилот, само 18-ият вариант проработи. А 17-те първи подхода към задачата бяха напразни. Между другото, в историята със създаването на администраторския панел, сюжетните обрати бяха на нивото на бразилските сериали, защото екипът се състоеше от мъже, които вече бяха ветерани – истински „недопечени калачи”.

Условие №3. Правим MVP и търсим проблемите на лицето, което взема решения. Разбира се, ужасът може да се отрази на лицето му само от факта, че в тридесетия път му носите някаква идея. Но все пак. И задължително показваме как именно решаваме неговите проблеми с нашия продукт.

Условие №4. Бързо правим пилот на коляно, който изглежда приблизително като финалния резултат. Да направиш всичко наистина страхотно — е примамливо, но може да се уплиш в перфекционизма, от който се оказва, че вместо пилот искате да покажете пилотна версия на вече идеален продукт. А такива няма. Затова просто направете нещо дори от пръчици.

Условие №5. Продукт. Проектът расте, получава финанси и идват специалисти с солиден опит.
И ако вие сте класически стартъп, това е точно моментът, когато трябва да свирите и да напуснете. Защото лесните полети по най-високите върхове и усещането за обща благост бързо се разсейват.

Излизането в продължава е сблъсък с реални натоварвания, интеграция с десетки системи, като същевременно, когато създавате нов функционал, поддържате и подобрявате старите версии. Всичко това са предизвикателства, много по-сериозни, отколкото да измислиш идея и да решиш да кажем, добре, но само един клиентски проблем.

Това са предизвикателства, и развитието на умения — става точно в този етап.

Благодаря, че прочетохте. Щастлив Нов Код!

Източник: habr.com

Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри 🔥 Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри | ProHoster