Владимир Краснов

Любовь к фреймворкам

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

Фреймворк вам не нужен, если вы считаете, что:

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

Серьезное заблуждение. Замените слово "фреймворк" на название любой CMS-системы и суть останется.

Подобное суждение можно услышать от людей, которые имеют общее представление о сути фреймворка — как об универсальном инструменте для решения задачи. Они ориентируются на маркетинговые обещания (даже если продукт некоммерческий).

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

"Мы нашли похожий проект, где использован фреймворк А"

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

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

Фреймворк помогает меньше говнокодить

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

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

Ещё причины не брать фреймворк:

  • Вы понимаете принципы и шаблоны проектирования. Способны их воспроизвести, сохранив компактность и ясность.
  • Хотите проверить гипотезу и быстро запуститься.
  • Мыслите архитектурой, а не отдельными компонентами.
  • Вы знаете, что ранняя оптимизация приводит к задержкам в в разработке.
  • Осознаете то, как ваш выбор повлияет на дальнейшее развитие проекта.

Есть ситуации, когда фреймворк может действительно пригодится.

У любого инструмента есть история. Посмотрите какие задачи решались с помощью фреймворка. Фреймворк — не универсальный инструмент.

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

Помните, большое заблуждение считать, что фреймворк ускоряет разработку. Назовем это эффектом "уже написанного кода". Много готового, но все это не соответствует задаче.

Вам нужен фреймворк, если:

Вы "плаваете" в создании структуры проекта.

Типичная проблема проектов: свалка и не связанность. Современная IDE отчасти помогает справиться с этой проблемой, но лишь отчасти. Структурность — это самодокументация.

У вас нет представления о качественном коде.

Из первого пункта можно считать, что у вопрос оценки качества кода (кроме того, что он работает) для вас пока еще загадка. Фреймворк диктует определенные правила и имеет массу встроенных примеров. Делая банальный copy-paste вы будете писать в стиле фреймворка. Для долгосрочного проекта это хорошо.

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

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

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