будни

На прошлой неделе было удивительное:

1. Федя признался, что понял кайф вайб-кодинга (до этого он всё время говорил, что понимает, что это такое, но я бы описал его прошлую позицию как просвещённый луддизм); надеюсь, сделаем про это с Федей отдельный эпизод подкаста.

2. Настя, наш операционный директор (не программист), завайбкодила прототип для клиента в lovable. Раньше бы мы назначили встречу с продуктовым дизайнером, он бы нарисовал макеты, мы бы сделали пару встреч и итераций, дальше бы мы его, может быть, сделали кликабельным, дальше бы посадили фронтендеров его заверстать. А тут Настя сделала всё сама за пару часов. И отправила клиенту не просто макеты, а полноценный прототип. Клиент — стартап, в котором нужна возможность связать врачей и пациентов, так эта шайтан-машина нашла бесплатное решение для видеосвязи и прикрутила его к прототипу.

Настя выглядела поражённой и даже встревоженной: «Самат, с помощью этого можно перестроить работу с клиентами». И спросила: «А нужны ли будут программисты?» и вообще: «Какое наше место в этом новом мире?»

Я спокоен: сложные, большие программы эта система всё ещё не может сделать нормально, и наше умение придумать гибкую, масштабируемую архитектуру, задавать и выдерживать требования к качеству при меняющихся требованиях — это технические навыки, которые делают нас (и наших программистов) ценными. Плюс мы думаем над задачей клиента, не просто бездумно исполняем приказ.

То есть программист сможет заниматься чуть более сложными вещами и ускорит свою работу.

Вспомнил, что на днях общался со знакомым, который делает сервис по созданию кастомных приложений обычными людьми. То есть ты говоришь, какое приложение хочешь, начинаешь им пользоваться и можешь прямо на лету что-то в нём поменять, с сохранением уже введённых данных, вообще не имея дела с кодом. Подобные инструменты, скорее всего, съедят нижнюю часть рынка, «простую разработку». Как мы сегодня не ищем дизайнера и верстальщика, чтобы написать объявление в ворде или сделать простую страницу на тильде, но обращаемся в издательский дом, если хотим опубликовать книгу, или нанимаем команду, чтобы запустить большой маркетплейс.

—

Ну и наконец, если в каком-то будущем мы сможем делать крутые программные продукты «совсем без программистов» — то:

1. долгосрочно, у нас будут гораздо большие проблемы, потому что перестроится вообще весь рынок интеллектуального (а с развитием физических роботов — вообще всего) труда, мир изменится;

2. краткосрочно, мы сами сможем гораздо смелее тестировать свои продуктовые гипотезы для своих продуктов (а мы хотим развиваться именно в сторону продуктовой разработки).

—

То есть я настроен оптимистично, но то, что два этих события произошли почти одновременно, не идёт у меня из головы. Кажется, что мы незаметно преодолели очередной барьер развития ИИ.

Вчера разбирали кейсы про разработку с продактами в школе wannabe и я понял, что это одна из вещей, которую я люблю больше всего: помогать продактам (дизайнерам, владельцам бизнеса) выстраивать отношения с разработкой, отвечать на вопросы продактов про разработку.

Если вы продакт, дизайнер или основатель бизнеса и у вас есть вопросы про разработку или трудности с разработкой — пишите, буду рад помочь! @samatg

Как перезапустить проект технически?

Прямо сейчас мы решаем эту задачу для стартапа. Ребята делают платформу для ученых, чтобы проводить исследования на больших группах респондентов. Куча интеграций, огромный зоопарк форматов данных.

Они пользуются уже третьей версией своей платформы. Фронтенд на low-code платформе Bubble, бэкенд частично на flask и частично n8n. Всё работает, приносит пользу, проект поднял больше миллиона долларов инвестиций.

Как навести порядок, радикально увеличить скорость доставки фич и гарантировать масштабируемость?

Первый порыв любого программиста — переписать всё с нуля. Благо, проект ещё не очень большой, за месяца 3–4 парой программистов, наверное, можно управиться. Составить список фичей, написать их заново, потушить сервис на пару часов, импортировать данные из старой системы в новую и запуститься.

Но это — ошибка. Во-первых, мы не понимаем истинного объема бизнес-логики, который успел накопиться в коде. Скорее всего, сам клиент её недооценивает. Во-вторых, пока будем переписывать — проект продолжит развиваться. Придется догонять. В-третьих, любой, кто делал импорт данных, скажет вам, что это задача из ада, и чем старее данные — тем сложнее их вытащить. Настроить тестирование этого нового проекта будет сложно, да и полноценным оно не может быть по определению.

В результате, в момент включения новой платформы в продакшен, точно возникнут проблемы, которые придется героически исправлять «прямо сейчас», в стрессе. Мало предсказуемости, о реальном объеме работы мы узнаем только в самом конце проекта, при попытке переключения. Мы такое не любим.

Правильный ход — это strangler fig pattern. Пишем небольшую обертку для старого бэкенда. Этот новый бэкенд действует как прокси — передает запросы к старому бэкенду, запоминая сами запросы и ответы. Дальше выделяем первые эндпоинты бэкенда, которые мы можем запрограммировать заново, красиво. Дублируем эти запросы пользователей в старый и новые движки. Сравниваем ответы нового движка с ответами старого, исправляем ошибки. Накапливаем информацию в новую, аккуратно составленную базу данных. И только после продолжительного тестирования на живых данных начинаем отдавать пользователю ответы нового бэкенда. Берем следующую пачку эндпоинтов и повторяем процесс.

Получается, у нас нет момента «большого рубильника», который переключит весь трафик со старого движка на новый, мы «едим этого слона по частям». Переход со старого бэкенда на новый происходит плавно, незаметно для бизнеса. Ошибки в новой системе видны только программистам и не затрагивают клиентов.

Не менее важна предсказуемость. В первом подходе мы весь проект живем под дамокловым мечом — какие сюрпризы нас ждут при запуске? Во втором подходе мы размазываем эту неопределенность по всей продолжительности проекта, так что уже через пару недель можно увидеть реальную скорость разработки, включая исправление ошибок, и оценить общий объем работы и сроки.

Наконец, этот подход позволяет выкатывать новые фичи в продукте внутри нового бэкенда до окончания переезда, параллельно с рефакторингом.

К сожалению, кажется, что каждый молодой программист обречен пытаться всё переписать правильно с нуля. Технарь, предлагающий strangler fig pattern, не лучше, просто за его обучение уже заплатил другой заказчик.

На фотографии тот самый фикус-душитель опутывает дерево, как новый бэкенд опутывает старый.

Только что опубликовали новое мобильное приложение в AppStore. Сделали его наши веб-разработчики на кросс-платформенной технологии CapacitorJS, так что не потребовалась отдельная команда мобильной разработки, сэкономили месяцы и миллионы рублей.

Два месяца переписывались с Apple по поводу in-app purchases и прочих коммерческих моментов. В результате всё решилось одним коротким звонком с Купертино. По телефону нам на хорошем русском объяснили, что «правила AppStore — это направляющие принципы, каждую ситуацию не распишешь формально, конкретно вам нужно сделать 1, 2, 3». Не стесняйтесь пользоваться опцией заказа звонка!

Интересно, что ни единого вопроса про Capacitor у Apple не было, хотя некоторые люди нас очень пугали, что любые веб-технологии — это сразу бан. Правда, наши фронтендеры собрали полноценное мобильное приложение — с оффлайном, входом через Apple ID и прочим, чего у сайтов обычно нет.

Раньше я был скептически настроен к кросс-платформенной мобильной разработке, но для не супер сложных приложений веб, кажется, победил.

Такой кайф, когда единая команда отвечает за продукт на всех платформах! Нет этого: «веб уже запрогал, андроид сделал не совсем как нужно, но сойдёт, а iOS-команда пока занята, ждём...»

Ура!

Если вы думаете о выпуске мобильного приложения — рекомендую присмотреться к Capacitor — классная технология. Подробный технический рассказ — примерно через месяц: клиент хочет сделать анонс, когда приложение немного обкатается.

Interview Coder безусловно помогает пройти формальное собеседование. С одной стороны, я не питаю иллюзий, что крупные компании откажутся от этих формальных проверок. Уже слышно, что компании всё чаще зовут кандидатов на личные встречи вместо созвонов онлайн. Не удивлюсь, если появятся технологические «античиты».

Интересно, что эта программа мало поможет при устройстве на работу к нам в компанию.

Обычно мы просим в свободном режиме, за пару дней решить реальную бизнес-задачу в коде. Пользуйся чем хочешь. Главное — чтобы был результат, прямо как на настоящей работе.

На собеседованиях же мы никогда не просим запрограммировать стандартную задачу, а говорим о личном опыте человека. Для этого не обязательно помнить деталей библиотек или названий функций. Важно понимать суть происходящего (ну или хотя бы показывать заинтересованность в ней), продемонстрировать, что умеешь видеть за техническими особенностями бизнес-цель и думаешь о том, как принести реальную пользу, а не просто «закрыть задачу». Ну и показать, что ты человек, с которым хочется работать вместе.

Тут современный ИИ может даже помешать.

Реальный мир на порядок богаче, сложнее и интереснее, чем любой экзамен. Если (когда) нейросети научатся решать реальные задачи, а не экзаменационные — вот тогда нам будет чего опасаться. С другой стороны, это будет совсем другая реальность и отбор хороших программистов вряд ли будет тогда насущным вопросом.

—

Но вернемся к Рою, которого уволили из университета.

Через месяц, Рой с другом основывают компанию Cluely. Этот сервис — уже не просто способ обмануть собеседования, но общий инструмент для удобного и незаметного использования ИИ. Слоган компании, оцененной в 120 млн долларов — «cheat on everything» — «жульничай во всем / списывай везде». Рекламный ролик — парень пользуется ИИ через виртуальные очки, чтобы врать на свидании. Самоирония?

Основатели сравнивают свой продукт с гуглом, калькулятором и проверкой орфографии — мол, бороться с ними — то же, что и бороться с прогрессом, который облегчает жизнь.

Стала ли наша память слабее от того, что мы не запоминаем десятков номеров телефонов, как раньше? Хуже ли мы ориентируемся в городе с появлением навигаторов? Становятся ли наши ноги и тело слабее от того, что мы ездим на машинах? Стоит ли отказываться от смартфонов, навигаторов, автомобилей? Стали ли мы хуже разбираться в мире с появлением гугла и тем, как он заменил библиотеки? К чему в этой цепочке примеров ближе ИИ?

Ещё одна аналогия, которая приходит в голову — это как если бы я поехал марафон на велосипеде. Буду ли я быстрее любого человека? Имеет ли это смысл? А что, если на работу доставщиком пиццы будут брать только победителей марафона?

ИИ заставляет заново задуматься о том, что значит быть человеком и зачем мы делаем те или иные, очень привычные вещи. Думаю, что дальше таких вопросов будет всё больше.

Начали проект по перезапуску большого и важного медиа — миллионы читателей, миллионы страниц материалов.

Бизнес-задачи перед нами ставят стандартные: редизайн, улучшение пользовательского опыта и удобства редакции, без потери трафика.

Технически сейчас это программа на C#, которая в одну сторону торчит админкой для редакции, а в сторону читателей генерирует HTML-страницы сайта. Это популярный сетап из 2000-х. Техническую задачу я формулирую как облегчение процесса разработки без потери производительности сайта.

Дело в том, что в текущем сетапе фронтендер не может нормально верстать страницы без привлечения бэкенда — это мешает быстрому и предсказуемому развитию бизнеса.

Современный фронтенд ушёл далеко вперёд в удобстве разработки; собрать классический отдельный фронтенд для новостного сайта — не велика затея, мы делали это уже много раз.

Но будет ли современное веб-приложение (SPA) так же производительно, как HTML-страницы из 90-х? Речь и о скорости первого открытия — можно ли загрузить JS после полной отрисовки страницы? — и о скорости перехода между страницами — быстрее ли JavaScript-логика, чем отдать готовый HTML с сервера?

Можно ли получить лучшее из обоих миров? На какие компромиссы придётся пойти?

Пока что я не знаю ответов на эти вопросы. Кажется, что для успеха этого проекта придётся разобрать современную фронтенд-разработку по кирпичикам и пересобрать в новой, подходящей именно нам конфигурации.

—

Вдохновляюсь я вот этим видео, где инженер разбирает устройство фронтенда магазина строительных и промышленных инструментов McMaster. На первый взгляд может показаться, что это сайт из 90-х, на самом деле там под капотом почти все ускорения современного веба, которые только можно представить. Редкий случай хорошего видео для разработчиков, очень рекомендую.

P. S. Один из разработчиков McMaster пишет, что под капотом там VB.NET, хранимки и XSL-трансформации поверх XML для генерации веб-страниц. Хочется вот всё то же самое, только без VB, хранимок и XSLT. 🙈

Тормозит приложение.

На днях написала топ-менеджер одной ритейл-сети. Тормозит мобильное приложение. Медленно работает поиск, добавление в корзину, оформление заказа. Нажимаешь на кнопку и ждешь…

В ритейле каждая доля секунды задержки — это люди, которые не купили товары, прямые потери. Мобильные разработчики не исправляют ситуацию. Переводят стрелки на бэкендеров, мол это бэкенд тормозит. Как разобраться, на чьей стороне сломалось и починить проблему?

Хорошие разработчики собирают аналитику по производительности своих приложений — какое время занимают ключевые действия типа «открытие главной», «поиск», «добавление в корзину», «оплата». Это называется Real User Monitoring.

Дальше мы кладем эту информацию на график: на оси Х — время, которое занимает действие, на оси Y — количество пользователей. Столбики слева — хорошо. Длинный хвост справа — это несчастные, у них, например, экран оплаты грузится минуту! Эти люди поменяют приложение, если у них будет выбор!

Будущее уже наступило. Знакомый продакт-дизайнер, без опыта в программировании, показал проект, который собрал самостоятельно с помощью Windsurf. Это мини-приложение в телеграме для генерации картинок и видео через доступные на рынке модели. Человек без знания программирования в одиночку запускает сервис!

Он послушал наш последний эпизод подкаста про то, как хакеры взломали похожего стартапера и попросил аудит. Код там жуткий, проще заново написать, чем пытаться найти ошибки. Но когда я сказал Феде, «раньше такое даже представить было нельзя», Федя ответил «да ладно, это тот же код, что клепают плохие аутсорсеры и фрилансеры с бирж, просто теперь он его сам сгенерировал».

Договорились, что если проект взлетит — то мы его быстро перепишем, благо кода там немного.

А вот второе «будущее» не такое приятное. Мошенники начали притворяться мной в телеграме и писать знакомым. Коллеги говорят, это беда всех успешных студий сейчас. Так что, друзья, будьте осторожны, я в телеграме только @samatg

Опубликовал поздравление с 8 марта в бейзкемпе (это наш внутренний рабочий форум) и пожалуй продублирую его сюда.

Я вижу, что многие пытаются совсем закенселить этот праздник, потому что мы выросли, слыша стыдные поздравления о «прекрасных дамах, которые украшают наш коллектив».

Мне очень повезло — всю карьеру меня окружают крутые женщины-профессионалы и мне есть что вам сказать.

Поздравляю вас с международным женским днем! Это день посвящен женщинам, вашим правам, достижениям и борьбе за равенство. 

Каждая из вас здесь не потому, что она женщина. Вы здесь, потому что вы круче всех, кто претендовал на открытую вакансию. При том, что желающих попасть в нашу команду — много.

Я знаю, что женщинами порой приходится плыть против течения. Прикладывать больше усилий, чтобы заниматься любимым делом, а не тем, что «принято». Сделать больше, чтобы добиться того же признания. 

Как отец двух дочек, я смотрю на вас с надеждой. Я надеюсь, что и мои девочки тоже смогут вырасти и заниматься тем, что любят, стать профессионалами в своём деле. Вы для меня — пример и я вами горжусь.

Ещё я горжусь тем, что в нашей компании ценят результат, а не пол. Если вдруг вы заметите, что в чем-то это не так, — пожалуйста, дайте знать.

С праздником!

Встречали это «вечное противостояние» между продактами и разрабами? Каждый думает, что лучше знает, что делать с продуктом:

— нам нужно сделать такую фичу, срок такой
— сорян, у нас всё сыпется, надо технический долг отдавать, сделаем через три недели
— тогда летят наши квартальные цели
— а у нас всё сыпется

Раньше я думал, это — «здоровый производственный конфликт». Теперь я считаю, что это — признаки «бытовой неустроенности», того, что с разработкой в компании есть проблемы. К сожалению, 90% команд живёт в этом состоянии.

До конца недели я буду отвечать на вопросы о разработке в телеграм-канале «продуктовая культура». Если вопрос будет касаться взаимодействия продакта и разработки, отвечу я. Если вопрос со стороны технических специалистов про продукт, продуктовые циклы и всё это — ответит Валерия Розова, основательница курса «менеджер продукта».

Я приму участие в этом курсе — но об этом в следующий раз.