Dev Easy Notes

Итак, погода. Короче город дождей этим летом вообще не оправдывает свою репутацию. Ощущение такое, что на фоне уже должен играть Мик Гордон. У меня от этого пекла IQ пунктов на 20 упал. Вы можете возразить, что IQ не может быть отрицательным, однако пока посты пишутся так себе)

Топ 3 мифа, веря в которые вы гарантировано проебетесь по жизни: 👉 Хороший продукт/блог сам себя продаст 👉 Хорошего работника сами заметят и продвинут 👉 Любовь сама себя найдет Вам разумеется может повезти, но если вы в своей стратегии полагаетесь на удачу, то вы лудоман!

Наблюдаю что почти каждый день у меня появляются новые просмотры/репосты и реакции на старых постах. Количество просмотров бешенное. Хотел бы немного подсветить о чем канал, чтобы как можно больше людей изучили рынок. Канал посвящен прохождению интервью в различные компании в РФ и на зарубежном рынке. На данный момент в канале предcтавлены ~150 интервью в различные компании: 1. Различный Big Tech: WB , Sber, SberHealth, СберТехнологии(Gigachat) , Яндекс , Яндекс Head , Ozon , МТС 2. Банки: Иннотех, Иннотех , Еще иннотех , Альфа Technical Leader , АК Барс 3. Различные компании: Газпром, RuTube 4. Зарубежные компании: Nebius (Яндекс), Qatar Insurance Company , Jetbrains , Jetbrains , Exness, Plata (Ex-tinkoff) , Salmon (ex-tinkoff Manila) , TON , Staking Facilities , Constructor И многие другие... Так же для тех кто любит почитать: 1. Как зарабатывают 1 млн в найме обычные Senior'ы и Middle? 2. Теория больших денег или как выбивать огромные ЗП: Часть 2 и Часть 3 3. Статистика по собеседованиям : Отклики и конвертация в собесы 4. Зарплаты в ИТ в 2025 : опрос более 300 анкет Консультации: условия Блок Полезные ссылки для собеседований и работы: Конспекты: 1. Apache Spark 2. Clickhouse 3. Greenplum 4. DWH+Hadoop+Kubernetes 5. Задачки с собесов 6. Lakehouse Conspects Boost канала

Пришло время сделать новый закреп. Количество людей в канале понемногу растёт, поэтому пара строк о том, что это вообще за канал. Пишу я про разработку в целом: про собесы, технологии, личный опыт и качалку. Это канал про разработку для тех, кто устал от беззубых душнил, корпоративных блогов или ребят, которые падают в обморок при виде мата в тексте. Истории с собесов: 👉 Самый забавный собес в моей карьере 👉 Собес в Авито 👉 Собес в Aliexpress 👉 Советы по прохождению алго-секции 👉 Как уменьшить волнение перед собесом Истории и рофлы: 👉 Мой каминг-аут 👉 Про первое место работы 👉 Как я попал в инфру 👉 Какого это работать в БигТехе 👉 Приключения мобильного разраба в мире инфры Для любителей сериалов: 👉 Про CI 👉 Про тесты 👉 Про DI Немного базы про разработку: 👉 База программирования в одном посте 👉 Советы, как не проебаться в работе 👉 Как я навайбкодил синтаксический анализ 👉 Оцениваем сроки 👉 Что такое архитектура 👉 Разгоняем про логи 👉 В IT нет научного подхода Boost канала для неравнодушных

Итак, сплав Каждый год, в середине лета мы с коллегами, летим в Пермь. Куча айтишников собирается в месте, грузится на плоты и сплавляется по реке в дали от цивилизации. Чего только не сделаешь, чтобы убежать от злоебучих созвонов! Как это присходит: мы летим в Пермь в четверг, затем в пятницу утром мы грузимся в автобус и фигачим 4-5 часов в глушь. После берем свои вещи, упаковываем в гермомешки, грузим их на плоты и гребем по реке до вечера. Если вы работали в аутсорсе, для вас ничего необычного. Вечером мы ставим палатки (иногда сами, иногда это делают организаторы), тусим у костра до ночи в пьяном угаре. Ночуем в палатках, утром собираем вещи, опять плот, опять гребем до вечера. Затем опять костер, палатки. Утром грузимся, плывем до обеда. Доплываем до места, где нас забирает автобус, и едем обратно в Пермь. Если повезет даже без солнечных ожогов, пневмонии и укусов клеща. Обычно все идет по такому сценарию, но не в этом году. Как минимум, произошло три знаменательных события: Первое: я принес свой телефон в жертву Посейдону, не без помощи бесоебства человека, который был со мной на плоту. В этом году я забыл про главное правило сплава: "все, что есть на плоту, может оказаться под водой в любой момент времени" Второе: потянул лодыжку, играя во фрисби на мокрой траве. В итоге за лето я себе уже вьебал плечо и ногу, если так пойдет дальше, к концу лета я буду в коляске Третье: мы заспидранили сплав, закончив его на второй день, вместо третьего. На справе было слишком много эффективных менеджеров. От такого мува ахуели все, особенно организаторы... В итоге активность 10/10, но не рекомендую если вы в своем уме)

Detekt Кто-нибудь заглядывал в исходники Detekt? Если вы этого не делали, то я рекомендую заглянуть туда хотя бы одним глазком, потому что это реально произведение искусства. В репозитории — просто кладезь крутых подходов: как работать с Gradle, с Classloader, с Serviceloader, и как правильно проводить архитектурные границы. Помимо этого есть примеры того, как писать тесты на Gradle плагин. Все привыкли воспринимать Detekt как плагин для Gradle. Вы замечали, что у него довольно странная инициализация? Сначала нужно установить плагин, а затем отдельно указать версию Detekt. Возникает вопрос — нахера? Я же уже установил плагин, почему я должен ещё раз указывать версию? Если посмотреть на первые коммиты, то Detekt изначально не имел ничего общего с Gradle — он создавался просто как CLI. И до сих пор его можно использовать без Gradle. Без Gradle будет геморойнее настроить работу, но зато не будем тратить время на конфигурацию. Фишка в том, что весь плагин Detekt для Gradle сводится к тому, чтобы просто вызывать CLI-версию с информацией, которую мы прописываем через Gradle-плагин. Другими словами, плагин Detekt для Gradle — это просто платформа, которая скачивает CLI и затем его вызывает. Именно поэтому и получается такая странная инициализация: она позволяет изменять версию Detekt без изменения версии самого плагина. Когда мне нужно сделать плагин для Gradle для решения какой-то задачи, я сначала пытаюсь сделать обычный CLI. Его в разы проще разрабатывать, отлаживать и тестировать. А уже потом, если действительно нужна информация, доступная только Gradle (например, граф зависимостей или расположение исходников), я оборачиваю CLI в Gradle-плагин.

Первое место работы Первая работа как и первая любовь – вещи которые не забудешь никогда. Они почти всегда далеки от идеала, но эмоциональная отдача — максимальная. Я до сих пор помню свои ощущения, когда впервые зашел в офис своей первой компании. Для меня, тогда ещё "зелёного" студента, мечтающего попасть в IT, это была буквально дверь в Нарнию. Куча людей за компьютерами: кто-то пишет код, кто-то обсуждает задачи, кто-то проверяет стенды на стенах (о них чуть позже). Одного взгляда на всё это было достаточно, чтобы понять – я должен приложить все усилия, чтобы попасть сюда. Это была небольшая томская контора, которая делала медиакомплексы для автобусов и электричек. Те, кто живёт в Москве или Питере, возможно, даже замечали эти "телики", показывающие маршрут, погоду и новости. Многие думают, что это просто заранее записанное видео, но на самом деле всё устроено куда интереснее. Медиакомплекс — по сути, машина под Linux, на экране которой на польный экран открыт браузер. Браузер ходит на локальный сервер за данными, а тот через MQ связывается с сервером контента. Локальный бэк подключается к "материнскому кораблю", чтобы обновить информацию. Я пришёл туда на позицию полутестера–полуразработчика на Java. За год работы там было всё: 👉 Абсолютно безумный гендир, который раз в месяц залетал с идеями вроде: «А давайте сделаем приложение, чтобы пассажиры могли менять подсветку в автобусе». 👉 Самый саркастичный архитектор за всю мою карьеру — смысл советов которого до меня доходит только сейчас. 👉 Проектировщик интерфейсов, который вейпил, крутил спиннеры, делал свою настойку, и я клянусь — я ждал, когда он приедет в офис на гироскутере. 👉 Фронтендер с личным стилистом, который подкатывал ко всему, что движется. 👉 Тестировщик, который блять, оставил у себя Кольцо Всевластия, потому что вообще не стареет, и с которым мы каждый час ходили на турник. 👉 HR, которая при увольнении пугала тем, что занесёт в «чёрный список», и тогда тебя вообще больше нигде не возьмут на работу. 👉 Главный бухгалтер, которая в свои 40 лет выглядела так, что поднимала настроение (и не только) у всего мужского коллектива. И при всей своей всратости условий — я всё равно вспоминаю эту работу с какой-то ностальгической теплотой.

Итак, по поводу конкурса Я честное слово уже пишу нормальные технические посты, но в данный момент. Если вам нравится мой канал, то я попрошу вас мне слегка помочь. Вот что нужно сделать, подписаться на канал конкурса @tg_contest_main. К сожалению без этого никак, после окончания конкурса можете отписаться, как от канала конкурса, так и от меня, если я вас заебал) После того, как подпишетесь в этой форме проставьте галочку напротив моего канала. Буду невероятно признателен ❤️

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

Итак, конкурс. Я решил поучаствовать в конкурсе авторских Telegram-каналов. Правила в нём – как в бойцовском клубе, только ровно наоборот. Первое правило: рассказать всем об этом конкурсе. Поэтому вот тут подробности. Вот тут – главный канал конкурса: @tg_contest_main (в котором и будет происходить вся туса). Посмотрим, что из этого выйдет. Если и факапиться – то хотя бы на большую аудиторию)

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

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

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

Итак, я навайбкодил себе синтаксический анализ кода 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, вероятнее всего заменит :)

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

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

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

Пару лет назад, когда я только пришёл в команду инфры, одной из первых задач было перевести одного бота в кубер. Потому что у нас в компании все мелкие сервисы как раз активно туда переезжали. И я тогда вёл забавный дневник, который назвал: "Путешествие мобильщика в мире куберов". Погнали: 👉 Поставили задачу перевести 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. Пробую деплой. Успешно. Приложение запустилось. 👉 Пробую отправить запросы. Запросы уходят в пустоту – происходит целое нихера. 👉 Понимаю: срочно нужны логи. Внедряю логирование. Деплой успешный. Пытаюсь найти логи – логов нет! 👉 Теряю надежду, хочется плакать. Читаю доку ещё раз. Проверяю "чистилище" для неправильных логов – да, они, разумеется, тут. 👉 Логи есть. Отлично. Понимаю, где ошибка в обработке запроса. Чиню. 👉 Делаю пробные запросы. Аллилуйя – всё работает.

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

Когда делать рефакторинг? Вопрос от подписчика. Кстати, если у вас есть интересные вопросы для разбора, можете писать в личку канала. Я не буду рассказывать про конкретные методы рефакторинга — об этом есть куча статей и книг. Просто поделюсь тем, как обычно подходят к этому процессу в некоторых командах, в которых я работал. В разработке главное противостояние — между бизнесом и разработчиками. Бизнесу важно сделать как можно больше фич, чтобы захватить больше рынка, а разработчикам нужно, чтобы писать код было комфортно, в том числе с использованием новых технологий. Если произойдет перекос в любую из сторон, будет жопа. Если перекос в сторону бизнеса, стоимость внедрения фич улетит в космос. Если победит разработка, мы будем бесконечно рефакторить код что сделать идеально, спорить о важности SOLID и переписывать всё на новые UI-фреймворки. Важно соблюдать баланс. Поэтому для проведения рефакторинга нужны четкая цель и причина. Нужны метрики, по которым будет понятно, что рефакторинг необходим. Например: График времени выполнения похожих задач — если он растет, значит, что-то не так с техдолгом. Не всегда это можно отследить, поэтому могут быть чисто технические метрики: 👉 Архитектурные ограничения — из-за текущей архитектуры мы не можем использовать что-то, кроме UI-тестов. Метрика: количество не-UI тестов. 👉 Отсутствие навигации — из-за этого онбординг новых разработчиков занимает дни, а код-ревью превращается в хаос. Метрика: время на ревью, время онбординга. 👉 Ненадежные тесты — текущая библиотека для тестов сильно флакает. Метрика: количество флакающих тестов. Это если мы говорим про рефакторинг, который идет от разработки. Но иногда он может идти сверху: "У нас в компании обновилась библиотека для полей — нужно перейти на новую версию для консистентности UI." Короче, для действительно нужного рефакторинга важны: 👉 Четкая цель 👉 Измеримые метрики 👉 Минимальный roadmap (как внедрять изменения постепенно) Как именно проводить рефакторинг — зависит от задачи и конкретной ситуации в проекте. Есть вот такой доклад пятилетней давности на эту тему. Насколько помню, в нём было много крутых советов.