Hacker News Digest

Автор, работая в быстро меняющемся стартапе, пришёл к выводу, что Google Sheets часто оказывается оптимальным решением для бизнес-задач. Он приводит три примера: двухмесячная разработка админ-панели для отслеживания грузов, трёхнедельное создание системы расчёта налогов и долгий поиск CRM — все эти проекты были заброшены, а их функции успешно выполнялись через таблицы. Ключевая идея: начинать с максимально простого решения (вроде Google Sheets), чтобы понять полный объём задачи, и только затем, если нужно, переходить к сложным инструментам. Это экономит время и силы, особенно в условиях неопределённости. Однако автор предупреждает: метод не универсален и подходит лишь там, где требования изначально не ясны.

• Spreadsheets объединяют базу данных, настраиваемый интерфейс и простую обработку данных в интуитивно понятном и доступном инструменте, позволяя быстро создавать решения.
• Они идеальны для прототипирования и временных решений, но часто становятся постоянными, что приводит к проблемам с поддержкой, версионностью и масштабируемостью.
• Существует разрыв между простыми инструментами вроде таблиц и полноценными приложениями, не хватает промежуточных решений с плавным пути миграции.
• Интеграция с AI (например, Gemini для генерации кода) и скриптами (Apps Script) значительно расширяет возможности таблиц, автоматизируя сложные задачи.
• Ключевой принцип — использовать простейшее решение для текущей задачи (YAGNI), избегая преждевременной оптимизации и сложных систем.

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

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

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

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

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

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

Возражения

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

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

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

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

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

• YouTube
  О проекте · Пресс-центр · Авторское право · Связаться · Авторам · Реклама · Разработчикам

• Правовые документы
  Условия · Конфиденциальность · Политика и безопасность

• Дополнительно
  Как работает YouTube · Тест новых функций · NFL Sunday Ticket

© 2025 Google LLC

• Участники критикуют догматизм докладчика: его тезисы «всё — API без внутренностей», «модули пишет один человек» и «C89 навсегда» выглядят слишком жёсткими и не универсальными.
• Подчёркивают, что «good-enough-now API» неизбежны: требования меняются, а идеальный интерфейс предсказать невозможно.
• Отмечают, что советы могут работать для стабильных desktop-систем, но не для быстро меняющихся продуктов или веба.
• Напоминают о важности баланса: избыточная абстракция и YAGNI-функции создают техдолг, а полное отсутствие модульности — дублирование и баги.