Профессиональное сообщество
лидеров цифровой трансформации
Евгений Обогоров
Евгений Обогоров
ООО "Эдштейн"
Генеральный директор

Вопрос коллегам: Разработка кастомизированных продуктов

7 января 2020
4 6847
Коллеги, как построить разработку и обновление продукта, который значительно кастомизируется в части фронтэнда под каждого клиента?
Коментарии: 4

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • 14.01.2020 12:00

    Давайте примем во внимание, что любой продукт (особенно если он интегрирован с другими системами) - кастомизируется.

    И все знают традиционные подходы от водопадной модели до аджайла, и ITIL нам всем - святое писание ))

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

    Когда мы работаем на подобных проектах для бизнеса или НКО, мы всегда рекомендуем следующие шаги

    1. Первичное описание ситуации "как есть"
    2. Выявление проблемных участков
    3. Фиксация цели (куда хотим прийти)
    4. Определение задач, которые необходимо решить, чтобы достичь цели
    5. Создание комплекса мероприятий (проектов), которые необходимо выполнить для решения задач и достижения цели

    Нужно погрузиться в жизнь компании, помочь ключевым сотрудникам сфокусироваться на настоящих проблемах, а не уходить в эмоции и негатив.
    И мы приходим к теории систем )) изменение производственных процессов в ИТ в чем-то и культурологические перемены. Иначе, революция от нового ИТ директора обязательно получит весомое сопротивление.

    Мы много рассказываем об этом https://amiveo.ru

    Ответить
    • 16.01.2020 16:28

      Ольга, спасибо за комментарий. Наверное тут скорее вопрос от стороннего разработчика как ему быть, когда не все изнутри ему известно. Не все же захотят в жизнь компании разработчиков погружать

      Ответить
      • Дмитрий Мыльников
        Дмитрий Мыльников
        Рейтинг: 13
        ПК ГПИ Челябинскгражданпроект
        Начальник отдела автоматизации проектирования
        23.01.2020 09:15

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

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

        Ответить
  • Дмитрий Мыльников
    Дмитрий Мыльников
    Рейтинг: 13
    ПК ГПИ Челябинскгражданпроект
    Начальник отдела автоматизации проектирования
    23.01.2020 09:30

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

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

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

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

    Само собой, что сделать систему первого типа намного проще и быстрее, чем систему второго типа. Но ничего невозможного тут нет.

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

    Ответить
фильтр
Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.