В чем главная проблема сложных кастомных проектов?

Введение

Сначала давайте разберемся, что такое кастомный веб-проект. Это сайт, который не собирается из готовых модулей на базе некой платформы или CMS, а требует активного участия программистов различного профиля.

Если вы хотите нечто уникальное, чего нет на типовых системах — вам уготована дорога в кастом.

В статье мы разберем как сделать этот путь более безопасным и экономным.

Ключевые характеристики кастомного проекта

Главное, что необходимо запомнить заказчику сильно кастомного проекта — это будет долго, дорого, трудно, с ошибками.

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

1. Сборка из готовых блоков — простая, быстрая, но практически не кастомизируемая.
2. Заказная разработка — долгая, дорогая, нужны разные профили программистов, но зато можно сделать нечто уникальное под проект.

Какой уровень кастомизации мне нужен в проекте?

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

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

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

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

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

В платформе Falcon Space мы исходит из следующего — гибкость решения является ключевой ценностью. Без этого невозможно будет планировать развитие продукта на базе платформы. Именно из-за гибкости мы не делаем полностью визуальные средства проектирования — все равно ключевым языком остается SQL и разметка строится на гибком Bootstrap4. Если это убрать и делать визуальные редакторы — сразу будут возникать серьезные ограничения по гибкости решения.

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

А представьте продукт, в котором все зашито внутри. На начальной стадии все хорошо работает, но чем больше данных, тем более тормознутый становится работа. И вы ничего с этим не можете сделать.В случае с Falcon Space у проекта есть возможность менять практически любой запрос SQL к БД (а именно они обычно являются причиной тормозов). Таким образом, можно оптимизировать работу системы.

Почему мы не ввязываемся в глубокий кастом?

Под глубоким кастомом я понимаю особые видоизменения стандартных функций, какие-то уникальные стили. И эти изменения плохо соотносятся с исходной платформой или CMS, что приводит к необходимости действовать обходными средствами (мягкое определение слово Костыль). Также глубокий кастом для нас — это полная интеграция с какой-то внешней системой по многим процессам (где наша платформа выступает просто как оболочка для другой системы). Такой проект будет полностью построен на API методах, а это дополнительная сложность для построения системы.

Глубокий кастом вреден как для заказчика, так и для поставщика услуг.

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

Программисты обычно недооценивают системные эффекты и общую сложность кастома. Глубокий кастом зачастую приводит к костылям в системе. В погоне за желанием удовлетворить изысканные вкусы заказчика применяются не самые надежные методы на грани фола.

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

Глубокий кастом обычно сложнее поддерживать. Это головная боль как заказчика, так и разработчика. Кто-то может подумать наоборот, что это хорошо для разработчика, много работы — но по факту за поддержку кастомного решения заказчик, который все это накрутил, не очень охотно платит с посылом «я же уже это оплатил ранее». И очень сложно до такого заказчика донести, что именно он создал эту проблему своими безумными хотелками.

Где выход?

Мы — за разумный кастом. У проекта должна быть очень высокая степень гибкости в ЗНАЧИМЫХ моментах:

• создание новых ролей, типов пользователей, личных кабинетов;
• изменение процесса движения заявки;
• изменение форм и состава полей у таблиц и форм;
• стилизация для UX, для удобства пользователя (но без вкусовщины);
• создание новых объектов учета в системе, постепенное расширение полей объектов;
• создание новых аналитических отчетов, диаграмм, графиков и т.д.
• создание новых сложных систем уведомлений пользователей;
• подключение новых API

Все это крайне важно для бизнеса. Без этого система рано или поздно упрется в одно из этих требований. И все это мы учитываем в рамках развития платформы. Сайт на Falcon Space не ограничен количеством пользователей, количеством и сложностью объектов в базе данных. Можно создавать различные страницы, формы, таблицы, графики, дашборды и постепенно их развивать.

Какой кастом может навредить проекту (и обычно мы его не приветствуем в наших проектах):

• чрезмерное увлечение графической частью (например, рисование своих иконок, множественный пересмотр шрифтов меток и т.д.)
• интеграция с кучей систем сразу (например, со всеми основными маркетплейсами) — это очень сложный кастомный проект. И обычно заказчики таких проектов не понимают всю сложность своего проекта. Такие проекты лучше делать постепенно: как минимум ограничиться интеграцией с 1-2 системами, и сначала реализовать только их.
• «хочу все по-своему». К примеру, у нас загрузка файлов есть в 2 вариантах (drop зона и через модальное окно). Но клиент хочет еще какой-то свой способ (причем без рациональных причин, кроме «ну я клиент, я так хочу»). Другой пример — это сортировка в таблице. У нас она работает строго определенным образом (можно по любому столбцу сортировать и это настраивается, но сама функциональность UI жестко задана в компоненте вывода таблиц). В проектах, где нужно все сделать по-своему без весомых причин — это просто пустая трата ресурсов как заказчика, так и разработчика.

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

Источник: https://falconspace.ru/blog/v-chem-glavnaya-problema-slozhnykh-kastomnykh-proektov