Выбор каркаса веб-приложения
07-05-2019Время чтения ~ 5 мин.PHP 4729
Любое веб-приложение начинается с идеи. Скорее даже абстрактной идеи, которая в двух словах рассказывает какую проблему клиента нужно решить. После этого идея начинает уточняться: как решить, каким способом, что для этого требуется? Таким образом формируется начальное техническое задание, где не затрагивая непосредственную реализацию, уточняется круг основных задач. На следующем этапе начинают отрабатываться базовые элементы взаимодействия, например регистрация пользователей или ключевые элементы интерфейса.
Таким образом ТЗ постоянно усложняется до тех пор, пока не станет казаться что все нюансы оговорены и можно приступать к реализации проекта.
От программистов обычно ждут строгого следования ТЗ. Если, не дай бог, к составлению ТЗ привлекают дизайнера, то всё обычно сводится к тому, чтобы соответствовать рисованным макетам, а программирование — ну после как-нибудь прикрутите. Это конечно, колоссальная ошибка, потому что перед тем, как что-то «рисовать» и серьёзно «программировать», необходимо опробовать идею/задачи в черновом варианте. Этот этап называется прототипированием.
Вместо того, чтобы рисовать красивые «рюшечки», дизайнер должен сделать примитивный каркас, который содержит лишь самые важные элементы. На такую работу уйдёт всего пара часов в той же Axure. Полученный макет очень простой и может использоваться программистом для отладки своих основных функций. Без прототипа дизайнер потратил бы неделю на красоты, а после кодеры «бодались» бы с ним по поводу «плашки не того размера/цвета». С прототипом проще — это черновик, на который не ушло много труда и времени.
Если нужно сделать новую функцию, не обязательно пытаться сделать её сразу «идеально»: вначале нужно просто хоть как-то заставить её выполнять задачу. Потому что может получиться так, что функция окажется не нужной вовсе или она должна работать по-другому. Вот когда она уже точно будет использоваться и определены все её параметры, тогда уже можно сделать её «красиво».
При разработке нового веб-приложения должны работать те же самые принципы. Нет смысла тратить время на оттачивание кода, дизайна, пока не будет готов рабочий прототип на котором можно протестировать все основные задачи.
Этот подход, кстати, довольно неплохо описывает Eric Ries в книге «The Lean Startup» (Эрик Рис «Бизнес с нуля»). Правда, там много «воды», но кто не читал, будет интересно.
Например в вашем приложении нужна работа с базой данных. Пока мы слабо представляем какие именно будут SQL-запросы и даже не уверены какая именно база будет использоваться. Можно конечно попробовать написать свою библиотеку (ну кто ж её не писал!), но здравый смысл подсказывает, что есть смысл взять что-то готовое, благо выбор большой.
Тут можно сделать ошибку. Например мы предположим, что база будет MySQL, и возьмём библиотеку именно под неё. Но со временем (сейчас мы об этом не знаем) нам нужно будет добавить поддержку Sqlite — придется искать решение для неё? Очевидно, что лучше уж взять универсальное решение, например PDO.
Но работа с базой подразумевает несколько подходов. Можно писать голым SQL, можно использовать ORM или более простой SQL Query Builder (Active Records в CodeIgniter) — какой вариант выбрать?
Когда вы пользуетесь чужим фреймворком, который, как кажется уже решил все эти проблемы, вы все равно столкнётесь с трудностями. Почти все фреймворки предлагают работу с БД и используют файл конфигурации, где указываются параметры доступа (хост, логин и т.п.). Но что делать если вам нужно одновременное использование MySQL и Sqlite? C учётом того, что последняя вообще может произвольно храниться в файле, возникает серьёзная проблема где-то хранить ещё и её конфигурацию (а их может быть множество), потому что без неё база данных просто не будет работать.
Получается забавная ситуация: есть библиотека, но она не может работать сама по себе — только через фреймворк. Это одна из «ловушек», в которую легко попасть.
Задача фреймворка всего лишь предоставить наборы библиотек для использования. Только само приложение должно решать использовать ли их и как. Даже если нужно «выстрелить себе в ногу» — никто не должен этому мешать. :-)
Таким образом лучшим решением будет взять какую-то универсальную библиотеку, или даже подобрать несколько вариантов, и попробовать поработать с ними. Тогда проявятся недостатки и будет понятно что больше подходит в итоге.
В процессе разработки будет сделано много ошибок. И вот здесь как раз и пригодится подход «микро-фреймворка». Если вы ошиблись в выборе библиотеки, всё, что нужно сделать — заменить её на другую и переписать часть своего кода. При использовании большого фреймворка такой вариант не сработает — придётся придумывать как обходить его ошибки и ограничения.
Отдельного упоминания заслуживает и выход новых версий фреймворков. Минорные версии обычно не вызывают сложностей, а вот большие обновления могут полностью сломать всё приложение. В качестве примера приведу jQuery (с php-фреймворками ситуация аналогична).
Разработчики «пилили» jQuery, которая становилась всё лучше где-то до версии 1.7 (это 2011 год). После этого кто-то решил, что настало светлое будущее и нужно отрефакторить библиотеку так, чтобы выпилить из неё «устаревший» код. Под этим подразумевались такие «допотопные» функции, как, например, определение браузера IE. Когда-то это была типичная практика — в jQuery-плагинах определять IE и под него отдельный код вставлять. Ну потому что был у нас такой браузер...
Предупреждали об этом целый год, попутно выпустив 1.8 (2012 год), а в версии 1.9 (начало 2013 г.) функции были удалены.
После этого гигантское количество jQuery-плагинов перестала работать, потому что в них были эти самые «допотопные» функции. Естественно никто ничего не собирался переписывать, потому что оно и так прекрасно работало — это просто «сломалась» сама jQuery. Разработчики jQuery тогда придумали «jQuery Migrate», дополнительную библиотеку, куда вынесли удалённые функции. Если раньше был один файл, теперь приходится грузить два, потому что без него половина плагинов (пусть и стареньких) просто не работает. Сейчас уже версия 3.4, но все продолжают пользоваться старой 1-й версией (85%, новая версия — жалкие 8%).
Если вы пользуетесь сторонними библиотеками, то всегда есть риск сломать своё приложение из-за её обновления. Но одно дело, когда меняется какой-то один модуль, а совсем другое — когда целый фреймворк: это сродни сносу всего фундамента. И важно сразу решить: будет ли этот фундамент мощным железобетонным на который можно поставить только предопределенные модули, либо это будет лёгкая платформа-шасси, на которую можно поставить уже что угодно.