Продолжаем забавные истории с собесов

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

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

Этапы были такие: HR → Android и Kotlin → Алгоритмы → Системный дизайн.

На Android и Kotlin были базовые вопросы и куча вот этих пазлеров про многопоточку. Помню, что я тогда прям задротил всё, что связано с многопоточностью, и точно ответил на все вопросы. Однако мне всё равно поставили Middle. Не знаю почему, возможно, я где-то промахнулся.

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

Однако интервьюер попросил меня рассказать про устройство heap. И вот это какая-то херня, давай меня ещё про красно-черное дерево спроси! Разумеется, я не смог рассказать про устройство — сомневаюсь, что сам интервьюер бы смог, но да ладно.

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

Хороший вопрос на подумать, ведь обычно мы баги отслеживаем по аналитике, а как понять, что баг именно в либе для аналитики? Ну, я предложил два вектора защиты:

👉 Системные логи, которые мы можем получить вместе с другими логами приложения.
👉 Интеграционные тесты, в которых мы прям бэк мокаем, чтобы проверить полностью работу либы.

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

Собственно, как-то так. Если меня читают ребята из Авито — если что, без обид, я же любя ❤️

Ну что ребятки, финалим эту серию про CI, какие задачи лучше не делать в CI.

Присаживайтесь поудобнее мы погружаемся в инфраструктурный хардкор.

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

Например вы хотите пинговать разработчика, если у него упал пайплайн на МРе. Это не CI-задача, и нет смысла занимать под неё целый runner.

В идеале я бы советовал развернуть на серверах компании какой-нибудь n8n. Вы тогда получаете гибкий инструмент в котором можете развлекаться как хотите без влияния на пайплайны.

Требуется гибкая логика повторных запусков. В Gitlab и похожих системах есть retry, но весьма тупой. Он не позволяет задать условия повторного запуска, основанные на типах ошибок или внешнем состоянии.

Нельзя например сказать: «Повтори, если ошибка 500», «Повтори с экспоненциальной задержкой».

В этом случае лучше подойдут системы c возможностью описывать, при каких условиях и сколько раз нужно повторять шаг вроде Airflow, Prefect или Temporal.

Вас не устраивает линейная структура. Если у вас возникает желание, ах вот если бы сюда поставить if или какой-нибудь while, то это явно не про CI. Платформы вроде GitLab CI поддерживают только линейное выполнение без предусловий. Airflow, Prefect и Dagster позволяют описывать не только последовательность действий, но и условия, при которых они должны выполняться.

Вам нужен гибкий cron с историй запусков. В CI системах есть примитивный cron вроде: «запускай вот этот пайплайн каждый день в 12 ночи». Однако в задачах вроде дообучения моделей или каких-то бизнес процессах могут возникнуть потребность: «выполнять cron только по будням», «пропускать запуск, если нет входных данных», «догнать пропущенные даты если была ошибка».

Помимо этого в Gitlab CI еще и историю запусков по cron нельзя просмотреть, показывается только последний запуск, а этого может быть мало.

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

Если логика основана на событиях извне, её проще и надёжнее реализовать в n8n или Prefect, где предусмотрены подписки на события, задержки и отложенные действия.

Подводя итог: CI нужен для тестов, сборок и деплоя. Всё, что выходит за рамки «выполни скрипт и проверь результат», особенно если это связано со временем, входными данными, внешними событиями или сложными зависимостями — должно выполняться в отдельных специализированых системах.

Если же данный пост показался вам слишком перегруженным и вы потерялись в названии кучи сервисов записывайтесь на мой авторский курс «Батя инфры» на котором я научу вас работать с данными системами и зарабатывать миллионы.

Меня это конечно задело. В прошлом посте был комментарий, что из-за того, что в постах у меня много длинных тире "–" вот таких. Велика вероятность, что пост сгенерирован через LLM.

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

Использую ли я LLM для постов? Конечно да, но для правки орфографии, без этого у вас бы кровь из глаз шла. Я же дурачок и пишу с ошибками. Однако идеи, структура поста и шутки (почти все) исключительно мои. Я максимум могу еще LLM попросить сделать факт чекинг или убрать тавтологию.

Ну и я как тревожная личность пошел в другие каналы, в которых я на 100% уверен, что они ведутся людьми и посмотреть что там со стилем. Ну в 90% постов используются длинные тире, и либо мы все генерим контент через LLM, либо все же нужно смотреть на другие признаки.

Попалась в одной статье вот такая картинка.

Не ней расположены ожидания даты появления AGI от различных экспертов по искусственному интеллекту. Думаю вы сразу обратили внимание на ожидание от Джеффри Хинтона.

Сперва пару строк, кто вообще такой Хинтон. Хинтон – ученый, который по факту может считаться батей всего ML, ведь это он изобрел подход backpropagation, который является прям базой для всего глубокого обучения.

Так вот, вам не кажется, что его оценка, скажем так... немного читерская?) Ее буквально можно перевести как: "Ну хз, возможно появится в следующем году, а возможно через лет 30, че вообще доебались?". И вот он либо гений, либо очень не хочет прогадать с ошибкой)

Недавно слушал один подкаст, в котором очень матёрые ребята обсуждали книгу Дяди Боба. Кто меня давно читает, знает, как я к ней отношусь. Если что, вот серия постов.

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

👉 В "Чистом коде" рекомендуется делать маленькие функции, по 5–10 строчек, не более. Это дичь, а не совет. Делайте функцию не короткой, а понятной. Если у вас сложная логика, то пусть будет функция на 500 строк кода, но зато не нужно будет бегать по другим функциям, туда-сюда теряя контекст и не понимая, что происходит.

👉 Интерфейсы с одной реализацией – отстой. Я не устану про это говорить, и я был в таком восторге, когда понял, что я не один такой сумасшедший. В подкасте чувак жаловался на то, что он просит LLM сделать класс, а она ему постоянно подсовывает интерфейсы, которые приходится удалять. Понимаю...

👉 Unit-тесты с моками. Я уже делал серию постов про тесты. Если кратко, unit-тесты в привычном понимании, про которые идёт речь в "Чистом коде" или книге по TDD, почти ничего не дают на практике. Да, сейчас их проще писать с LLM, и иногда это прям нужно. Однако в подавляющем большинстве случаев они только мешают. Всю свою карьеру я слышу: "Если ты поменял код, меняй и тесты". А толку от этих тестов, если они не позволяют делать рефакторинг без регресса?

Ну и в конце была очень крутая фраза. Можно по-разному относиться к чистому коду, однако будем честны: написать книгу, которую вся индустрия будет критиковать даже спустя 30 лет — это прям мощно...

Я всё-таки решил зайти в код Telegram. Задание выложили, и я подумал: дай-ка посмотрю, насколько там всё сложно. До этого я лишь пробегался мельком и особо не углублялся в кодовую базу.

Какой же это карнавал боли и страданий! Я правда готов признать: разрабы Gradle, вы чёткие ребята. Мне кажется, значимая часть компенсации разработчика, который работает с кодом Telegram, уходит на психиатра. Вот тут действительно современные знания Android-разработки идут по направлению нахуй, они вообще тут бесполезны.

Я бы в readme к проекту написал: «Оставь надежду, всяк сюда входящий».

Итак, качалка.

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

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

На текущий момент мой максимум 115, но на прошлой трене у меня уже 110 получается выжать на 3 раза, что означает, что 120 маячит вот уже прям перед носом.

Возможно, было бы и больше, если бы я не вьебал себе плечо на верёвочном парке месяц назад, но это уже отдельная история.

Когда делать рефакторинг?

Вопрос от подписчика. Кстати, если у вас есть интересные вопросы для разбора, можете писать в личку канала.

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

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

Если перекос в сторону бизнеса, стоимость внедрения фич улетит в космос. Если победит разработка, мы будем бесконечно рефакторить код чтобы сделать идеально, спорить о важности SOLID и переписывать всё на новые UI-фреймворки.

Важно соблюдать баланс. Поэтому для проведения рефакторинга нужны четкая цель и причина. Нужны метрики, по которым будет понятно, что рефакторинг необходим. Например: График времени выполнения похожих задач — если он растет, значит, что-то не так с техдолгом. Не всегда это можно отследить, поэтому могут быть чисто технические метрики:

👉 Архитектурные ограничения — из-за текущей архитектуры мы не можем использовать что-то, кроме UI-тестов. Метрика: количество не-UI тестов.
👉 Отсутствие навигации — из-за этого онбординг новых разработчиков занимает дни, а код-ревью превращается в хаос. Метрика: время на ревью, время онбординга.
👉 Ненадежные тесты — текущая библиотека для тестов сильно флакает. Метрика: количество флакающих тестов.

Это если мы говорим про рефакторинг, который идет от разработки. Но иногда он может идти сверху: "У нас в компании обновилась библиотека для полей — нужно перейти на новую версию для консистентности UI."

Короче, для действительно нужного рефакторинга важны:
👉 Четкая цель
👉 Измеримые метрики
👉 Минимальный roadmap (как внедрять изменения постепенно)

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

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

Пару лет назад, когда я только пришёл в команду инфры, одной из первых задач было перевести одного бота в кубер. Потому что у нас в компании все мелкие сервисы как раз активно туда переезжали. И я тогда вёл забавный дневник, который назвал: "Путешествие мобильщика в мире куберов". Погнали:

👉 Поставили задачу перевести RMS (внутреннюю систему) в k8s. Думаю: «Справлюсь быстро, нужно всего-то почитать пару док – выглядит изи».
👉 Изучаю, что вообще такое k8s, читаю инструкцию по переезду. Оказывается, у нас есть своя обёртка над k8s – называется Unic.
👉 Изучаю, что за Unic. Нихера не понятно, но очень интересно. Начинаю разбираться, как работают пайплайны для деплоя в Unic.
👉 Нужно запросить доступ к k8s от CI нашего проекта. Пишу админу, прошу изменить настройки сети. Меня шлют лесом – бля, я что, опять на сайте знакомств?
👉 В итоге договариваемся, прокидываем сетевые доступы от CI до k8s.
👉 Настраиваю пайплайны публикации по инструкции для демо-проекта. Добавляю Dockerfile, подключаю пайплайны Unic, в доках которого гордо заявлено, что он сам умеет собирать и публиковать докер. Генерирую паспорт проекта – да, именно паспорт.
👉 Пробую задеплоить демо-проект. Пайплайны падают, ругаются на паспорт. Благо я из Казахстана и к доёбам из-за паспорта привык.
👉 Пишу в группу SRE по поводу паспорта. Они просят прописать специальные доступы в CI.
👉 Снова прошу владельца инфры прописать доступы. Он прописывает мне по ебалу. Отказывает, говорит: не выдам доступы.
👉 Пишу снова SRE, что не получается выбить доступы. Спрашивают: "Нужно деплоить на прод?". Отвечаю: "Нет, только в QA".
👉 Тогда отвечают: "А, ну если в QA, то и с паспортом не надо заморачиваться". Блять…
👉 Отключаю таски проверки паспорта в CI (жалко, в Госуслугах так нельзя). Пробую ещё раз задеплоить демо-проект.
👉 Фейл: неправильный формат конфигурационного файла (хотя я взял его с демо-проекта без изменений). Ещё раз изучаю файл, выставляю все поля как надо.
👉 Пробую снова – оказывается, Unic рот топтал сам собирать и публиковать докер. Надо делать всё вручную.
👉 Добавляю отдельную job-у для публикации докера демо-приложения.
👉 Фейл: нужны сервис-аккаунты для публикации в Artifactory, которые соответствуют билд-инфре. Остальные не работают.
👉 Прошу создать эти аккаунты – слава богу, сделали сразу. Меняю настройки пайплайнов.
👉 Докер опубликовался, но деплой упал: не хватило ресурсов. Оказывается, нужно количество инстансов +1 запасной.
👉 Делаю 3 инстанса в namespace. Три инстанса для сервиса, у которого 3 запроса в неделю – Big Tech, хуле…
👉 Ещё попытка деплоя – успешно! Демо-приложение задеплоилось. Пытаюсь перенастроить пайплайны на наше приложение.
👉 Запускаются, но сразу падаем. Причина – неизвестна. Начинаю искать.
👉 Оказалось – неправильно настроен health check. Думаю написать заявление, но передумал.
👉 Меняю health check. Пробую деплой. Успешно. Приложение запустилось.
👉 Пробую отправить запросы. Запросы уходят в пустоту – происходит целое нихера.
👉 Понимаю: срочно нужны логи. Внедряю логирование. Деплой успешный. Пытаюсь найти логи – логов нет!
👉 Теряю надежду, хочется плакать. Читаю доку ещё раз. Проверяю "чистилище" для неправильных логов – да, они, разумеется, тут. Правлю формат логов.
👉 Логи есть. Отлично. Понимаю, где ошибка в обработке запроса. Чиню.
👉 Делаю пробные запросы. Аллилуйя – всё работает.

Многие спрашивают меня, каково это – работать в большой корпорации. Это крайне увлекательное занятие, которое состоит из:

– Вводим пароль для VPN, получаем код на телефон, заходим в VPN, идём в Jira – опять код на телефон, идём в GitLab – ах да, снова код на телефон.
– Затем идём на дейли-ретро-стендапо-планирование, на котором два часа обсуждаем, каким образом будем красить кнопку и какой Json нам жизнено важно переложить сегодня.
– Читаем документацию к инструменту, который используется только в данной компании и знания о котором на внешнем рынке столь же полезны, как презерватив в монастере.
– Красим кнопку – но только под фиче-флагом, ведь A/B-тест!
– Перекладываем Json из базы на клиента.
– У нас AI-прорыв – теперь перекладываем Json из одной LLM в другую.
– Всем стоять, никому не двигаться! У нас фича-фриз и отвод релизной ветки.
– Кстати, ты не менял пароли от учёток уже пять минут – иди меняй!
– Повторяем на следующий день.

Короче, ребята я решил признаться. Несмотря на мою искреннюю любовь к typescript и качалке, мне нравятся женщины!

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

После прошлого поста отписалось пару человек. Бедняги, наверное думали, что у них был шанс...

Итак, я навайбкодил себе синтаксический анализ кода Kotlin

У меня за последние два дня произошёл крутой AI-момент. Есть у меня одна CLI-тулза, которая ищет тесты на проекте. Ищет она их тупо, пробегаясь по всем файлам. Заглядываем в файл, пробегаемся по всем методам и вытаскиваем все, у кого есть аннотация "Test" и "AllureID".

Для задачи можно было тупо использовать regex. Однако там ещё есть хитрая логика exclude тестов по специальной аннотации, которая может быть как на методе, так и на классе. Короче, regex, конечно, можно использовать, но это получится очень хрупкая штука.

Поэтому, чтобы не париться и при этом сделать стабильное решение, я затащил Kotlin embedded compiler. Он даёт полный карт-бланш на работу с AST. Однако есть ложка дёгтя — compiler весит под 70 MB. При этом я использую максимум полпроцента функционала.

Поэтому я решил: а дай-ка я навайбкодю себе свой анализ, который будет делать самый минимум, который мне нужен. В этом мне поможет мой безмолвный напарник в виде Aider и Claude под капотом.

Когда я дал Claude задачу верхнеуровнево, он, как и полагается ленивому разрабу, попытался всё сделать через regex. Пришлось его явно просить о том, чтобы он сделал машину состояний, а также сначала разбил код на токены и только потом провёл анализ и вытащил нужные мне данные. Я, конечно, знатно удивился, но он всё сделал с первой попытки – от меня потребовалась лишь правка в одном месте.

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

Далее я пошёл и вручную отрефакторил его код в более читаемый вид – сгенерированные тесты помогли убедиться, что я ничего не сломал.

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

В итоге я сделал нужную мне штуку за полтора дня. Без LLM я бы, наверное, потратил примерно неделю.

Что из этого можно вынести:

👉 Сейчас много где кричат о том, что разрабов заменят на LLM. Чем больше работаю с LLM, тем больше убеждаюсь, насколько это чушь. Сама по себе LLM генерит неподдерживаемое, ломающееся говно.

👉 С LLM ты реально получаешь буст производительности, потому как я бы одни только тесты полдня писал, а тут они были готовы за пару минут.

👉 При работе с LLM крайне важна база. Благодаря универу я более-менее знал, как правильно делать синтаксический анализ. Без этих знаний я бы до сих пор возился с решением через regex, которое абсолютно не расширяемое.

Короче, LLM не заменит разраба. Однако разраб, который умеет грамотно работать в паре с LLM, вероятнее всего заменит :)

Короче, я тестировал VK-знакомства в течении недели и вот, что я понял!

В целом, смерть в одиночестве не самая плохая альтернатива.

Недавно вспомнил, что хотел поделиться с вами одной статьёй – пожалуй, единственной, которая за последние несколько лет действительно отозвалась у меня в душе. Называется она: "Я программист, и я тупой"

Главная идея статьи в том, что автор говорит: у меня скудные интеллектуальные способности, поэтому я нивелирую их инженерными практиками. И дальше – всего в нескольких абзацах – изложена лютейшая база того, как вообще стоит подходить к разработке.

Мне кажется, что все самые крутые инженерные практики рождаются именно из ограничений нашего мышления: мы пишем тесты, потому что наша внимательность ограничена; мы создаём документацию, потому что со временем всё забываем; мы делаем код-ревью, потому что не можем охватить всю кодовую базу в одиночку.

Мы не нейросети, которые всё помнят и ничего не упускают. Поэтому один из самых важных навыков – это умение управлять сложностью. Если твои решения просты и при этом работают, то ты точно не тупой. Мне кажется, как раз наоборот – с такими людьми я бы и хотел работать.

Иду домой, зная что второго свидания не будет, но теперь она знает почему делать интерфейсы с одной реализацией – плохо

Итак, конкурс.

Я решил поучаствовать в конкурсе авторских Telegram-каналов. Правила в нём – как в бойцовском клубе, только ровно наоборот. Первое правило: рассказать всем об этом конкурсе.

Поэтому вот тут подробности. Вот тут – главный канал конкурса: @tg_contest_main (в котором и будет происходить вся туса).

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

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

Еще я понял, что возможно нужно перестать писать посты из спортзала)