Как разделять относительно одинаковые скрипты между клиентами?
Имеются различные заказы на разработку дополнений для сайта. Предположим, что дополнения - как плагины для вордпресса. Иногда приходят заказы от разных клиентов на идентичный скрипт, тогда проблем нет, я делаю все в одной папке, использую гит, все сохраняю и далее рассылаю кому нужно. Но в какой-то момент доработка этого скрипта между клиентами может различаться и я не знаю как лучше с использованием гита вести уже 2 разные "версии" скрипта. Я пробую работать с разными ветками = разные клиенты, но не уверен, что это хороший вариант. Подскажите, у кого был подобный опыт или может что-то порекомендовать, как быть в ситуации, когда изначально для разных клиентов идентичный скрипт подходит, а потом нужно индивидуально под каждого допиливать?
Дополнительно:
Ответы:
Декомпозиция и разбиение скриптов на более простые части, а так же добавление гибкости как в плане настроек, так и функционала.
Проектировать расширяемую, модульную структуру решения (конкретнее без примеров кода не сказать).
Оставлять в "основном" решении возможность подвязаться на события / переопределить какие-то константы, методы / etc.
В "клиентских" решениях либо расширять базовое решение (наследование в терминах ООП), либо в основном решении продумывать публичное API так, чтобы иметь возможность императивно дополнять / модифицировать результат основного скрипта. Ну либо проектировать настройки основного решения так, чтобы оно одновременно покрывало все клиентские сценарии (декларативный подход).
По опыту, обычно декларативный подход в долгосроке более выгоден, но требует максимального покрытия тестами прям с самого начала, так как имеет тенденцию к превращению в монстра, в котором миллион настроек и очень страшно что-то подвинуть и быть уверенным, что ничего не сломалось. К версионированию более щепетильный подход нужен. Зато все тесты собраны в одном месте и действительно что-то гарантируют.
Императивный подход куда быстрее запилить, само по себе "основное" решение будет куда меньше, но в коде "клиентских" версий будет гораздо больше неочевидного. Тесты опять-таки, если пишутся, в таком случае должны писаться на клиентских сайтах тоже, так как прохождение тестов на "основном" решении вообще ничего не будет гарантировать.
Если вышесказанное звучит как-то сложно, то работа над параллельными версиями (если клиентов не больше человек 10) - вполне себе вариант, почему нет. :)
-
если клиентов не больше человек 10
Пока что был опыт на один "скрипт" - примерно 3 клиента с немного разными запросами, а т.к. я быстро не смог спроектировать хорошее разделение кода в рамках одного "репозитория", то просто веток насоздавал.
И это пока что единственный опыт. Все прошлые разработки устраивали всех других клиентовОставлять в "основном" решении возможность подвязаться на события / переопределить какие-то константы, методы / etc.
Думал об этом решении и в принципе оно вполне реальное, просто немного больше времени затратить на разработку, чтобы покрыть более важные места. А то что не покрыто, если клиент запрашивает в "том" месте доработку, то допилить "основное" решение, а в отдельном использовать работу с событиями
Скрипты выросли. И у них появилась общая часть (shared). Которая не меняется. И вариативная часть которую
можно спокойно менять под каждого клиента. Как выделить общее и частное - это великая тайна.
И понять ее можно только с опытом.
Я-бы предложил следующую стратегию. В общее (shared) должны зайти интерфейсы и абстрактные классы
или какие-то сущности которые почти никогда не меняются. В вариативные части (client1, client2 ...)
зайдут реализации или то что просто сильно меняется.
Преимущества данного подхода - будет меньше кода в перспективе. Но есть и недостаток.
Некоторые клиенты могут почувстовать странное (немотивированное) изменение версии
в (shared) части которое они не заказывали. Впрочем это может быть редко или вообще никогда.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Для разделения относительно одинаковых скриптов между клиентами вам может пригодиться использование кэширования на стороне клиента. Это позволит каждому клиенту иметь свою копию скрипта, что обеспечит изоляцию данных и предотвратит возможные конфликты между пользователями.
Одним из распространенных способов достижения этой цели является добавление уникального параметра к URL скрипта. Например, вы можете добавить временную метку или случайное число к концу URL, чтобы каждый клиент получил свою копию скрипта.
Пример кода на PHP:
$scriptUrl = 'http://example.com/script.js'; $uniqueParam = time(); // или можно использовать rand() для генерации случайного числа $scriptUrlWithParam = $scriptUrl . '?unique=' . $uniqueParam; echo '';
Таким образом, каждый клиент будет загружать скрипт с уникальным параметром, что позволит избежать конфликтов между пользователями.
Если вы используете какой-то фреймворк или библиотеку для управления ресурсами, такие как RequireJS или Webpack, у вас может быть возможность автоматически добавлять уникальные параметры к URL скриптов. Проверьте документацию выбранного инструмента для более подробной информации.
Надеюсь, это поможет вам разделить скрипты между клиентами и избежать возможных проблем. Если у вас возникнут дополнительные вопросы, не стесняйтесь задавать их.