В чем главная проблема сложных кастомных проектов?
Кастомный веб-проект — это сайт, который не собирается из готовых модулей на базе некой платформы или CMS, а требует активного участия программистов различного профиля. В статье мы разберем как сделать этот путь более безопасным и экономным.
Введение
Сначала давайте разберемся, что такое кастомный веб-проект. Это сайт, который не собирается из готовых модулей на базе некой платформы или CMS, а требует активного участия программистов различного профиля.
Если вы хотите нечто уникальное, чего нет на типовых системах — вам уготована дорога в кастом.
В статье мы разберем как сделать этот путь более безопасным и экономным.
Ключевые характеристики кастомного проекта
Главное, что необходимо запомнить заказчику сильно кастомного проекта — это будет долго, дорого, трудно, с ошибками.
Важно сразу понимать, где вы находитесь: на сборке типовых блоков или на заказной разработке с нуля под проект. У этих двух проектов совершенно разные процессы.
Сборка из готовых блоков — простая, быстрая, но практически не кастомизируемая.
Заказная разработка — долгая, дорогая, нужны разные профили программистов, но зато можно сделать нечто уникальное под проект.
Какой уровень кастомизации мне нужен в проекте?
Почему нельзя к кастому применить техники сборки из готовых блоков — все дело в хотелках и аппетитах заказчика в плане изменений. Нужно сразу решить для себя на каком уровне кастомизации вы готовы быть. Если вы берете что-то типовое, то сразу определяйте возможный уровень кастомизации.
Если этого не сделать, то велик риск, что в будущем вы просто упретесь в это ограничение. Например, вы хотите сделать в своей системе личный кабинет клиента, а, оказывается, это нельзя сделать в рамках существующей системы. И вероятно придется менять полностью систему, что создает дополнительные временные и финансовые расходы.
Обратная ситуация тоже нехорошая. Необходимо сделать некий типовой проект, но для этого берут не какую-то типовую CMS, на которой уже 100500 раз делался подобный проект, а решают начать разработку с нуля. В итоге вы собираете все грабли, которые уже давно учтены в готовых решениях. При этом разработка будет дорогая, долгая.
Истина лежит где-то посередине. Нужно спланировать какие изменения вам нужны в будущем и искать систему, которая позволит эти будущие изменения учесть. Чем больше готовых наработок существует в продукте, тем проще их будет адаптировать в ваш проект.
Ключевым остается вопрос последующей кастомизации. Какой вам толк от 100 различных возможностей некоего некастомизируемого продукта, если там нельзя внедрить критически важную для вас бизнес-логику.
В платформе Falcon Space мы исходит из следующего — гибкость решения является ключевой ценностью. Без этого невозможно будет планировать развитие продукта на базе платформы. Именно из-за гибкости мы не делаем полностью визуальные средства проектирования — все равно ключевым языком остается SQL и разметка строится на гибком Bootstrap4. Если это убрать и делать визуальные редакторы — сразу будут возникать серьезные ограничения по гибкости решения. При этом владельцу проекта приходится идти на некоторые ограничения в плане работы функционала (например, компонент чата решает все главные функции коммуникации, но его проблематично полностью кастомизировать под клиента). Эти ограничения касаются скорее мелких тактических деталей и не ограничивают ключевые вопросы — изменение бизнес-логики, изменение стилизации, гибкая разметка форм и так далее. Даже оптимизация SQL запросов остается в зоне влияния команды на проекте. А представьте продукт, в котором все зашито внутри. На начальной стадии все хорошо работает, но чем больше данных, тем более тормознутый становится работа. И вы ничего с этим не можете сделать.
В случае с Falcon Space у проекта есть возможность менять практически любой запрос SQL к БД (а именно они обычно являются причиной тормозов). Таким образом, можно оптимизировать работу системы.
Почему мы не ввязываемся в глубокий кастом?
Под глубоким кастомом я понимаю особые видоизменения стандартных функций, какие-то уникальные стили. И эти изменения плохо соотносятся с исходной платформой или CMS, что приводит к необходимости действовать обходными средствами (мягкое определение слово Костыль). Также глубокий кастом для нас — это полная интеграция с какой-то внешней системой по многим процессам (где наша платформа выступает просто как оболочка для другой системы). Такой проект будет полностью построен на API методах, а это дополнительная сложность для построения системы.
Глубокий кастом вреден как для заказчика, так и для поставщика услуг.
Заказчик обычно не может принять, что это так дорого и долго (т.е. не видит всей сложности глубокого кастома, постоянно сравнивая это с подходом сборки). Программисты обычно недооценивают системные эффекты и общую сложность кастома. Глубокий кастом зачастую приводит к костылям в системе. В погоне за желанием удовлетворить изысканные вкусы заказчика применяются не самые надежные методы на грани фола. Глубокий кастом в принципе не очень выгоден исполнителям — они сильно завязываются в проект, вместо того, чтобы улучшать свой стандартный продукт. Глубокий кастом обычно сложнее поддерживать. Это головная боль как заказчика, так и разработчика. Кто-то может подумать наоборот, что это хорошо для разработчика, много работы —, но по факту за поддержку кастомного решения заказчик, который все это накрутил, не очень охотно платит с посылом «я же уже это оплатил ранее». И очень сложно до такого заказчика донести, что именно он создал эту проблему своими безумными хотелками.
Где выход?
Мы — за разумный кастом. У проекта должна быть очень высокая степень гибкости в ЗНАЧИМЫХ моментах:
создание новых ролей, типов пользователей, личных кабинетов;
изменение процесса движения заявки;
изменение форм и состава полей у таблиц и форм;
стилизация для UX, для удобства пользователя (но без вкусовщины);
создание новых объектов учета в системе, постепенное расширение полей объектов;
создание новых аналитических отчетов, диаграмм, графиков и так далее;
создание новых сложных систем уведомлений пользователей;
подключение новых API.
Все это крайне важно для бизнеса. Без этого система рано или поздно упрется в одно из этих требований. И все это мы учитываем в рамках развития платформы. Сайт на Falcon Space не ограничен количеством пользователей, количеством и сложностью объектов в базе данных. Можно создавать различные страницы, формы, таблицы, графики, дашборды и постепенно их развивать.
Какой кастом может навредить проекту (и обычно мы его не приветствуем в наших проектах):
чрезмерное увлечение графической частью (например, рисование своих иконок, множественный пересмотр шрифтов меток и так далее);
интеграция с кучей систем сразу (например, со всеми основными маркетплейсами) — это очень сложный кастомный проект. И обычно заказчики таких проектов не понимают всю сложность своего проекта. Такие проекты лучше делать постепенно: как минимум ограничиться интеграцией с 1–2 системами, и сначала реализовать только их;
«хочу все по-своему». К примеру, у нас загрузка файлов есть в 2 вариантах (drop зона и через модальное окно). Но клиент хочет еще какой-то свой способ (причем без рациональных причин, кроме «ну я клиент, я так хочу»). Другой пример — это сортировка в таблице. У нас она работает строго определенным образом (можно по любому столбцу сортировать и это настраивается, но сама функциональность UI жестко задана в компоненте вывода таблиц). В проектах, где нужно все сделать по-своему без весомых причин — это просто пустая трата ресурсов как заказчика, так и разработчика.
Найдите для себя разумный уровень кастомизации в проекте и сразу учитывайте этот фактор при выборе инструмента для создания и последующего развития своего проекта.
Просто о сложном
Новости 
Кейсы 
How to 
Интервью и дискуссии 
Маркетинговые исследования 
Проверено ADPASS 
Рекламные кампании 