Да, написать изолированный кусок кода для одной функции — это сейчас идеальная задача для любой LLM.
Но тут есть пара нюансов:
Проблема микросервисов никогда не была в написании кода одного сервиса. Главная боль — это распределенные транзакции, разрыв сети, консистентность данных и распределенный трейсинг. LLM еще очень плохо понимают архитектуру всей системы целиком и то, как эти 50 «идеально написанных» кусочков будут общаться между собой в проде под нагрузкой.
Если сейчас больно искать, где потерялся спан в трейсе из десятка сервисов, написанных людьми, то представьте, каково будет дебажить логику, которую нагенерили агенты без единого архитектурного видения.
Учитывая, что у новых моделей окна контекста уже пробивают 1-2 миллиона токенов, ограничение «маленького контекста» — это временно (хочется в это верить). Скоро скормить LLM-ке хорошо структурированный модульный монолит будет даже выгоднее: она будет видеть всю предметную область разом, а не пытаться угадать контракты соседнего сервиса.
Так что, с точки зрения написания — да, проще. А вот с точки зрения поддержки всей инфраструктуры — LLM могут этот «налог на микросервисы» только увеличить, генерируя их десятками там, где хватило бы одного модуля.
И мечты бьются о суровую выборку... Рынок так долго премировал за знание «модно-молодёжных» технологий, что найти того, кто понимает, почему один JOIN лучше десяти сетевых вызовов, сегодня труднее, чем архитектора с сертификатом AWS.
Немного выше @Wesha открыл хорошую коробочку, рекомендую посмотреть.
А если коротко от себя:
Санировать ввод - прекрасная мысль. А вот захардкодить в схему БД ограничение «только Россия и только 10 цифр» – это классический legacy-капкан.
Ваше решение намертво привязывает бизнес к одной стране. Что произойдет, когда к вам придет клиент из Беларуси (+375) или Узбекистана (+998)? База с ограничением в 10 символов просто не даст ему зарегистрироваться.
Да и любой адекватный SMS-шлюз работает по международному стандарту E.164 (до 15 цифр, начиная с +). Если вы отрезали код страны, вам придется хардкодить +7 обратно при каждом обращении к API провайдера.
Здравствуйте! Отличный рефлекс – думать о защите ПДн. Но остаются проблемы:
При утечке БД такой алгоритм разгадают за 5 минут, и от штрафов регуляторов (например, по 152-ФЗ) это самописное решение не спасет. Нужна реальная криптография, а там в любом случае необходимо хранить строку (могу ошибаться, в криптографии не силен).
Ваш кейс идеально подтверждает статью: вы выбрали INT именно ради математики, и это сразу всё сломало. 0306 + 1111 = 1417, а 306 + 111 = 417. Без отдельного хранения длины ключа вы не сможете расшифровать данные обратно. И тут начинается усложнение.
Что делать при переполнении разрядов с серией 0999? 999 + 1111 = 2110.
Представления отличный инструмент. Но зачем изначально создавать себе проблему на уровне хранения (терять данные), чтобы потом героически её решать через View? База должна хранить консистентные факты.
Что касается изменения форматов в будущем: если МВД добавит пятую цифру, букву или дефис, тип CHAR или VARCHAR мигрировать/расширить гораздо проще. А вот если вы заложились на INTEGER, то при появлении букв ваша схема просто ляжет с ошибкой типизации.
Единственный "исход", который я ожидаю – что разработчик умеет думать о природе данных.
Расскажите, в каком таком контексте потеря данных (ведущего нуля) – это не баг, а допустимый недостаток, у которого есть свои "преимущества"? Экономия 2 байт на жестком диске в обмен на невалидные паспорта пользователей? Отличный трейд-офф, заверните два.
Вы предлагаете классический антипаттерн – размазать ответственность за целостность данных тонким слоем по фронтенду или бизнес-логике. База данных должна хранить сам факт (идентификатор), а не математическую абстракцию, которую нужно каждый раз "собирать" костылями.
Представьте: завтра к этой базе подключается новый микросервис, BI-система для аналитики или понадобится сырая выгрузка в CSV. Каждому новому клиенту придется заново писать этот костыль с подстановкой нулей. А если кто-то забудет это сделать? Данные разъедутся. База должна гарантировать консистентность: положили строку – достали строку.
Спасибо за перевод и очень точный диагноз! Особенно мысль о том, что ИИ просто подсветит тех, кто не умеет «водить эту штуку».
Я в своей книге как раз препарирую этот феномен. Индустрия годами поощряла разработчиков собирать продукты из готовых черных ящиков ради быстрого Time-to-Market. Выросло целое поколение специалистов, которые виртуозно перекладывают JSON из одного API в другое, но совершенно не понимают, как работает память, сеть и железо под капотом. Именно их и заменит ИИ. Потому что нейросеть уже сейчас перекладывает формочки и пишет бойлерплейт дешевле и быстрее. А вот для инженеров, которые умеют считать байты, понимают цену абстракций и строят архитектуру, ИИ станет просто экскаватором вместо лопаты. Пропасть станет огромной.
Вы очень точно подметили про "иллюзию простоты". Никто не призывает возвращаться к ручному управлению памятью везде и всюду, но вот эта потеря связи между "написал строчку" и "понял, что произошло под капотом" действительно пугает. Рад, что мы на одной волне!
Секрет в том, что бизнесу (или "кабанычу") не нужно продавать "красивую архитектуру". Ему нужно продавать метрики и деньги. Если фича, написанная за 1 день, заставляет приложение тормозить на бюджетных Android-смартфонах, конверсия падает, и бизнес теряет деньги. Плюс, не отдавать на фронт всю таблицу из БД вместе с техническими и неиспользуемыми на клиенте полями – это не N дней работы, это просто грамотно написанный DTO/сериализатор, который пишется за те же 15 минут, но экономит мегабайты.
Именно) JSON – прекрасный инструмент. Формат ни в чем не виноват. Виновато отношение, при котором "раз это текст и он гибкий, значит можно запихивать в него вообще всё подряд без разбора, фронтенд сам отфильтрует". Об этом и речь.
Микрооптимизации и переписывание на Rust ради 5мс без бизнес-цели – это зло. Но в статье речь не о преждевременной оптимизации, а о базовой инженерной гигиене. Спроектировать API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн. Чинить это потом, когда база ляжет от рекурсивных джойнов, а клиенты начнут жаловаться на лаги – обойдется бизнесу в десятки раз дороже.
Gzip действительно отлично жмет повторяющиеся ключи в JSON, и реальный egress-трафик будет меньше 'сырых' мегабайтов. Но проблема в том, что уникальные текстовые данные, вложенные структуры и избыточные метаданные (те же длинные токены, id и лишние base64) сжимаются хуже. К тому же, чем больше мы сэкономили на трафике за счет gzip, тем больше тактов CPU смартфона мы сожжем на декомпрессию этого "жира" перед тем, как отдать его парсеру. Так что за мусорные данные мы всё равно платим: либо рублями провайдеру, либо батареей пользователя.
Вы правы в деталях механики. Парсингом действительно занимается JS-движок (Hermes/V8). Но проблема возникает как раз на стыке: когда нам нужно прокинуть этот огромный массив данных для рендера списков на нативную сторону. В старой архитектуре это приводило к сериализации/десериализации при переходе через мост. В новой JSI (которую я упоминаю) это решается ссылками на C++ объекты, но аллокация огромного количества памяти под "мусорные" поля из ответа всё равно нагружает GC и съедает ресурсы процессора.
Спасибо за интерес! Да, конечно. Напишите мне в личку здесь или в Telegram (ссылка в профиле) — договоримся, как это лучше организовать, с радостью подпишу.
Сегодня сам получил печатный экземпляр, проверял как сервис печати по требованию работает. В целом неплохо.
Спасибо за комментарий! Вы правы: писать сложный интерактивный SPA в большой команде на ванильном JS или jQuery – это выстрел в ногу. Это будет стоить дорого и быстро превратится в легаси.
Пример с «Hello World» – это намеренная гипербола, чтобы подсветить базовый оверхед, который современный стек тянет за собой.
Как я и отмечаю в статье: фреймворки отлично дают архитектурный каркас для большой команды. Боль в другом – сейчас этот тяжелый стек начали тащить по дефолту вообще везде: в статичные лендинги, простые блоги и визитки. Фреймворк перестал быть осознанным решением под уровень задачи.
Интересно ваше мнение: где, по-вашему, сейчас проходит адекватная граница применимости того же Next.js? С какого масштаба проекта он начинает полностью окупать свой вес?
Абсолютно согласен. Экосистема React не позволяет написать код «один раз и навсегда». Я сам участвовал во вскрытии такого легаси: мобильное приложение известного ТЦ на юге РФ, написанное на React Native.
Приложение спокойно жило и работало годами, пока не вышел очередной апдейт iOS, сломавший всё. Чтобы просто заставить этот "современный" стек запуститься, нужно было мигрировать через 3 мажорные версии и разгрести ад зависимостей. Бизнес посмотрел на смету работ и просто похоронил приложение.
Вы правы: цена поддержки такого кода космическая, потому что ты платишь не за новые фичи, а за то, чтобы старый код просто компилировался.
А где я их жалею? При прочих равных, поисковик лучше индексирует сайт с SSR, а не SPA.
Ни Гугл, ни Яндекс не раскрывают своих алгоритмов поискового продвижения, все познается эмпирическим путем. И за эти знания спасибо моей команде прекрасных специалистов💪
Да, написать изолированный кусок кода для одной функции — это сейчас идеальная задача для любой LLM.
Но тут есть пара нюансов:
Проблема микросервисов никогда не была в написании кода одного сервиса. Главная боль — это распределенные транзакции, разрыв сети, консистентность данных и распределенный трейсинг. LLM еще очень плохо понимают архитектуру всей системы целиком и то, как эти 50 «идеально написанных» кусочков будут общаться между собой в проде под нагрузкой.
Если сейчас больно искать, где потерялся спан в трейсе из десятка сервисов, написанных людьми, то представьте, каково будет дебажить логику, которую нагенерили агенты без единого архитектурного видения.
Учитывая, что у новых моделей окна контекста уже пробивают 1-2 миллиона токенов, ограничение «маленького контекста» — это временно (хочется в это верить). Скоро скормить LLM-ке хорошо структурированный модульный монолит будет даже выгоднее: она будет видеть всю предметную область разом, а не пытаться угадать контракты соседнего сервиса.
Так что, с точки зрения написания — да, проще. А вот с точки зрения поддержки всей инфраструктуры — LLM могут этот «налог на микросервисы» только увеличить, генерируя их десятками там, где хватило бы одного модуля.
И мечты бьются о суровую выборку... Рынок так долго премировал за знание «модно-молодёжных» технологий, что найти того, кто понимает, почему один JOIN лучше десяти сетевых вызовов, сегодня труднее, чем архитектора с сертификатом AWS.
Немного выше @Wesha открыл хорошую коробочку, рекомендую посмотреть.
А если коротко от себя:
Санировать ввод - прекрасная мысль. А вот захардкодить в схему БД ограничение «только Россия и только 10 цифр» – это классический legacy-капкан.
Ваше решение намертво привязывает бизнес к одной стране. Что произойдет, когда к вам придет клиент из Беларуси (+375) или Узбекистана (+998)? База с ограничением в 10 символов просто не даст ему зарегистрироваться.
Да и любой адекватный SMS-шлюз работает по международному стандарту E.164 (до 15 цифр, начиная с +). Если вы отрезали код страны, вам придется хардкодить +7 обратно при каждом обращении к API провайдера.
Здравствуйте! Отличный рефлекс – думать о защите ПДн. Но остаются проблемы:
При утечке БД такой алгоритм разгадают за 5 минут, и от штрафов регуляторов (например, по 152-ФЗ) это самописное решение не спасет. Нужна реальная криптография, а там в любом случае необходимо хранить строку (могу ошибаться, в криптографии не силен).
Ваш кейс идеально подтверждает статью: вы выбрали INT именно ради математики, и это сразу всё сломало. 0306 + 1111 = 1417, а 306 + 111 = 417. Без отдельного хранения длины ключа вы не сможете расшифровать данные обратно. И тут начинается усложнение.
Что делать при переполнении разрядов с серией 0999? 999 + 1111 = 2110.
Представления отличный инструмент. Но зачем изначально создавать себе проблему на уровне хранения (терять данные), чтобы потом героически её решать через View? База должна хранить консистентные факты.
Что касается изменения форматов в будущем: если МВД добавит пятую цифру, букву или дефис, тип CHAR или VARCHAR мигрировать/расширить гораздо проще. А вот если вы заложились на INTEGER, то при появлении букв ваша схема просто ляжет с ошибкой типизации.
Отличное дополнение про иностранные и советские паспорта (возьму на вооружение в качестве дополнения, вопрос все же про паспорта РФ).
Это как раз тот самый «контрольный выстрел» в архитектуру, построенную на INTEGER.
Единственный "исход", который я ожидаю – что разработчик умеет думать о природе данных.
Расскажите, в каком таком контексте потеря данных (ведущего нуля) – это не баг, а допустимый недостаток, у которого есть свои "преимущества"? Экономия 2 байт на жестком диске в обмен на невалидные паспорта пользователей? Отличный трейд-офф, заверните два.
Вы предлагаете классический антипаттерн – размазать ответственность за целостность данных тонким слоем по фронтенду или бизнес-логике. База данных должна хранить сам факт (идентификатор), а не математическую абстракцию, которую нужно каждый раз "собирать" костылями.
Представьте: завтра к этой базе подключается новый микросервис, BI-система для аналитики или понадобится сырая выгрузка в CSV. Каждому новому клиенту придется заново писать этот костыль с подстановкой нулей. А если кто-то забудет это сделать? Данные разъедутся. База должна гарантировать консистентность: положили строку – достали строку.
Спасибо за перевод и очень точный диагноз! Особенно мысль о том, что ИИ просто подсветит тех, кто не умеет «водить эту штуку».
Я в своей книге как раз препарирую этот феномен. Индустрия годами поощряла разработчиков собирать продукты из готовых черных ящиков ради быстрого Time-to-Market. Выросло целое поколение специалистов, которые виртуозно перекладывают JSON из одного API в другое, но совершенно не понимают, как работает память, сеть и железо под капотом. Именно их и заменит ИИ. Потому что нейросеть уже сейчас перекладывает формочки и пишет бойлерплейт дешевле и быстрее. А вот для инженеров, которые умеют считать байты, понимают цену абстракций и строят архитектуру, ИИ станет просто экскаватором вместо лопаты. Пропасть станет огромной.
Вы очень точно подметили про "иллюзию простоты". Никто не призывает возвращаться к ручному управлению памятью везде и всюду, но вот эта потеря связи между "написал строчку" и "понял, что произошло под капотом" действительно пугает. Рад, что мы на одной волне!
Секрет в том, что бизнесу (или "кабанычу") не нужно продавать "красивую архитектуру". Ему нужно продавать метрики и деньги. Если фича, написанная за 1 день, заставляет приложение тормозить на бюджетных Android-смартфонах, конверсия падает, и бизнес теряет деньги. Плюс, не отдавать на фронт всю таблицу из БД вместе с техническими и неиспользуемыми на клиенте полями – это не N дней работы, это просто грамотно написанный DTO/сериализатор, который пишется за те же 15 минут, но экономит мегабайты.
Именно) JSON – прекрасный инструмент. Формат ни в чем не виноват. Виновато отношение, при котором "раз это текст и он гибкий, значит можно запихивать в него вообще всё подряд без разбора, фронтенд сам отфильтрует". Об этом и речь.
Микрооптимизации и переписывание на Rust ради 5мс без бизнес-цели – это зло. Но в статье речь не о преждевременной оптимизации, а о базовой инженерной гигиене. Спроектировать API так, чтобы он не отдавал клиенту пароли, внутренние ID базы и лишние 50 полей, которые не используются на экране – это не "наворот", это нормальный дизайн. Чинить это потом, когда база ляжет от рекурсивных джойнов, а клиенты начнут жаловаться на лаги – обойдется бизнесу в десятки раз дороже.
Gzip действительно отлично жмет повторяющиеся ключи в JSON, и реальный egress-трафик будет меньше 'сырых' мегабайтов. Но проблема в том, что уникальные текстовые данные, вложенные структуры и избыточные метаданные (те же длинные токены, id и лишние base64) сжимаются хуже. К тому же, чем больше мы сэкономили на трафике за счет gzip, тем больше тактов CPU смартфона мы сожжем на декомпрессию этого "жира" перед тем, как отдать его парсеру. Так что за мусорные данные мы всё равно платим: либо рублями провайдеру, либо батареей пользователя.
Вы правы в деталях механики. Парсингом действительно занимается JS-движок (Hermes/V8). Но проблема возникает как раз на стыке: когда нам нужно прокинуть этот огромный массив данных для рендера списков на нативную сторону. В старой архитектуре это приводило к сериализации/десериализации при переходе через мост. В новой JSI (которую я упоминаю) это решается ссылками на C++ объекты, но аллокация огромного количества памяти под "мусорные" поля из ответа всё равно нагружает GC и съедает ресурсы процессора.
Спасибо за интерес! Да, конечно. Напишите мне в личку здесь или в Telegram (ссылка в профиле) — договоримся, как это лучше организовать, с радостью подпишу.
Сегодня сам получил печатный экземпляр, проверял как сервис печати по требованию работает. В целом неплохо.
Не могу утверждать, но уверен, что сначала поисковые боты отрабатывают, а потом уже поверх собранных данных накручивается ИИ
Спасибо за комментарий! Вы правы: писать сложный интерактивный SPA в большой команде на ванильном JS или jQuery – это выстрел в ногу. Это будет стоить дорого и быстро превратится в легаси.
Пример с «Hello World» – это намеренная гипербола, чтобы подсветить базовый оверхед, который современный стек тянет за собой.
Как я и отмечаю в статье: фреймворки отлично дают архитектурный каркас для большой команды. Боль в другом – сейчас этот тяжелый стек начали тащить по дефолту вообще везде: в статичные лендинги, простые блоги и визитки. Фреймворк перестал быть осознанным решением под уровень задачи.
Интересно ваше мнение: где, по-вашему, сейчас проходит адекватная граница применимости того же Next.js? С какого масштаба проекта он начинает полностью окупать свой вес?
Абсолютно согласен. Экосистема React не позволяет написать код «один раз и навсегда». Я сам участвовал во вскрытии такого легаси: мобильное приложение известного ТЦ на юге РФ, написанное на React Native.
Приложение спокойно жило и работало годами, пока не вышел очередной апдейт iOS, сломавший всё. Чтобы просто заставить этот "современный" стек запуститься, нужно было мигрировать через 3 мажорные версии и разгрести ад зависимостей. Бизнес посмотрел на смету работ и просто похоронил приложение.
Вы правы: цена поддержки такого кода космическая, потому что ты платишь не за новые фичи, а за то, чтобы старый код просто компилировался.
А где я их жалею? При прочих равных, поисковик лучше индексирует сайт с SSR, а не SPA.
Ни Гугл, ни Яндекс не раскрывают своих алгоритмов поискового продвижения, все познается эмпирическим путем. И за эти знания спасибо моей команде прекрасных специалистов💪