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

Не ней расположены ожидания даты появления 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-знакомства в течении недели и вот, что я понял!

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

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

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

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

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

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

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

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

Первое место работы

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

Для меня, тогда ещё "зелёного" студента, мечтающего попасть в IT, это была буквально дверь в Нарнию. Куча людей за компьютерами: кто-то пишет код, кто-то обсуждает задачи, кто-то проверяет стенды на стенах (о них чуть позже). Одного взгляда на всё это было достаточно, чтобы понять – я должен приложить все усилия, чтобы попасть сюда.

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

Медиакомплекс — по сути, машина под Linux, на экране которой на полный экран открыт браузер. Браузер ходит на локальный сервер за данными, а тот через MQ связывается с сервером контента. Локальный бэк подключается к "материнскому кораблю", чтобы обновить информацию.

Я пришёл туда на позицию полутестера–полуразработчика на Java. За год работы там было всё:

👉 Абсолютно безумный гендир, который раз в месяц залетал с идеями вроде: «А давайте сделаем приложение, чтобы пассажиры могли менять подсветку в автобусе».
👉 Самый саркастичный архитектор за всю мою карьеру — смысл советов которого до меня доходит только сейчас.
👉 Проектировщик интерфейсов, который вейпил, крутил спиннеры, делал свою настойку, и я клянусь — я ждал, когда он приедет в офис на гироскутере.
👉 Фронтендер с личным стилистом, который подкатывал ко всему, что движется.
👉 Тестировщик, который блять, оставил у себя Кольцо Всевластия, потому что вообще не стареет, и с которым мы каждый час ходили на турник.
👉 HR, которая при увольнении пугала тем, что занесёт в «чёрный список», и тогда тебя вообще больше нигде не возьмут на работу.
👉 Главный бухгалтер, которая в свои 40 лет выглядела так, что поднимала настроение (и не только) у всего мужского коллектива.

И при всей своей всратости условий — я всё равно вспоминаю эту работу с какой-то ностальгической теплотой.

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-плагин.

Итак, сплав

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

Как это присходит: мы летим в Пермь в четверг, затем в пятницу утром мы грузимся в автобус и фигачим 4-5 часов в глушь. После берем свои вещи, упаковываем в гермомешки, грузим их на плоты и гребем по реке до вечера. Если вы работали в аутсорсе, для вас ничего необычного.

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

Утром грузимся, плывем до обеда. Доплываем до места, где нас забирает автобус, и едем обратно в Пермь. Если повезет даже без солнечных ожогов, пневмонии и укусов клеща.

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

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

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

Третье: мы заспидранили сплав, закончив его на второй день, вместо третьего. На справе было слишком много эффективных менеджеров. От такого мува ахуели все, особенно организаторы...

В итоге активность 10/10, но не рекомендую если вы в своем уме)

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

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

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

Истории с собесов:
👉 Самый забавный собес в моей карьере
👉 Собес в Авито
👉 Собес в Aliexpress
👉 Советы по прохождению алго-секции
👉 Как уменьшить волнение перед собесом

Истории и рофлы:
👉 Мой каминг-аут
👉 Про первое место работы
👉 Как я попал в инфру
👉 Какого это работать в БигТехе
👉 Приключения мобильного разраба в мире инфры

Для любителей сериалов:
👉 Про CI
👉 Про тесты
👉 Про DI

Немного базы про разработку:
👉 База программирования в одном посте
👉 Советы, как не проебаться в работе
👉 Как я навайбкодил синтаксический анализ
👉 Оцениваем сроки
👉 Что такое архитектура
👉 Разгоняем про логи
👉 В IT нет научного подхода

Boost канала для неравнодушных