У вас есть идея для приложения, и вы готовы его построить. Денег мало, а времени мало, поэтому вы решаете использовать стартовый набор, чтобы выполнить работу. Это кажется отличной идеей: кто-то уже нашел время, чтобы собрать полное приложение — от базы данных до серверных компонентов и кода на стороне браузера — что должно сэкономить вам деньги и позволить вам сосредоточиться на написании кода, уникального для вашего приложения. . Что возможно могло пойти не так…
Конечно, обещания не всегда оправдывают ожидания. Прошли недели или месяцы, а вы все еще пытаетесь реализовать свой проект. Стартовый набор, который так много предлагал в начале вашего проекта, теперь стал главным препятствием.
Мы видели, как в ряде проектов использовались стартовые наборы, и неоднократно сталкивались с одними и теми же проблемами. Самая большая проблема заключается в том, что стартовый набор часто создается для решения чужой проблемы. Если у вас нет тех же проблем, что и у автора стартового комплекта, вы, скорее всего, окажетесь в положении, когда вы либо предоставляете что-то нестандартное, либо вынуждены вырезать части стартового комплекта. Как только вы начнете дергать за нить, вы не можете быть уверены, сколько она распустится.
Многие стартовые наборы имеют ограниченную документацию или вообще не имеют ее. Чем сложнее стартовый набор, тем труднее понять, что происходит под капотом. Из-за процесса сборки вы можете даже не знать всего, что есть в вашем окончательном приложении. Поддержание или расширение кодовой базы также становится сложной задачей в этой ситуации.
Требуемые версии основных компонентов также являются серьезной ловушкой. Примеры включают приложения, созданные на самой передовой (и нестабильной) версии Node, или приложения PHP, использующие устаревшие функции. При использовании более старых компонентов ваше приложение может содержать дыры в безопасности, которые нельзя исправить без серьезного рефакторинга базовых стартовых наборов. Приложения на передовой версии компонента могут включать функции, которые удаляются по мере перехода компонента к циклу стабильного выпуска. Опять же, вы привязаны к платформе, которую со временем будет все труднее поддерживать.
В качестве иллюстрации этого клиент попросил нас изменить приложение, основанное на популярном стартовом наборе. Хотя первоначальная работа была завершена в очень короткие сроки, они столкнулись с проблемами, связанными с ее расширением. Файловая структура по умолчанию очень затрудняла создание повторно используемых компонентов. Кроме того, фреймворк был привязан к версии Node, отличной от LTS, а это означало, что работа должна была пройти через длительную миграцию, чтобы перенести ее на более стабильную платформу. После тщательного анализа было определено, что лучший путь вперед — переписать код так, чтобы он больше не был привязан к этому стартовому набору.
Также учтите, что чем сложнее фреймворк или стартовый набор, тем туже смирительная рубашка. Meteor, например, обеспечивает быструю разработку, если вы согласны использовать Mongo в качестве хранилища данных. Хотя Mongo — отличное решение, это не правильный ответ для каждой проблемы. Мы видели, как многие младшие команды разработчиков начинали с Meteor. По мере того, как они развиваются как команда и узнают больше об управлении данными, они понимают, что им необходимо перейти на реляционную базу данных. Теперь они столкнулись с трудным выбором: перестроить все с нуля или придумать хаки, чтобы система продолжала работать.
Стартовые наборы также лишают возможности учиться. Вместо того, чтобы тратить время на изучение новых технологий и идей, разработчику дается набор кода и указаний по изменению поверхностных элементов, таких как пользовательский интерфейс или подключение к базе данных.
Однако это не означает, что стартовые наборы не могут быть полезны. Создание собственного стартового набора может ускорить ваши усилия по разработке, особенно если вы делаете подобные проекты на регулярной основе. Стартовые наборы от других разработчиков также могут предоставить возможность немного покопаться, чтобы увидеть, что другие люди считают важным включить в качестве основы приложения.
Стартовые наборы всегда идут с компромиссом. Хотя они позволяют коду выйти за дверь в очень короткие сроки, они часто накладывают ограничения, которые ощущаются, когда приходит время добавить ключевые функции в приложение. Более полные стартовые наборы по самой своей природе более сложны. Ключевой вопрос: стоит ли быстрое начало работы в ущерб гибкости для удовлетворения долгосрочных потребностей в продукте? Если вы не создаете простой веб-сайт, ответ почти всегда будет отрицательным.
