Что такое кастомизация программы

Кастомизация (англ. customisation) — англицизм, часто использующийся в околокомпьютерной терминологии, означающий настройку чего-либо под нужды конкретного пользователя. Синонимами слова «кастомизация» могут также выступать также термины англоязычного происхождения «моддинг» и «тюнинг».

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

Словом «тюнинг» чаще всего называют кастомизацию автомобиля или любого другого транспортного средства. При этом, человек, который модифицирует свою машину, зачастую одновременно преследует цель и сделать внешний вид поинтереснее, и повысить ее мощность по сравнению с заводской.

Лучшие Программы для Кастомизации Виндовс 11/10 в 2022 | Лучший софт для оформления Windows

В сфере кастомизации компьютеров чаще применяется термин «моддинг». Здесь на первый план выходит эстетический вид, а уже во вторую очередь установка дорогих мощных комплектующих.

Кастомизация компьютера может происходить и в среде операционной системы. Установка тем оформления, настройка программ под нужды пользователя и подбор к этим программам альтернативных скинов, – все это тоже кастомизация, но только программная 🙂

Источник: www.bestfree.ru

Что такое кастомизация программы

Кастомизация

Одним из последних трендов на рынке является кастомизация товаров. Подобное явление активно используется как небольшими компаниями, так и такими гигантами, как Apple, Microsoft и многими другими не менее известными брендами.

Так что же такое кастомизация? От английского слова “customer” (клиент), понятие означает создание товара под запрос конкретного потребителя, например, вы приобретаете компьютеры для фирмы, но хотите, чтобы они отличались от остальных таких же компьютеров, для этого вы заказываете кастомизацию у поставщика, чтобы он добавил название и логотип вашей компании на поверхность ПК. Таким образом, подобный ребрендинг позволяет создать уникальный товар, чтобы клиенты или сотрудники могли идентифицировать его с вашим брендом. Ключевое преимущество кастомизации заключается в том, что вы получаете уже готовый продукт. Тем самым экономя свое время и деньги.

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

OEM и ODM

Существует множество способов кастомизировать ПО. Одними из самых распространенных способов подобной модификации программ являются OEM и ODM. Далее мы подробно расскажем о каждом из них.

КАК СДЕЛАТЬ КРАСИВЫЙ РАБОЧИЙ СТОЛ | КАСТОМИЗАЦИЯ WINDOWS 10

OEM или же Original Equipment Manufacturer (с английского “производитель оригинального оборудования”) — производство деталей и оборудования, которые могут быть проданы другим производителям в качестве комплектующих для создания или дополнения их товаров.

Например, компания, производящая компьютеры, как правило, не производит для него программное обеспечение и операционные системы, а закупает их у других производителей. При этом подобные системы могут быть кастомизированы под конкретные запросы пользователей ПК. Например, если компания выпустила лимитированное устройство на свой юбилей или в тандеме с какой-либо фирмой, то они могут запросить у производителя ОС кастомизированную версию системы. Одними из наиболее ярких примеров подобной кастомизации являются товары компании Samsung, которая часто проводит различные коллаборации с брендами и заказывает ребрендинг Android ОС для своих устройств.

К преимуществам OEM производителей можно отнести следующее:

+ Относительная бюджетность данного метода, так как подобные компании предоставляют хорошие скидки за использование их систем для товаров массового производства;
+ Возможность подстроиться под каждого клиента с его запросами;
+ Экономия средств на собственном производстве;
+ Нет привязанности к конкретному производителю, в любой момент можно сменить компанию OEM, которая производит для вашего бизнеса комплектующие элементы.

Однако у данной схемы есть и ряд недостатков:

— Подобная система работы не подойдет для маленьких предприятий, выпускающих товары в небольшом объеме, так как это может быть очень дорогостояще;
— Не в каждой нише возможно сотрудничество со сторонними компаниями, например, в силу производственной тайны;
— Нужно указывать соавторство OEM компании при продаже товаров.

ODM или же Original Design Manufacturer, также известное как White Label, (с английского “производство оригинального устройства”) — производство товаров, которые создаются полностью по собственному оригинальному проекту. При сотрудничестве с ODM производителями, компании заказывают у них производство полноценного товара, как правило, сразу кастомизированного под их фирму, после чего продают его под своим брендом, то есть выдают за свой оригинальный продукт.

Стоит отметить, что многие предприниматели путаются в понятиях White Label и ODM, в то время как они практически идентичны. Единственное отличие в том, что ODM — это именно производитель кастомизированного товара, а White Label — форма сотрудничества между этим производителем и фирмой-заказчиком.

Преимущества подобного сотрудничества:

+ Компании не требуется наличие собственной фабрики или завода для производства товаров, соответственно, экономятся материальные ресурсы;
+ Вам не нужно тратить время на создание собственного производства с нуля, достаточно заказать кастомизированный товар у ODM производителя и сразу же начать продавать;
+ Нет необходимости указывать ODM компанию в качестве сопроизводителя товаров, так как по форме сотрудничества White Label, все права на них принадлежат компании, заказавшей производство.

— Более дорогостоящее производство товаров;
— Зависимость от ODM компании, если по какой-то причине их производство остановится, то и продажи компании-заказчика прекратятся;
— Сложность при смене ODM-партнера, так как не всегда можно быстро и без потерь найти компанию, условия которой бы соответствовали требованиям фирмы.

Таким образом, OEM и ODM производства используются для создания уникальной продукции для бренда. Каждая из этих схем имеет свои параметры, опираясь на которые, компании могут выбрать наиболее удобный и выгодный для них способ производства кастомизированной продукции.

Кастомизация программы видеонаблюдения Xeoma

О кастомизации информационных систем

Основное направление деятельности нашей компании — это разработка корпоративных информационных систем. Помимо систем под заказ мы делаем два тиражируемых продукта. Конечно, мы стараемся, чтобы наши продукты были максимально удобными и функциональными.

Однако в реальной жизни каждый бизнес имеет свои особенности и не всегда готов мириться со стандартными возможностями системы. Возникает задача доработки решения под конкретного клиента и его дальнейшей поддержки. Какие существуют подходы к организации архитектуры расширяемых продуктов? Какие проблемы могут возникнуть при разработке? Как поступили мы?

Обо всем этом ниже.

Возможные подходы

Для начала уточним, что «проектом-расширением» или просто «расширением» мы называем продукт с внесенными модификациями для конкретного заказчика. А теперь рассмотрим некоторые из возможных подходов к расширению продукта:

Отдельный бранч в репозитории под каждый проект-расширение

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

Можно, конечно, сразу думать о будущих переводах на новую версию продукта и организовывать код таким образом, что все специфичные изменения будут располагаться максимально в стороне от кода основного продукта. В идеальном мире это бы сработало, но мы с вами живем в суровой реальности, где часто срок выполнения задачи может быть объявлен как “вчера”, и работает над проектом отнюдь не компактная команда классных профессионалов, а батальон вчерашних студентов. В таких ситуациях люди редко задумываются об архитектуре и идут по пути наименьшего сопротивления — нашел место, где надо поправить, удалил старое, написал новое. Это, кстати, ведет к еще одной большой проблеме — логика расширения перемешивается с логикой продукта.

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

Использование динамических атрибутов (модель Entity-Attribute-Value)
Модель Entity-Attribute-Value (или Open Schema) может использоваться вместе со стандартной реляционной моделью для динамического определения и хранения значений новых атрибутов сущностей. При использовании модели EAV значения атрибутов обычно пишутся в одну таблицу из трех колонок. Как несложно догадаться, их имена Entity, Attribute и Value:

• Entity — хранит ссылку на объект, поле которого мы описываем. Обычно это идентификатор сущности;
• Attribute — ссылка на определение атрибута (об этом ниже);
• Value — собственно значение атрибута.

Обязательным компонентом схемы является также таблица, которая хранит описание метаданных для атрибутов:

• тип атрибута;
• ограничения (длина поля, регулярное выражение, которому должно соответствовать значение и пр.);
• компонент для отображения в UI;
• порядок отображения компонента в UI.

Для использования этой модели в продукте необходимо сделать 2 вещи:

• Реализовать механизм задания метаданных, с помощью которого мы сможем, например, указать, что к сущностям типа “Договор” добавится новый атрибут «Дата расторжения», тип поля — «Дата», компонент для отображения — DateField.
• Реализовать механизмы отображения и ввода значений динамических атрибутов на необходимых экранах продукта. Механизм должен находить возможный набор атрибутов для данной сущности в таблице с описанием метаданных, отображать компоненты для их редактирования, а затем в таблице с данными искать и отображать их значения, сохраняя их при закрытии экрана.

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

Далее о недостатках. Во-первых, это ограниченность применения. Модель EAV позволит лишь добавить атрибуты в сущность и отобразить их в заранее определенном месте на экране. Не более того. Об изменении функциональности, хитрых UI-компонентах здесь речи не идет.

Во-вторых, EAV модель создает большую дополнительную нагрузку на сервер БД. Для загрузки одного экземпляра сущности без связей потребуется чтение вместо одной нескольких строк таблицы. Для загрузки списка экземпляров, например в таблицу на UI, вообще потребуется N+1 запросов, либо джойны по числу колонок таблицы. Учитывая, что база данных в корпоративных системах и так чаще всего является самым медленным и плохо масштабируемым элементом, такая дополнительная нагрузка может просто убить систему.

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

Плагинная архитектура
Данная архитектура позволяет хранить дополнительную функциональность в отдельных артефактах — плагинах. Если ваш заказчик хочет какой-то новой специфики, то вы ставите ему базовый продукт, пишете плагин, подключаете его и готово. Для использования плагинов в продукте должны быть объявлены точки расширения. Что это такое? Если просто, то это определенные места в коде.

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

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

Плагинная архитектура позволяет хранить всю новую функциональность отдельно от продукта, что является немаловажным её достоинством. Полное физическое разделение продукта и плагинов делает процесс обновления версии продукта или плагина очень простым — достаточно лишь заменить обновленный компонент.

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

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

Как это делаем мы