Hacker News Digest

Дублирование часто дешевле, чем попытка создать «правильное» обобщение. На RailsConf 2014 я говорил: «дублирование намного дешевле неправильного абстракции», что отразилось в твите «Duplication is far cheaper than the wrong abstraction» (41 shades of blue, март 2014). Когда в коде появляется повтор, разработчик вытаскивает его в метод или класс, получая новую абстракцию. Со временем к ней добавляются параметры и условия, чтобы покрыть новые требования, и код превращается в запутанный набор ветвлений. При этом сохранение такой конструкции подпитывается эффектом удержания вложенных усилий — «sunk‑cost fallacy» заставляет считать, что сложный код обязателен и важен.

Чтобы выйти из ловушки, лучше отменить прежнее решение. Нужно вернуть дублирование, заменив вынесённый метод на его тело в каждом месте вызова, а затем оставить только те части, которые действительно нужны конкретному вызывающему. Удаляя лишние ветви, вы избавляетесь от условных параметров и получаете чистый код, который легко расширять. Такой «откат» часто раскрывает, что исходная абстракция была избыточной, и позволяет заново выделить более подходящие обобщения. Главное – не позволять заложенным усилиям удерживать плохой дизайн.

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

Чтобы ускорить процесс получения услуг у регулируемой монополии, где падение удовлетворённости ниже 96 % грозит миллионами штрафов, команда решила заменить устаревший ASP‑форму и дорогой React‑приложение на полностью HTML‑ориентированный сайт. Используя Astro, они построили сайт, где каждая стадия формы — отдельная страница, отправляемая на сервер, а данные сохраняются в базе. Такой подход позволил работать без JavaScript, поддерживать древние браузеры и сохранять ввод даже при плохом соединении. Результат — количество пользователей мгновенно удвоилось.

Ключевой принцип — «простое HTML работает везде». Как отмечает Теренс Эден, даже браузеры типа PSP, способные открыть лишь три вкладки и часто терять память, без проблем отображают страницы GOV.UK, написанные в лёгком HTML. Команда использовала кастомные веб‑компоненты, которые перехватывают стандартную валидацию браузера, выводят ошибки в aria‑describedby и очищают их при вводе, избегая тяжёлых React‑валидаторов. Доступность достигла уровня AA, а всё приложение оставалось лёгким: без 20 МБ JavaScript‑пакетов, только небольшие улучшения в виде CSS и минимального скрипта. Это показывает, что для публичных форм достаточно чистого HTML и грамотного серверного хранения, а современные фреймворки лишь дополняют, а не заменяют базовый веб‑технологический фундамент.

• Простой HTML‑first подход с минимальным JavaScript может значительно повысить доступность и производительность сайтов.
• Использование технологий вроде HTMX и серверных фреймворков (Go, Rails, Django) позволяет реализовать сложные функции без тяжёлых клиентских библиотек.
• Проблемы с поддержкой старых браузеров и устройств часто решаются через полифиллы, ограничение функционала и fallback‑варианты.
• Успешные кейсы показывают, что правильный дизайн и понимание пользователей важнее выбора конкретного фреймворка.

Автор рассказывает, как он создал свой собственный класс AppVersion для сравнения версий, но затем обнаружил, что в Ruby уже есть встроенный Gem::Version, который делает то же самое, но лучше. Он заменил свой класс на встроенный и призвал сообщество делиться знаниями, чтобы избежать изобретения велосипедов.

• Участники восхищаются элегантностью и лаконичностью Ruby, особенно в реализации классов вроде AppVersion, и отмечают его выразительность по сравнению с TypeScript, Elixir и другими языками.
• Подчеркивается мощь метапрограммирования Ruby и его роль в развитии любви к программированию, хотя есть критика по поводу документации и экосистемы.
• Сравниваются реализации AppVersion в других языках (Python, Java, Scala), где признается сходство в выразительности, но отмечаются различия в синтаксисе и подходах.
• Упоминается ностальгия по Rails и его современное состояние, а также скрытые возможности стандартной библиотеки Ruby.
• Есть критика Ruby за "скрытые опасности" (footguns) и проблемы с масштабированием, а также за то, что экосистема Rails затмевает сам язык.

Разработчик сравнивает несколько популярных фреймворков и объясняет, почему выбрал Phoenix LiveView. Вместо того чтобы разделять фронтенд и бэкенд на разные стеки, он нашёл решение, которое позволяет писать всё на одном языке — Elixir. Это не только ускоряет разработку, но и даёт серьёзные преимущества в производительности.

Ключевые моменты:

• Меньше кода, меньше ошибок: Вместо двух кодовых баз (например, JavaScript + PHP) всё пишется на Elixir, включая UI-логику, что снижает вероятность ошибок.
• Реальное время без усилий: LiveView использует WebSockets для двухсторонней связи в реальном времени, что встроено "из коробки" и не требует дополнительных библиотек.
• Производительность и надёжность: Бэкенд на Elixir (работающем на Erlang VM) обеспечивает высокую конкурентность и отказоустойчивость. Фоновые задачи через Oban перезапускаются автоматически при сбоях.
• Единая архитектура: Нет необходимости в отдельном API или SPA, что упрощает разработку и развертывание.

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

• Обсуждение в основном вращается вокруг сравнения Rails, Phoenix и LiveView, но при этом всплывают факты, что Rails всё ещё умеет WebSocket, а Phoenix не так уж идеален, если нужен только CRUD-приложение.
• Участники спора подчеркивают, что выбор стека часто диктуется личными предпочтениями и опытом, а не объективными преимуществами.
• Несколько раз поднимается тема, что современные фреймворки всё ещё не решают проблему масштабирования и фоновых задач, и что важнее выбрать тот стек, который действительно подходит под задачу.
• Также обсуждается, что выбор инструмента влияет на набор библиотек и сообщество вокруг него, и это может быть важнее, чем абстрактные преимущества языка.

Разрабатывайте самое простое, что только может работать.
Это правило годится и для исправления багов, и для новых систем.

Многие инженеры мечтают о «идеальной» архитектуре: масштабируемой, распределённой, красивой. Это ошибка. Лучше глубже понять текущую систему и сделать самое простое решение.

Простое может выглядеть скучно
Джуны любят рисовать сложные схемы из кэшей, очередей, прокси. Настоящее мастерство — уметь делать меньше. Великий дизайн выглядит тривиально: «О, задача оказалась простой».
Unicorn и стандартный Rails REST API — примеры: всё нужное достигается очевидными средствами.

Практика
Нужно ограничение частоты запросов в Go-сервисе?

• Вариант 1: Redis + алгоритм «протекающего ведра».
• Вариант 2: счётчики в памяти (теряются при рестарте).
• Вариант 3: включить rate-limit в edge-прокси одной строкой конфига.
  Если последнее покрывает требования — выбирайте его.

Развивайте продукт, начиная с минимума и усложняя только по новым требованиям. Это YAGNI как высший принцип.

Возражения

1. Слякоть из костылей
   Костыль не прост — он добавляет сложности. Настоящее простое решение требует понимания всей системы и часто сложнее придумать.

2. Что такое «просто»?
   Простота — это минимум сущностей, минимум переходов, минимум новых инструментов. Она не всегда очевидна и требует инженерной работы.

3. Масштабирование
   Простое не значит «только сейчас». Unix-сокеты, CGI, файлы — примитивы, на которых построены крупные системы. Если завтра потребуется масштаб, выясните новые факты и добавьте минимально необходимое.

Делайте самое простое, что только может работать — и будете удивлены, как далеко это вас заведёт.

• Участники сходятся в том, что «делай самое простое, что может работать» — полезная эвристика, но не универсальный закон.
• Опытные разработчики подчеркивают: простота ≠ легкость; требует глубокого понимания задачи и контекста.
• На больших системах «простое» быстро ломается из-за edge-case’ов и масштаба, поэтому часто приходится усложнять.
• Частая ошибка — проектировать «на вырост»: реакт, k8s и прочее для сайта из трёх страниц, лишь бы «в портфолио».
• Самый практичный совет: фиксируй реальные требования здесь и сейчас и строй под них, а не под гипотетическое будущее.