Данфа

Six-seven в архитектуре ПО

Если вы родитель школьника или просто иногда заходите на YouTube Shorts, вы слышали этот звук. «Six-seven!» (шесть-семь). Выкрик без смысла, сопровождаемый характерным жестом взвешивания невидимых гантелей.


На вопрос «Как дела?» — шесть-семь. «Какая оценка?» — шесть-семь. Это идеальный ответ эпохи постиронии. И чем дольше я смотрю на релизы современных JavaScript-фреймворков в 2026 году, тем больше понимаю: они работают по тому же принципу.

Что такое синдром «Шести-Семи» в разработке?


В мире разработки софта есть понятие Overengineering (избыточное проектирование). Это когда для создания простого списка покупок пишется микросервисная архитектура на Kubernetes, настраивается CI/CD пайплайн и внедряются нейросети для предсказания того, какой хлеб вы купите завтра.

Мем «six-seven» стал идеальным символом этого явления. Разработчики крупных библиотек добавляют функции не потому, что их просили пользователи, а потому что:
  1. Нужно выпустить мажорную версию (v2.0 звучит лучше, чем v1.9).
  2. Главный архитектор посмотрел доклад на конференции и решил, что теперь мы будем писать всё только через «реактивные сигналы четвертого поколения».
  3. Конкурирующая библиотека добавила это, значит, нам тоже надо.

Смысла столько же, сколько в выкрике подростка на уроке алгебры при виде цифр 6 и 7, но шума очень много.

Примеры из реальной жизни бэкенда и фронтенда



1. PHP против Node.js: Весы Скарамуччи
Помните времена, когда PHP был просто языком для сайтов? Теперь у нас есть асинхронные серверы на ReactPHP, Fibers и Swoole. Мы пытаемся заставить синхронный язык танцевать танец асинхронности.
Зачем? Чтобы ответить на API-запрос за 5 миллисекунд вместо 15. В итоге сложность поддержки кода возрастает экспоненциально. Когда заказчик спрашивает: «Зачем нам эта магия внутри сайта-визитки?», разработчик просто разводит руками, делает жест ладонями вверх-низ и шепчет: «Six-seven...». Потому что архитектурной необходимости в этом ноль, зато профиль на GitHub выглядит красиво.

2. Фронтенд-библиотеки: Тикток-рефакторинг
Каждые полгода выходит новый стандарт управления состоянием. Сначала все любили Redux. Потом MobX. Затем Vuex. Потом Pinia. Сейчас Zustand или Jotai.
Каждая новая библиотека позиционируется как убийца предыдущей. Но если посмотреть на код серьезного приложения, написанного пять лет назад, он работает до сих пор. А приложение, переписанное на ультрамодный стейт-менеджер месяц назад, уже требует обновления зависимостей, ломающих билд.
Это классический «six-seven»: громкий возглас о том, что старая технология мертва, хотя она просто тихо делала свою работу.

3. AI-first разработка: Нейросеть пишет "сикс-севен" код
Теперь к нашим баранам добавились большие языковые модели. Я прошу GigaChat написать функцию сортировки. Он выдает мне шедевр на 200 строк с использованием паттернов проектирования, названных в честь древнегреческих богов.
Я спрашиваю его: «Почему так сложно?».
А он отвечает голосом цифрового философа: «Эта реализация обеспечивает масштабируемость и инверсию зависимостей».
По факту — six-seven. Обычный usort отработал бы быстрее и понятнее, но где тут место для магии искусственного интеллекта?

Почему мы на это ведемся?


Маркетологи корпораций (от Wildberries, продающего футболки с надписью «67», до разработчиков фреймворков) знают одну истину: людям скучно.
  • Стабильность продается плохо. Никто не пойдет на конференцию слушать доклад «Мы ничего не меняли три года, и всё стабильно».
  • Хайп продается отлично. Выход версии «Quantum Reactive Streams Pro» вызывает бурю аплодисментов, даже если под капотом там старый добрый цикл событий.

Для подростков мем «six-seven» — это способ уйти от ответа взрослого.
Для разработчиков новые фреймворки — это часто такой же способ уйти от решения реальных бизнес-задач. Зачем чинить баг в легаси-коде, если можно потратить неделю на миграцию проекта с одной реактивной библиотеки на другую, визуально идентичную?

Как перестать быть жертвой «Six-Seven»-архитектуры?


Прежде чем внедрять новую технологию в свой продукт-проектирование-и-шаблоны-сайта.рф, задайте себе два вопроса:
  1. Решает ли это проблему пользователя? Если нет, то это pure six-seven.
  2. Кто будет это поддерживать в 3 часа ночи? Если ответ «никто», возможно, стоит остаться на проверенном решении.

Иногда лучший код — это тот, который просто работает. Без квантовых вычислений, блокчейна в базе данных пользователей и обязательных криков «Шесть-семь!» при каждом коммите.
Автор:  2 часа назад