Четыре expert'а разнесли мой feedback-сервис

Четыре критика нашего feedback-сервиса: жестокая правда

Представь ситуацию: ты потратил недели на разработку системы сбора feedback для borisovai-site, прошелся по best practices, всё выглядит красиво. А потом приглашаешь четырех экспертов провести code review — и они разносят твой код в пух и прах. Нет, не язвительно, а обоснованно. Я тогда сидел с этим отчетом часа два.

Началось с Security Expert‘а. Он посмотрел на мою систему сбора feedback и сказал: «Привет, GDPR! Ты знаешь, что нарушаешь европейское законодательство?» Оказалось, мне не хватало privacy notice, retention policy и чекбокса согласия. XSS в email-полях, уязвимости для timing attack’ов, email harvesting — полный набор. Но самое больное: я использовал 32-битный bitwise hash вместо SHA256. Это как строить замок из картона. Эксперт вынес вердикт: NOT PRODUCTION READY — пока не пофиксишь GDPR.

Потом пришла очередь Backend Architect‘а. Он посмотрел на мою базу и спросил: «А почему у тебя нет составного индекса на (targetType, targetSlug)?» Я посчитал: 100K записей, full-scan по каждому запросу. Это боль. Но это было ещё не всё. Функция countByTarget загружала ВСЕ feedback’и в память для подсчета — классический O(n) на production’е. Плюс race condition в create endpoint: проверка rate limit и дедупликация не были атомарными операциями. Вишенка на торте: я использовал SQLite для production’а. SQLite! Архитектор деликатно посоветовал PostgreSQL.

Frontend Expert просмотрел React-компоненты и нашел missing dependencies в useCallback, untyped any в fingerprint.ts, отсутствие AbortController. Но главное убийство: нет aria-labels на кнопках, нет aria-live на сообщениях об ошибках. Screen readers просто не видели интерфейс. Canvas fingerprinting работал синхронно и блокировал main thread. Проще говоря, мой feedback-форм был отзывчив для слышащих пользователей, но недоступен для людей с ограничениями по зрению.

И ещё Product Owner добавил: нет email-уведомлений админам о критических баг-репортах. Система красивая, но никто не узнает, когда пользователь кричит о проблеме.

Итог? ~2 недели критических фиксов: GDPR-соответствие (privacy notice + право на удаление данных), индекс на БД, транзакции в create endpoint, полная ARIA-поддержка, email-notifications, миграция на PostgreSQL. Сначала казалось, что я строил production-готовое решение. На самом деле я строил красивое демо, которое развалилось при первой серьёзной проверке.

Урок: security, accessibility и database architecture — это не вишни на торте, это фундамент. Ты можешь иметь идеальный UI, но если пользователь не может получить доступ к твоему сервису или его данные не защищены, ничего не имеет значения.

😄 WebAssembly: решение проблемы, о существовании которой ты не знал, способом, который не понимаешь.