Знаете, я тут недавно поймал себя на странной мысли: мне реально нравится работать с легаси-проектами. И нет, меня не подменили.

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

А потом начинается реальность. Ты сидишь и думаешь: как правильно спроектировать эту фичу, которую еще никто не использовал? Какая структура БД будет оптимальной для кейсов, которые мы еще даже не знаем? А вдруг через полгода всё придется переписывать, потому что не учли какой-то важный сценарий?

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

А вот легаси... Вот где магия.

Да, открываешь такой проект – и там хаос. Функция на 500 строк с тремя уровнями вложенных циклов. Бизнес-логика размазана между контроллером, сервисом и каким-то вспомогательным модулем. Запрос к базе, который считает что-то через жопу и работает по 3 секунды. Переменная с названием temp2_new_final_REALLY_USE_THIS.

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

И вот тут начинается кайф. Ты видишь узкое место – переписываешь кусок кода. Сразу можешь прогнать тесты (которые уже есть!), посмотреть на мониторинг, получить обратную связь. Нашел странную логику – разбираешься, почему так сделали, и часто оказывается, что это решает какой-то граничный случай, о котором ты бы в новом проекте даже не подумал.

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

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

Так что да, я теперь тот странный разраб, который радуется легаси-проектам 🙂

В проекте появляется файл CODEOWNERS, и все думают: «Ура, наконец-то порядок! Теперь никто не сломает критичную логику!»

Прописываем владельцев для каждой папки. Настраиваем обязательные проверки. Теперь любое изменение в платежах должен одобрить Вася, а в авторизации – Петя. Безопасность! Контроль! Качество!

А потом начинается реальность.

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

И самое смешное – когда владелец наконец-то смотрит твой код, он часто просто ставит галочку. Потому что у него своих задач выше крыши, он не погружался в контекст, и честно говоря, он просто верит, что ты не накосячил.

Вот тут я понял: CODEOWNERS – это не про код. Это про людей.

Файл не защищает от багов. Он не сделает код лучше магическим образом. Он не заменит нормальное ревью. Он просто создает точку синхронизации между людьми.

И есть два способа его использовать.

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

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

Я видел проекты, где CODEOWNERS превратился в проблему. Каждый владелец стал узким местом. Люди начали обходить систему – делать коммиты в обход, просить "просто апрувни, я сам проверил".

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

А еще видел проекты, где CODEOWNERS вообще нет. И знаете что? Они прекрасно работают. Команда просто сама договаривается, кого позвать на ревью критичных изменений. Без формальных правил, без обязательных блокировок. Просто на доверии и здравом смысле.

Так что если собираетесь добавлять CODEOWNERS в проект – сначала подумайте не про файл, а про команду. Есть ли у вас люди, которые реально готовы быть владельцами? Хватит ли у них времени? Доверяете ли вы остальным разработчикам настолько, чтобы не требовать аппрувы на каждый чих?

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

Яндекс оказывается обновил систему найма и сделал это не плохо.

Но в такой уравниловке безусловно есть и проблемы.

https://habr.com/ru/companies/yandex/articles/959986/

Всех с пятницей и рабочей субботой :)

#пятничныйюмор

Тут балуюсь с оптимизацией сборки Next.js приложения, при сборке docker образа, отжирается 50 гигов. Самое приложение, меньше гига.

Люблю фронтенд.

После оптимизации удалось добавиться увелечение только на 6 гигабайт, после окочания джобы + 1 гиг на кэш.

#cicd #nexjs #reacr

Вышла GPT5.1. Как всегда быстрее, лучше, умнее.

Я пока сильно разницы не заметил, кроме скорости.

Так же появилась кастомизация «стиля» ответа.

#openai #chatgpt #gpt5.1

Сижу готовлюсь к выступлению, остался час.

Буду рассказывать о GitOps, и как методология может помочь аналитикам и командам.

#analystdays #ad21

Сейчас слушаю доклад, как внедрили ИИ в подбор.

Там прям классная и очень правдивая мысль — за последние 5 лет вопросы, которые можно найти в статье на Хабре «Топ 50 вопросов к системному аналитику», как задавали, так и задают.

Первый вопрос, который задают, — чем отличается POST от GET? Конечно же вопрос на позицию не меньше Senior.

#собесы

Ехал на закрытие Analyst Days 21 с полной уверенностью, что хорошо выступил, но совсем не ожидал что мой доклад займет третье место. 🥉

Понадобилось три конференции и два года что бы повторить результат весны 2023 (AD 19)

Это мотивируют выступать еще больше, ещё качественней (благо есть куда расти).

Докладчики-победители Analyst Days #21
🥇1 место — Аня Гурова
🥈2 место — Аня Казаченко
🥉3 место — Лев Немировский

Языку Go сегодня 16 лет. Из,наверное, самых классных функций последнего времени - это новый сборщик Green Tea, который пока в бета.

Причем не верится в такую дату, честно говоря. Помню как смеялись, когда требование в вакансиях было 5 лет, а языку 2-3 года. Прям себя сильно олдом почувствовал.

#go #golang