Какие задачи возникают в результате отказа от использования веб-фреймворков?
Что такое фреймоворк? Это программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. В отличие от библиотеки функций, фреймворк накладывает ограничения на структуру и логику программного продукта.
Определение фрейморка (англ. framework — каркас, структура) взято из Википедии.
Веб-фреймворк служит для построения веб-приложения, в него включена логика обработки HTTP запросов, работа с FTP, электронной почтой.
Зачем нужен веб-фреймворк?
В любом языке программирования фреймворк является надстройкой над языком. Часто это весьма сложная надстройка, с очень высоким уровнем абстракции, с богатой функциональностью, позволяющая конструировать приложение из сторонних модулей, легко расширять и модифицировать под свои нужны. Также фреймворк вводит ограничения на структуру файлов, стиль оформления кода, правила по разделению логики. Вокруг некоторых из этих фреймворков возникают сообщества пользователей, пишутся книги о том, как их использовать. Цель большинства фреймворков — на сколько возможно больше экономить время на начальном этапе разработки и на поддержке готовых проектов. Но иногда из-за высокой сложности они становятся трудными в понимании, требуют долгого обучения, прежде чем их можно будет начать использовать наилучшим образом. Я, например, пока ещё не осилил Django для языка Python.
Внутреннее и функциональность устройство фреймворков отличается, но можно сказать, что какая-то часть их организована по схожим принципам, например, MVC фреймворки или RESTfull микро-фреймворки. Часть решений является улучшенной и расширенной версией более старых. С определённой долей уверенности скажу, что если знаешь как работает один из них, то сможешь разобраться и в другом, а это даст значительную экономию времени.
Ещё следует заметить, что следствием высокой сложности фреймворков является медленная работа приложения. Например, сложному приложению на базе Zend Framework требуется загрузить около сотни файлов с диска на каждый входящий запрос HTTP.
Можно ли обойтись без веб-фреймворка?
Принимая решение использовать фреймворк в разработке программного обеспечения, программист соглашается, что в итоге программный продукт будет работать медленнее, но процессы проектирования и разработки будут быстрее, а техническое сопровождение — проще. В случае сложного проекта гораздо дешевле купить более мощный компьютер для веб-сервера, чем позволить нескольким программистам топтаться на одном месте, изобретая свой велосипед.
При отказе от использования возникает ряд сложностей, которые может обойти только тот, кто уже разобрался, как то или иное решение реализовано в существующих фреймворках. Иногда разработка вызывает ощущение «изобретения велосипеда». Или колеса. Постоянно возникают вопросы «А как то или это сделать, как оно должно работать, как его закодировать?». При этот нет ни сообщества, готового помочь, ни примеров, которые можно было взять за основу, ни репозитория готовых решений, которые можно было бы подключить к проекту. Приходится заимствовать решения из открытых источников, часто — прямо из других фреймворков.
Программные решения, принятые группой разработчиков на проекте без фреймворка, несут мало пользы другим разработчикам — для них это просто информация «у этой задачи есть решение». Очень мало энтузиастов портировать решения в существующие фреймворки.
Расчёт потерь в результате отказа от фреймворка
- Постановка: мы должны разработать сервис комментирования чужих онлайн-покупок, для чего нам понадобится агрегировать данные о покупках в интернет-магазинах и давать пользователями ставить лайки 🙂 Согласитесь, это довольно сложное и уникальное веб-приложение, поэтому никакая CMS не подойдёт
- Техническое решение: опуская детали, решили делать «с чистого листа», но на базе существующего фреймворка
- Команда: три программиста, все разбираются в выбранном фреймворке, зарплата одного программиста $1000 в месяц
Команда оценила сложность приложения и выдала такие сроки:
- выпуск альфа-версии через 2 месяца
- бета-версия будет через 4 месяца
- релиз — через 6 месяцев
Итоговая стоимость работы: 6 месяцев * 3 человека * $1000 = $18000
Продолжение расчёта будет после таблицы.
Разные задачи разработки веб-приложения и их решения с использованием и без использования фреймворков
Рассматривается с точки зрения серверной разработки.
| с чем имеем дело? | а если не требуется? | а если сделать по-простому? | а как делается в фреймворках? |
| хранение данных в базах данных | не использовать базу данных вообще. можно хранить данные в файла, а можно вообще обойтись статическими HTML страницами | ограничиться одним типом баз данных | реализован одинаковый доступ к разным типам баз данных (MySQL, PostgreSQL, Oracle и другим), в некоторых — разделение баз данных на чтение/запись, горизонтальное и вертикальное деление |
| доступ к отдельным записям базы данных | работать с данными в «сыром виде» (для реляционных баз данных это запросы на языке SQL/DQL, для key-value в любом случае работа с данными в «свёрнутом виде», например JSON) | писать свой велосипед, упрощаяющий построение SQL запросов для чтения и измеение данных | реализован универсальный доступ к данным (ORM — object-relational mapping, рус. объектно-реляционное отображение, википедия или DAO — data access object, рус. объект доступа к данным википедия), и не исключающий работу с SQL |
| кэширование данных | не кэшировать данные вообще | кэшировать одним выбранным способом, например всегда все веб-страницы целиком | реализован одинаковый способ использования нескольких средств кэширования данных, с возможностью быстрого переключения с одного средства на другое: редис на мемкэш, мемкэш на файлы или вообще кэш выключить |
| перехват и отображение ошибок | выключить перехват всех ошибок | писать все в текстовый файл | реализована фильтрация сообщений по важности, запись сообщений в текстовые протоколы, отправка уведомлений по электронной почте, корректная обработка ошибок в интерфейсе |
| протоколирование/логирование | не вести логи | писать всё в один файл | реализован механизм регистрации протоколов несколькими способами (в файл, в базу, по почте), можно расширить и отправлять по скайпу, в систему контроля заданий |
| отправка электронной почты | не использовать почту | отправлять только одним жёстко заданным способом | реализовано отправление сообщений разными способами (mailsend, postfix, smtp) |
| получение электронной почты | не использовать получение почты | ограничиться одним жёстко заданным механизмом | реализовать универсальный способ получения электронной почты (протоколы imap, pop3, хуки к почтовым серверам) |
| роутинг HTTP запросов, ЧПУ человеко-читаемые URL (ЧПУ) | работать с URL по-старинке (index.php?dummy=boo&…) | сделать жёсткий прямой роутинг, написать кучу реврайтов в .htaccess | реализован прямой роутинг URL (распознавание URL), обратный роутинг (генерация URL), физический и логический |
| выполнение консольных команд | не запускать приложение из консоли | написать своё решение, позволяющее обрабатывать параметры командной строки | … |
| логическое разделение логики хранения данных, обработки и отображения (паттерн MVC или MVVM) | всё в одном файле: switch + куча if, из любой точки кода можно обратиться хоть в базу, хоть в файлы, хоть в кэш | поделить код на контролер+модель+представление или модель+представление+модель_представления и надеяться, что никто не будет из любой точки кода обращаться хоть в базу, хоть в файлы, хоть в кэш | реализован удобный механизм деления кода по зонам ответственности, есть дополнительные слои логики ля построения часто используемых элементов интерфейса (формы, списки); фреймворк может взять на себя заботу о том, чтобы слои логики не могли вызываться в обход одного разрешённого способа (код уровня «представление» не может обратиться в базу данных) |
| шаблонизация | в любой момент можно сделать echo в выходной поток | нативный способ, например purePHP | реализован универсальный способ работы с шаблонизаторами, в которые к тому же настроена компиляция и кэширование шаблонов |
| динамическая сборка страниц из частей (например, комментарии к записям блога + навигационное меню + банеры — и всё это в одном месте кода) | использовать монолитную архитектуру | … | … |
| кэширование на нескольких уровнях абстракции (данные из базы, или часть страницы или вообще вся страница) | не кэшировать, потому что пользователей мало или постоянно нужны актуальные данные | ограничиться одним способом, например всегда кэшировать всю страницу целиком | реализованы механизмы кэширования на всех уровнях абстракции, с поддержкой включения/отключения кэширования по условиям, сборку страницы из кэшированных фрагментов |
| работа с источниками извне по HTTP/FTP | не обращаться к внешним источникам | file_get_contents(‘http://copist.ru/feed/’) и нет проблем | удобные средства работы с данными через сеть, несколькими способами |
| работа с SOAP | не использовать SOAP | имитировать получение и отправку заголовков, разбирать и собирать пакеты SOAP штатными средствами или даже регулярными выражениями; отмечу, что в некоторых языках штатные средства для SOAP превосходят возможности фрейморков в других языках — например, C# и Java могут такое, чего PHP не сможет никогда. | уже готовые исследование XSD, автоматическое построение классов по XSD, прямой и обратный маршаллинг данных, автоматическая генерация SXD для методов, объявленных как веб-методы |
| автозагрузка файлов с определениями классов (для интерпретирумых языков) | включать код из файлов с фиксированными путями или всегда вообще все | хранить список путей к файлом определений классов (classmap) или договориться о жёстком соответствии пространств имён (namespaces), именах классов (classnames), именах директорий (paths) и именах файлов (filenames) (PSR-1, PSR-2) | реализованы несколько механизмов автоматической загрузки определений классов, кроме того есть возможность собрать все файлы определений в один, а также легко подключать сторонние части кода |
| модульность программной системы, например модуль комментариев, модуль блог, модуль «wiki» | не заморачиваться этим вопросом — сделать монолит | сделать хуки, как в Drupal и WordPress | реализовано деление кода по модулям, подключение разными механизмами, например, через конфигурацию, через хуки, через события; причём стандартным способом могут быть подключены сторонние модули |
| миграция данных, то есть изменение структур данных и массовая модификация данных | Данные не меняются никогда! Хотя нет, меняются… А, не — не меняются. Почти. | работать с базой данных напрямую или написать свой механизм обновления структуры данных | реализованы механизмы установки и отмены обновлений, резервное копирование |
| поддержка нескольких языков | проект на одном языке | сложные фразы соединять из более коротких, хранить всё в своём формате | удобная логика построения фраз с динамическими параметрами, числительными, хранение файлов переводов в разных форматах, совместимых с системами перевода (вариант), возможно автоматический перевод с ручным контролем (human proof-reading) |
| событийный механизм | можно обойтись без событий, если в приложении допустима жёсткая логика (вместо создать событие и надеяться, что класс А его обработает — напрямую вызвать класс А) | Да правда — можно же обойтись без событий | имеется удобный менеджер событий, всегда можно узнать — кто и на какое событие подписан, отследить обработку событий, цепочку вызова обработчиков, добавить новый обработчик, остановить ход обработки события |
| асинхронная работа, механизмы очередей | язык и так асинхронный, а долгих процессов не бывает | увеличить допустимое время ответа сервера, пользователю показать spinner | поддержка нескольких решений по работе асинхронно через очереди сообщений или иным способом |
| автоматическая генерация программного кода | для нашего небольшого приложения мы руками всё накодим | вручную «копипаст» одного куска кода в другой, но сначала надо договориться, что является идеальным куском кода | реализована базовая кодогенерация, её можно расширить и дополнить под нужды проекта, например для одинаковых списков, форм, классов |
| автоматизированное функциональное и модульное тестирование | у меня всё работает, какое ещё тестирование? | отдельные классы написаны так, что их можно проверить, но постоянно мешаются то база данных, то кэш, то echo где-попало | фреймворк поддерживает работу с средствами тестирования; в фреймворке имеются средства для временной замены базы данных, кэша, сессии и, согласно концепции фреймворка, код разделён на слабо-связанные логические блоки |
| с чем имеем дело? | а если не требуется? | а если сделать по-простому? | а как делается в фреймворках? |
Так можно ли отказаться от веб-фреймворка?
Да, можно, если проект достаточно прост.
- http://url-sh.copist.ru/ — это пример реализации сокращателя ссылок на базе шаблона проектирования MVC и MVVM, с своей реализацией ORM, роутингом URL, работой через AJAX. Его код на github.com. Если знакомы с современными фреймворками, то увидите, что код похож на Symfony, Yii, Laravel.
- http://mindpasswd.com/ — генератор легко запоминающихся паролей — на том же самом решении + добавлена мультиязычность (русский вариант http://mindpasswd.ru/).
- Многочисленные посадочные страницы (landing page) часто написаны без использования фреймворков или CMS.
Расчёт потерь в результате отказа от фреймворка
Меняем условия: Теперь наши программисты решили делать программный продукт без фреймворка, потому что а) они про них ничего не знают, либо б) читали о них только критические статьи (пример).
Команде из трёх программистов придётся придумать своё базовое решение, которым они будут пользоваться дальше. Как я уже сказал, это соглашения о структуре файлов, соглашения о правилах кодирования, о логическом делении кода. Также надо будет сделать простую и понятную версию для тиражирования блоков кода. Обычно выделяется один программист на разработку основы, а остальные предлагают и критикуют реализацию. Через 2 месяца может появиться альфа-версия, причём большая часть времени уйдёт на решение простейших вещей типа работа с базой данных, авторизация, шаблонизация и два из трёх наших программистов почти ничем не занимались.
Промежуточный подсчёт
* через 2 месяца выпущена альфа-версия, что стоило 3 человека * 2 месяца * $1000 = $6000.
При продолжении работы программисты могут столкнуться с тем, что их базовое решение не может реализовать все требования, согласованные для бета-версии. Смотрим таблицу вверху — там много пунктов, на которые придётся обратить внимание: база данных, MVC, сеть, кэш, асинхронная работа, почта, логи и так далее. Если они работают по колонке «а если сделать по-простому?», то в коде появляется много временного непонятного кода, костылей и заплаток. А если аккуратно, честно и правильно, то срок реализации увеличивается. На собственном опыте — в два-три раза. Таким образом до беты они доберутся не через 2, а через 4 или 6 месяцев.
Промежуточный подсчёт
* альфа-версия уже стоила $6000
* через 4 месяца выпущена бета-версия, что стоило 3 человека * 4 месяца * $1000 = $12000
Предположу, что от беты до релиза тоже не два месяца получилось, а четыре.
Итоговый подсчёт
* альфа-версия стоила $6000
* бета-версия стоила $12000
* через 4 месяца выпущен релиз, что стоило 3 человека * 4 месяца * $1000 = $12000
Всего $6000 + $12000 + $12000 = $30000
А планировалось $18000. Разница +$12000. Это стоимость большого выделенного сервера на целый год и даже больше.
А самое печальное — это поддержка проекта. Предположим, что этих трёх крутых программистов перевели на другой проект или через год они уволились. Каждому, кто будет заниматься поддержкой проекта в будущем, придётся самостоятельно изучить полностью весь код этого проекта, прежде чем изменять его. Документации, скорее всего не будет. В лучшем случае поддержка сможет исправлять ошибки, не рискуя делать значительные изменения.
Смотри также
- Советы как изучать исходный код незнакомого продукта
- Почему я ненавижу фреймворки (перевод) на habrahabr
- определение термина CMS (wikipedia)
- определение термина ORM (wikipedia)
- определение термина MVC (wikipedia)
- определение термина MVVM (wikipedia)
Из личного опыта. С тех пор как я поработал с несколькими из них, я не рекомендую какой-либо конкретный фреймворк или конкретный язык. Слишком большой выбор, чтобы советовать что-то конкретное. Я предлагаю написать простейшее приложение, например Hello World или гостевую книгу, на нескольких из них. Только тогда станет ясно, что удобнее.
Программы поддержки при изучении проектирования и разработки веб-приложений, новых языков программирования и веб-технологий.
Быстрая оценка текущего уровня знаний. Графики личного профессионального роста. Виджеты для портфолио. Рекоментации по эффективному повышению уровня знаний.
Pingback: Как строится современное веб-приложение | Блог о веб-разработке и веб-технологиях()