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

Question

[maksam07]

Имеются различные заказы на разработку дополнений для сайта. Предположим, что дополнения - как плагины для вордпресса. Иногда приходят заказы от разных клиентов на идентичный скрипт, тогда проблем нет, я делаю все в одной папке, использую гит, все сохраняю и далее рассылаю кому нужно. Но в какой-то момент доработка этого скрипта между клиентами может различаться и я не знаю как лучше с использованием гита вести уже 2 разные "версии" скрипта. Я пробую работать с разными ветками = разные клиенты, но не уверен, что это хороший вариант. Подскажите, у кого был подобный опыт или может что-то порекомендовать, как быть в ситуации, когда изначально для разных клиентов идентичный скрипт подходит, а потом нужно индивидуально под каждого допиливать?

Answer 1

[VoidVolker]

Декомпозиция и разбиение скриптов на более простые части, а так же добавление гибкости как в плане настроек, так и функционала.

Answer 2

[Максим Морев]

Проектировать расширяемую, модульную структуру решения (конкретнее без примеров кода не сказать).

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

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

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

Если вышесказанное звучит как-то сложно, то работа над параллельными версиями (если клиентов не больше человек 10) - вполне себе вариант, почему нет. :)

Comments

[maksam07]

если клиентов не больше человек 10

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

Оставлять в "основном" решении возможность подвязаться на события / переопределить какие-то константы, методы / etc.

Думал об этом решении и в принципе оно вполне реальное, просто немного больше времени затратить на разработку, чтобы покрыть более важные места. А то что не покрыто, если клиент запрашивает в "том" месте доработку, то допилить "основное" решение, а в отдельном использовать работу с событиями

Answer 3

[mayton2019]

Скрипты выросли. И у них появилась общая часть (shared). Которая не меняется. И вариативная часть которую
можно спокойно менять под каждого клиента. Как выделить общее и частное - это великая тайна.
И понять ее можно только с опытом.

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

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