ООО «ТЕЛЕСТОР»
ИНН:7811212947
erid:2SDnjchQtDg
ООО «ТЕЛЕСТОР»
ИНН:7811212947
erid:2SDnjchQtDg
Сначала давайте разберемся, что такое кастомный веб-проект. Это сайт, который не собирается из готовых модулей на базе некой платформы или CMS, а требует активного участия программистов различного профиля.
Если вы хотите нечто уникальное, чего нет на типовых системах - вам уготована дорога в кастом.
В статье мы разберем как сделать этот путь более безопасным и экономным.
Главное, что необходимо запомнить заказчику сильно кастомного проекта - это будет долго, дорого, трудно, с ошибками.
Важно сразу понимать, где вы находитесь: на сборке типовых блоков или на заказной разработке с нуля под проект. У этих двух проектов совершенно разные процессы.
Почему нельзя к кастому применить техники сборки из готовых блоков - все дело в хотелках и аппетитах заказчика в плане изменений. Нужно сразу решить для себя на каком уровне кастомизации вы готовы быть. Если вы берете что-то типовое, то сразу определяйте возможный уровень кастомизации.
Если этого не сделать, то велик риск, что в будущем вы просто упретесь в это ограничение. Например, вы хотите сделать в своей системе личный кабинет клиента, а, оказывается, это нельзя сделать в рамках существующей системы. И вероятно придется менять полностью систему, что создает дополнительные временные и финансовые расходы.
Обратная ситуация тоже нехорошая. Необходимо сделать некий типовой проект, но для этого берут не какую-то типовую CMS, на которой уже 100500 раз делался подобный проект, а решают начать разработку с нуля. В итоге вы собираете все грабли, которые уже давно учтены в готовых решениях. При этом разработка будет дорогая, долгая.
Истина лежит где-то посередине. Нужно спланировать какие изменения вам нужны в будущем и искать систему, которая позволит эти будущие изменения учесть. Чем больше готовых наработок существует в продукте, тем проще их будет адаптировать в ваш проект.
Ключевым остается вопрос последующей кастомизации. Какой вам толк от 100 различных возможностей некоего некастомизируемого продукта, если там нельзя внедрить критически важную для вас бизнес-логику.
В платформе Falcon Space мы исходит из следующего - гибкость решения является ключевой ценностью. Без этого невозможно будет планировать развитие продукта на базе платформы. Именно из-за гибкости мы не делаем полностью визуальные средства проектирования - все равно ключевым языком остается SQL и разметка строится на гибком Bootstrap4. Если это убрать и делать визуальные редакторы - сразу будут возникать серьезные ограничения по гибкости решения.
При этом владельцу проекта приходится идти на некоторые ограничения в плане работы функционала (например, компонент чата решает все главные функции коммуникации, но его проблематично полностью кастомизировать под клиента). Эти ограничения касаются скорее мелких тактических деталей и не ограничивают ключевые вопросы - изменение бизнес-логики, изменение стилизации, гибкая разметка форм и т.д. Даже оптимизация SQL запросов остается в зоне влияния команды на проекте.
А представьте продукт, в котором все зашито внутри. На начальной стадии все хорошо работает, но чем больше данных, тем более тормознутый становится работа. И вы ничего с этим не можете сделать.
В случае с Falcon Space у проекта есть возможность менять практически любой запрос SQL к БД (а именно они обычно являются причиной тормозов). Таким образом, можно оптимизировать работу системы.
Под глубоким кастомом я понимаю особые видоизменения стандартных функций, какие-то уникальные стили. И эти изменения плохо соотносятся с исходной платформой или CMS, что приводит к необходимости действовать обходными средствами (мягкое определение слово Костыль).
Также глубокий кастом для нас - это полная интеграция с какой-то внешней системой по многим процессам (где наша платформа выступает просто как оболочка для другой системы). Такой проект будет полностью построен на API методах, а это дополнительная сложность для построения системы.
Глубокий кастом вреден как для заказчика, так и для поставщика услуг.
Заказчик обычно не может принять, что это так дорого и долго (т.е. не видит всей сложности глубокого кастома, постоянно сравнивая это с подходом сборки).
Программисты обычно недооценивают системные эффекты и общую сложность кастома. Глубокий кастом зачастую приводит к костылям в системе.
В погоне за желанием удовлетворить изысканные вкусы заказчика применяются не самые надежные методы на грани фола.
Глубокий кастом в принципе не очень выгоден исполнителям - они сильно завязываются в проект, вместо того, чтобы улучшать свой стандартный продукт.
Глубокий кастом обычно сложнее поддерживать. Это головная боль как заказчика, так и разработчика.
Кто-то может подумать наоборот, что это хорошо для разработчика, много работы - но по факту за поддержку кастомного решения заказчик, который все это накрутил, не очень охотно платит с посылом "я же уже это оплатил ранее".
И очень сложно до такого заказчика донести, что именно он создал эту проблему своими безумными хотелками.
Мы - за разумный кастом. У проекта должна быть очень высокая степень гибкости в ЗНАЧИМЫХ моментах:
Все это крайне важно для бизнеса. Без этого система рано или поздно упрется в одно из этих требований. И все это мы учитываем в рамках развития платформы. Сайт на Falcon Space не ограничен количеством пользователей, количеством и сложностью объектов в базе данных. Можно создавать различные страницы, формы, таблицы, графики, дашборды и постепенно их развивать.
Какой кастом может навредить проекту (и обычно мы его не приветствуем в наших проектах):
Найдите для себя разумный уровень кастомизации в проекте и сразу учитывайте этот фактор при выборе инструмента для создания и последующего развития своего проекта.
Источник: https://falconspace.ru/blog/v-chem-glavnaya-problema-slozhnykh-kastomnykh-proektov