@maksam07

Как разделять относительно одинаковые скрипты между клиентами?

Имеются различные заказы на разработку дополнений для сайта. Предположим, что дополнения - как плагины для вордпресса. Иногда приходят заказы от разных клиентов на идентичный скрипт, тогда проблем нет, я делаю все в одной папке, использую гит, все сохраняю и далее рассылаю кому нужно. Но в какой-то момент доработка этого скрипта между клиентами может различаться и я не знаю как лучше с использованием гита вести уже 2 разные "версии" скрипта. Я пробую работать с разными ветками = разные клиенты, но не уверен, что это хороший вариант. Подскажите, у кого был подобный опыт или может что-то порекомендовать, как быть в ситуации, когда изначально для разных клиентов идентичный скрипт подходит, а потом нужно индивидуально под каждого допиливать?
  • Вопрос задан
  • 205 просмотров
Пригласить эксперта
Ответы на вопрос 3
VoidVolker
@VoidVolker
Dark side eye. А у нас печеньки! А у вас?
Декомпозиция и разбиение скриптов на более простые части, а так же добавление гибкости как в плане настроек, так и функционала.
Ответ написан
Комментировать
SeaInside
@SeaInside
15 лет пилю все эти штуки
Проектировать расширяемую, модульную структуру решения (конкретнее без примеров кода не сказать).

Оставлять в "основном" решении возможность подвязаться на события / переопределить какие-то константы, методы / etc.
В "клиентских" решениях либо расширять базовое решение (наследование в терминах ООП), либо в основном решении продумывать публичное API так, чтобы иметь возможность императивно дополнять / модифицировать результат основного скрипта. Ну либо проектировать настройки основного решения так, чтобы оно одновременно покрывало все клиентские сценарии (декларативный подход).

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

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

Если вышесказанное звучит как-то сложно, то работа над параллельными версиями (если клиентов не больше человек 10) - вполне себе вариант, почему нет. :)
Ответ написан
mayton2019
@mayton2019
Bigdata Engineer
Скрипты выросли. И у них появилась общая часть (shared). Которая не меняется. И вариативная часть которую
можно спокойно менять под каждого клиента
. Как выделить общее и частное - это великая тайна.
И понять ее можно только с опытом.

Я-бы предложил следующую стратегию. В общее (shared) должны зайти интерфейсы и абстрактные классы
или какие-то сущности которые почти никогда не меняются. В вариативные части (client1, client2 ...)
зайдут реализации или то что просто сильно меняется.

Преимущества данного подхода - будет меньше кода в перспективе. Но есть и недостаток.
Некоторые клиенты могут почувстовать странное (немотивированное) изменение версии
в (shared) части которое они не заказывали. Впрочем это может быть редко или вообще никогда.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы