Четырнадцать миллионов шестьсот двадцать пять вариантов 🎲

Любую задачу можно решить бесконечным количеством способов. В разработке эта бесконечность обычно сжимается до двух-трех относительно адекватных вариантов.

Эта история возникла после недавнего общения с товарищем. Когда-то мы помогали ему с eCommerce, но сегодня уже нет, и поэтому обсуждение попало сюда.

Итак, исходная задача: в определенное время включать и отключать определенную службу доставки в интернет-магазине. Подрядчик оценил работу в 20 часов, что показалось слегка завышенным.

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

Вариант 1: "Барский" 👑

Создаем новое ограничение у службы доставки: время начала и окончания работы. Главное, чтобы на сервере было корректно установлено московское время. Выносим настройку в оформление доставки — готово. Делать это относительно несложно, поскольку у Битрикса есть штатные механизмы для расширения ограничений по доставке, оплате и даже скидкам.

Плюсы: решение гибкое, настроить его сможет практически любой пользователь.

Вариант 2: "Жестко в коде" 🖥

Прописываем логику прямо в коде — можно на PHP, можно на JavaScript. Определяем, когда показывать доставку, а когда нет. Главное — правильное серверное время. Можно скрывать доставку (не лучший вариант) или исключать ее из массива данных — здесь уже масса решений.

Этот вариант проще первого, но если что-то потребуется поменять, придется снова звать разработчика. В проекте, о котором идет речь, используется Vue, так что можно реализовать логику и там. Однако вариант так себе. 🤷

Вариант 3: "Калашников" 🔫

Создаем два PHP-файла: один включает доставку, другой выключает. Запускаем их по cron в нужное время — и готово.

Гибкость: можно легко менять расписание в cron. Однако для этого потребуются хотя бы базовые знания. Сами скрипты для включения/выключения доставки напишет ChatGPT за пару минут. В итоге задача вместе с настройкой cron займет пару часов. ⚡️

Выводы 🧐

Подобных вариантов можно придумать еще десятки — они будут находиться где-то в этом диапазоне, различаясь только трудозатратами.

Главный смысл этой истории: почти любую задачу можно решить разными способами, каждый из которых имеет свои плюсы и минусы. Мой товарищ выбрал cron, сократив время реализации с 20 до 4 часов.

Но дело не столько в экономии времени, сколько в квалификации менеджеров, с которыми вы взаимодействуете. На мой взгляд, к большинству задач стоит предлагать 2-3 варианта решения с разбором плюсов и минусов каждого. Важно учитывать развитие проекта, его долгосрочную стратегию и другие факторы. Возможно, имело бы смысл выбрать первый вариант, если бы такие ограничения можно было бы переиспользовать, например, в оплате или маркетинговых блоках.

С другой стороны, третий вариант — это "костыльное" решение, и на крупных проектах так делать нельзя: если подобных обработчиков будет сотни, возникнет хаос. Поэтому важно учитывать контекст задачи. 🚧

Костыльное решение оправдано, если заказчику объясняют, какие варианты у него есть, и он делает осознанный выбор.