Что такое framework в программировании

17.04.202221.04.2022 admin 0 Comments

Веб-фреймворки для начинающих: простое объяснение с примерами

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

Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.

Веб-фреймворк — это каркас для написания веб-приложений. Он определяет структуру, задаёт правила и предоставляет необходимый набор инструментов для разработки.

Типы веб-фреймворков

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

Бэкенд-фреймворки

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

Правила и архитектура серверных фреймворков не даёт возможности разработать веб-приложение с богатым интерфейсом. Они ограничены в своей функциональности, однако вы всё равно можете создавать простые страницы и разные формы. Также они могут формировать выходные данные и отвечать за безопасность в случае атак.

Фронтенд-фреймворки

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

Все эти инструменты используют JavaScript.

Фуллстек-фреймворки

Если фреймворк решает задачи и на серверной, и на клиентской стороне, то он относится к категории фуллстек. В качестве примера можно назвать Meteor. Обе его стороны — серверная и клиентская — работают на JavaScript. Поэтому вы можете создавать и использовать для них один и тот же код. Следующая особенность — «режим реального времени». Когда вы что-то меняете в одном интерфейсе, изменения происходят и в остальных.

К фуллстек также относятся фреймворки Next.js и Nuxt. Первый создан поверх React.js, а второй работает на базе Vue.js. Такие веб-фреймворки могут быть сложными для начинающих.

Можно работать и с серверной, и с клиентской стороной веб-приложения

Фреймворки и микрофреймворки

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

Например, если ваше приложение основано на Django и вам нужны веб-сокеты, то вы можете воспользоваться микрофреймворком aiohttp. Другой пример: если ваше приложение не очень большое и вам нужна только простая маршрутизация URL и шаблоны с несложным контекстом, вы можете использовать Flask с Jinja2 (или другим шаблонизатором) вместо Django.

Архитектура веб-фреймворков

Архитектура почти всех популярных веб-фреймворков основана на декомпозиции нескольких отдельных слоёв (приложения, модули и т.д.). Это означает, что вы можете расширять функциональность, исходя из своих потребностей, и использовать изменённую версию вместе с кодом фреймворка или добавлять сторонние приложения.

Существует множество open-source сообществ и коммерческих организаций, которые создают приложения или расширения для популярных фреймворков, например, Django REST Framework, ng-bootstrap и т.д.

MVC — Модель, Представление и Контроллер (Model-View-Controller) — три составляющих каждого веб-фреймворка.

Модель MVC используется во всех веб-фреймворках

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

Особенности веб-фреймворков

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

Веб-кэширование — помогает хранить разные документы и позволяет избежать перегрузки сервера. Пользователи могут использовать его в различных системах при соблюдении нескольких условий. Он также работает на стороне сервера. Например, вы можете заметить ссылки на кэшированный контент на странице результатов поиска Google.

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

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

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

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

Приложения — фреймворки позволяют разрабатывать разные веб-приложения. Наиболее распространённые инструменты используются для создания блогов, форумов, универсальных веб-сайтов, систем управления контентом (CMS)

Как выбрать подходящий веб-фреймворк

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

Полезно также изучить сравнение нескольких фреймворков. Например, вот сопоставление возможностей Django и Ruby on Rails.

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

Как научиться пользоваться веб-фреймворками

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

Если в документации нет простых гайдов, можно поискать их на других площадках. Например, на freeCodeCamp есть бесплатный курс по React, а на сайте Tutorialspoint — туториалы по разным языкам и технологиям.

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

Источник

Начинающим программистам: что такое фреймворки и библиотеки

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

Когда человек начинает программировать, он узнаёт про фреймворки и библиотеки. Попробуем на доступных примерах объяснить, что это такое и чем они полезны. Будем использовать аналогию с постройкой дома. Это несколько упрощает реальное положение вещей, зато помогает понять разницу.

Фреймворки

Представьте: вам нужно построить дом. Можно выбрать готовый типовой проект и немного поиграть с планировкой, пока архитектор не против и вы не трогаете капитальные стены. А можно нарисовать план самому и получить именно тот дом, который хотите — даже если вы хотите цилиндрический дом со входом на втором этаже.

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

Так же работает фреймворк. Вы используете готовый шаблон и наполняете его своим кодом. Вы теряете в гибкости, зато программа работает стабильно: всё основное фреймворк берёт на себя. Под капотом фреймворка миллион нюансов: например, работа с файловой системой и базами данных, обработка ошибок, защита паролем.

Без фреймворка вам нужно будет обо всём думать самостоятельно. Это даёт больше свободы, но и больше ответственности. Если криво реализована авторизация в базу данных, через эту кривизну код смогут взломать. Если не написали обработку ошибок, программа может не работать. На языке строительства это эквивалент дома без канализации или когда в стенах не предусмотрели дырки под розетки.

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

Библиотеки

Продолжаем строительную аналогию. Допустим, с домом вы определились, но в нём теперь нужно сделать ремонт и провести электрику. Это можно сделать с помощью молотка, отвёртки, ручной дрели и зубила, а можно взять специальные инструменты — болгарку, перфоратор и шуруповёрт. Специнструменты — это и есть библиотеки. С ними задача решается быстрее, но чтобы ими пользоваться, нужно умение. Если задача простая и с ней действительно можно справиться только с молотком и отвёрткой — отлично, тогда нам не нужны библиотеки и достаточно встроенных средств языка программирования.

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

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

Мы сами решаем, как и когда вызывать библиотечные функции и что с ними делать. Библиотека — это просто набор заранее определённых функций, из которых, как из кирпичиков, можно складывать то, что нам нужно. Ещё одно интересное свойство: внутри фреймворка можно использовать другие библиотеки. Например, если вам нужен адаптивный сайт и удобная работа с формами — используйте Bootstrap для адаптива как фреймворк и подключите к нему библиотеку jQuery.

Что теперь

В одной из будущих статей потренируемся на библиотеках и фреймворках. Не переключайтесь и до скорого!

Источник

Framework — это что? Простым языком о том, что такое фрейморк

Написали статью для новичков, чтобы рассказать, что это такое и какие виды framework-ов бывают.

Framework — это что?

Из этой статьи о framework вы узнаете:

Framework это что?

Фреймворк — это структура, на базе которой можно создать конечный продукт. Это проще, чем писать весь код с нуля.

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

Framework — это тот самый план постройки продукта для разработчиков.

Разница между CMS, фреймворками и написание кода с нуля

Разбираем на примере фронтенд-разработки. Предположим, вам нужно создать сайт. Есть 3 подхода, которые можно использовать: написать код с нуля, использовать framework или использовать CMS.

Что такое framework?

Framework — это набор шаблонов, заготовок. Каркас будущего проекта, на который разработчик может нанизывать дополнительные функции и фишки, которые нужны проекту.

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

Плюсы использования framework

Минусы использования фреймворков

О фреймворках

В сегодняшней статье поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.

Роман Ивлиев на примере множества проектов портала banki.ru, а также заказной разработки в студии крупных проектов Онтико. Рассмотрим следующие темы и поищем ответы на вопросы:

О фреймворках

Роман Ивлиев (Банки.ру)

Я очень давно ковыряюсь в IT и прошел путь от инженера до директора за 10 с лишним лет.

Про что мне с вами сегодня хотелось поговорить?

Зачем, собственно, пишут эти замечательные фреймворки? Почему их такое бешеное количество (кто этим занимается, тот наверняка знает, что они есть практически в любом языке)? В чем плюсы-минусы их применения? О наиболее распространенных мифах и о том, на что можно и нужно обращать внимание при их выборе.

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

Перед тем как пробовать у себя то, о чем я вам сейчас наговорю, лучше сначала попробуйте у соседа, потому что, естественно, лучше пусть у него потом что-то болит, чем у вас.

Тем не менее, зачем пишут фреймворки? Почему их десятки, а для некоторых языков даже много десятков.

Вот картинка. Кто узнал себя? Кто-то еще и чем-то самодельным пользуется — есть конторы, которые сами чего-то наделали крутого. И я признаюсь — в каждой из контор, в которых я работал, был свой фреймворк. Причем, в Банки.ру у нас есть фреймворк, который построен на базе Битрикса. Поэтому про боль я могу говорить долго. У нас есть Битрикс образца 2008-го года, который прекрасно выполняет свои задачи, в нем очень мало осталось от Битрикса, кроме имен, классов и кучи булшита, который туда напихали за долгие годы. Но тем не менее.

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

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

Это, наверное, топ-4, почему их пишут:

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

Есть еще пара моментов, почему это делают. Например, потому что «тот, что есть, он плохой». Это на моей практике такой решительный аргумент. Говоришь: «Ппочему ты взял фреймворк А, а не Б?» — «Б — плохой». «Почему?» — «Потому что». Про это тоже чуть позже поговорим.

Есть еще один момент — а кто не начинал писать свой? На моей памяти каждый разработчик… Есть еще, кто не начинал писать свой фреймворк? Есть. Это на самом деле не стыдно, и я с большим уважением отношусь к тем людям, потому что если ты уже умеешь программировать, то писать свой фреймворк — это просто трата времени. Потому что возьми тот, который уже кто-то за тебя написал, допиши его, и это будет гораздо быстрее, эффективнее, и ты решишь те же самые задачи.

Я не знаю, может это связано немного с разницей в поколениях. Но во времена, когда я только начинал всем этим безобразием заниматься, написать свою CMS и свой фреймворк — это считалось, вообще, делом чести. Т.е. если у тебя нет своей CMS — ты лох. Если у тебя нет своего фреймворка, после того, как ты написал свою CMS — ты, вообще, лох в квадрате. Более того, время спустя люди, которые со мной выросли из того поколения, сейчас занимаются примерно тем же самым – они все равно пишут свои фреймворки. Потому что чужой — плохой, потому что тот, что есть, он плохой.

Плюсы и минусы. Казалось бы, решений вагон. Давайте будем искать.

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

Посмотрим, какие плюсы, исходя из того, для чего их пишут.

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

Можно на этом фоне ускорять разработку. Потому что ты не программируешь свои, например, 10 методов, ты берешь готовые. Если есть документация, соответственно. О документации тоже поговорим.

Есть шансы, что можно сделать что-то одинаковое. Если у вас, например, есть в компании 10 проектов, то есть ненулевая вероятность того, что решая задачу в одном проекте, пользуясь фреймворком, который задал вам тот самый каркас, вы можете потом спокойно (условно спокойно) тащить эти разработки в соседний проект. При этом вы экономите время, силы, но не экономите нервы. Почему? Не потому что он плохой, а потому что люди на самом деле разные, и фреймворк — это инструмент. Если мы рассмотрим в качестве альтернативы молоток, то кто-то молотком умеет забивать гвозди, кто-то молотком умеет отбивать пальцы — казалось бы, один и тот же инструмент, но эффект прямо противоположный. С этой штукой то же самое. Человек, опытный, человек, который знает, как этим пользоваться, спокойно решает задачу. Чаще всего, не думая о том, что все остальные люди, которые потом этим будут пользоваться, могут немного отличаться по квалификации, по отношению к жизни, религии и по всем другим причинам.

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

Подразумевается, наверное, что люди, которые выкладывают фреймворки (не абы какие, а вот те, которые были на картинке в начале прещзентации) — профессионалы. На той картинке были собраны одни из самых популярных фреймворков на PHP, Python, Java и JavaScript. Вещи, которые разрабатываются почти промышленно, подразумевают, что разрабатывают их профессионалы, поэтому, когда вы это решение берете в руки, вы в целом можете быть уверены, что с вероятностью почти 100% то, что там написано, оно работает.

Минусы. Что такое фреймворк? Это груда чужого кода, которая иногда документирована, иногда не очень документирована, иногда документирована не совсем корректно. И самое главное, что не всегда понятно, как это работает. Т.е. если вы берете большой толстый фреймворк, разобраться в том, как реально в нем что-то происходит, достаточно сложно. Поэтому в ситуации, когда вы упираетесь в тормоза (как любят говорить «что-то тормозит»), то чтобы понять, что тормозит внутри вот этой коробки, нужно приложить определенные усилия. Даже если вы поймете, что в этой коробке работает не так, переписать эту коробку — это тоже определенные усилия. Потому что каждый фреймворк накладывает на разработчика некий стиль программирования. Можно взять очень крутой фреймворк, и программировать на нем настолько бездарно, что результаты вашего творчества перечеркнут все, что было заложено этими замечательными людьми-профессионалами, все их идеи.

Еще минус — надо переучиваться. Даже если вы берете фреймворки в рамках одного и того же языка программирования, то они на самом деле очень сильно друг от друга отличаются. Если взять на PHP какой-нибудь Symfony, как они внутри устроены, как нужно ими пользоваться — это совершенно разные диалоги. Когда, например, в объявлении о работе пишут, что «нам нужен программист на таком-то фреймворке» — это специально пишут. Потому что, если вы пишете на другом фреймворке, то у вас уже деформированное сознание, скорее всего. У людей, в принципе, деформируется сознание, когда они долго работают с одним и тем же. Если вы, например, долго-долго программировали на Ассемблере и умеете в голове переворачивать систему исчисления из троичной в 25-тиричную, то вряд ли вы что-то простое после этого сможете сделать. Вы уже обречены делать сложное. То же самое с фреймворком — есть очень простые, очень легкие каркасные решения, которые вот так вот, на раз-два программируются, а есть реально штуки, которые даже специалистам очень сложно заставить работать нормально.

Таким образом, вы попадаете на некий крючок, связанный со всеми предыдущими минусами. Т.е. если вы в своей компании разрабатываете огромное количество чего-то, используя один из фреймворков, то шансов перейти на другой у вас практически нет. Либо у вас очень добрый бизнес, или вы стартап, который готов жертвовать ночами, 25-ый час и т.д. Потому что по-разному все. Во многих языках, даже в той же самой Java, заложена разная идеология — там разные способы обработки данных, по-разному все это подходит. В итоге, вы становитесь заложником. По сути, так же, как с языком — если вы начали писать на PHP, то вы и будете дальше писать на PHP. Либо у вас есть сервисно-ориентированная архитектура, и суть в том же самом — вы можете брать кусками и переписывать. Пожалуйста, она вас спасет. Все остальное не спасет.

Есть мифы. Связанные с тем, что в первую очередь, человеку свойственно верить в доброе и вечное. Мало кто начнет утверждать, что «Все тлен, PHP — тлен, Perl — тлен, Go — тлен, все тлен. Common Lisp — наше все! Напишем на Common Lisp свой язык, на своем языке напишем свой фреймворк, и будем пилить на нем весело и задорно, зато все будет как «я хочу», и все другие будут просто восхищаться». Тем не менее, есть частые мифы и это из жизни, на самом деле. Это те штуки, с которыми реально пришлось столкнуться лбами. Т.е. казалось бы, разрабатывают профессионалы…

Миф 1-ый — безопасность. Даже несмотря на то, что фреймворки разрабатываются профессионалами, несмотря на то, что некоторыми из них пользуются миллионы людей, тем не менее, это открытый код. Безопасность — это бич открытого софта, потому что вы официально анонсируете патчи по безопасности, иначе как про них народ узнает? Вы берете и пишете на сайте: «Вот, мы тут нашли дырку… Пожалуйста, кто не успел защититься, кто не успел обновиться, тот попал». Разработчиков сторонних — вагон, вы можете схватить чужое решение, с какого-нибудь плохого GitHub’а, на котором лежит плохой код (наверняка такой где-нибудь есть). В принципе, из-за этого изобилия вы можете спокойно попасть в ситуацию, когда вы совершенно целенаправленно своими собственными руками в свой собственный код впихиваете чей-нибудь експлойт… Безопасность — вещь важная. Многие из вас тестируют безопасность своих приложений?

Вот, собственно, вам и ответ, почему это косяк. Потому что, казалось бы, решение готовое, решение классное, решение работает, все здорово, запрограммирую. Потом ба-бах, и ваши данные куда-нибудь утекли, ваш интернет-магазин почему-то начал продавать по 1-му рублю, или вот базы данных недавно опубликовали с телефонными номерами, типа «мы в соцсетях нашли их номера». Ага, нашли в соцсетях. Нашли в соцсетях админа, которому купили пиво, который обновил какой-то софт наверняка.

Классный миф про инженеров. Все считают, что если у нас все стандартизованно (все же пишут на работе стандарт, регламент), то мы легко заменим инженера. Это же классно — полный рынок инженеров на Haskell, например. Полно инженеров. Открываете HeadHunter — просто толпы инженеров на Haskell мечтают поработать в вашей компании. Это классно работает при условии, что вы только-только начали. У меня 35 инженеров, и у нас есть стандарты на разработку, еще у нас популярный фреймворк, и проект у меня уже давно начат, ему 11 лет, и я хочу сказать, что время входа человека в команду без ментора, старшего, который просто так сидит и говорит, что делать, ну, месяц. С ментором — 2 недели. И плюс еще ищешь черти сколько, потому что у меня есть то, что принято называть зоопарком. Мы пишем на PHP, у меня есть Битрикс, Symfony, двух версий каждая из того, что я назвал до этого, и еще на фронте у меня есть такой же список – штук семь, я даже сейчас все и не вспомню. Тем не менее, даже если это все хорошо работает, фиг вы быстро найдете инженера. Потому что каждым инструментом можно пользоваться так, как тебе хочется — инженер А, который программирует на каком-то Java фреймворке на Spring’е, пишет вот так, инженер Б — пишет вот так. И когда эти два парня встречаются, первое, что начинает говорить второй парень: «Нет, ну так нельзя делать, давай, я сейчас все перепишу по-быстренькому», тем самым он вышибает третьего парня, который, вообще, только пришел, он молодой. Он смотрит-смотрит на этих двух людей, и говорит: «Блин, да все же работало?».

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

Все говорят о скорости разработки: «Сейчас мы быстренько возьмем фреймворк, фреймворк классный, фреймворк быстро работает, мы по-быстренькому прикрутим, завертим, и все у нас быстренько пойдет». На самом деле все это хорошо работает при условии, что вам нужно типовое решение. Если вам нужно не типовое решение, фиг вы найдете подходящий фреймворк. Например, если вам нужно тупо отправлять файлики и что-то там делать — это хорошо, а если у вас на пути встает какое-нибудь устройство, которое перестает адекватно реагировать на http, и записывать нужно уже не в одно, а в 121 место, вам все равно придется писать все самим. И тогда вы попадаете в известную историю, когда у вас есть то, что работает, вы говорите, что это работает плохо, потому что предыдущий фреймворк плохой, постепенно на базе этого фреймворка, вы начинаете строить свой.

На самом деле, я везде немного утрирую, естественно, потому что не так все плохо, фреймворками пользуются и пишут, но боль, определенно, есть. И на самом деле все это классно, когда у вас есть специалисты. Группа лиц, собранных в одном месте, работающих над одной задачей, взявших инструмент, но не умеющих им пользоваться, все равно быстро ничего сделать не смогут. Даже если они все очень круто пишут на PHP, например, или на Phyton, или на Java, или на любом замечательном языке. Если они не очень сильно разбираются в этом фреймворке, быстро у них не получится. Более того, понять, что ты разрабатываешь хорошо на том инструменте, которым ты пользуешься, можно только спустя какое-то время. Либо если у тебя уже есть какой-то специалист по этим вопросам — сходил к нему в гости. Поэтому есть комьюнити (чуть дальше про них будем говорить), и оно реально спасает.

Есть еще мода. Мода — это страшная вещь, которая касается не только фреймворков, но и IT в целом. Приходит человек к знакомому IT’шнику и говорит: «Слышишь, чего там сейчас на рынке, вообще, круто?» — «На рынке круто — вот это». Он говорит: «О! Хочу вот это». Занавес. Слезы, плач, печаль и т.д.

По большому счету чуваку нужно, чтобы это все реально работало, ему больше ничего не нужно. Ему нужно, чтобы это было простое решение.

Еще есть куча несвязанных вещей, которые я выделил:

Фреймворк, естественно, плохой, потому что он что-то не может из коробки. Ну, потому что вряд ли вы найдете комбайн. Кто-нибудь читал на Хабре шикарную статью про фабрику фабрик для изготовления универсальных молотков? Вот здесь примерно то же самое. Естественно, человечество хочет сделать что-то универсальное, потом оно понимает, что что-то универсальное никому не нужно. Оно начинает делать механизм для построения чего-то универсального, потом механизм для построения построения и т.д. Это замкнутый круг.

Если так уже умеет другой фреймворк, то это тоже плохо. Поэтому, например, все, что сейчас рождается, на таких более-менее серьезных языках
программирования, практически, никогда не выживает, потому что «все уже было сделано до нас, чего этим пользоваться, нафиг надо привыкать» и т.д.

Естественно, что-то не получается. Вот именно вот «так» нельзя сделать. Это вечный холивар, когда говорят: «А вот здесь нужен active directory, а он вот так вот не через activ, а через прямые SQL-запросы, вот так вот все круто, память экономят, все здорово…». Да фигня все это. Все делают одно и то же. Плюс-минус. Есть решения специализированные, есть решения вендоровские, которые заточены под какие-то конкретные решения.

И последний пункт, это реально боль.

Я вам как менеджер говорю. Это самая большая проблема, когда у вас есть сильный инженер, который давно сидит, он уже умеет очень сильно на этом всем программировать и в конечном итоге: «Все, что вы мне предлагаете, это все фигня». И объяснить ему, почему, например, его фреймворк, не его фреймворк и т.д. — это достаточно сложно, потому что реальных критериев отбора очень много, сейчас мы по ним пробежимся.

Как это все выбирать? Конкретных рецептов нет, потому что, естественно, задач бешеное количество. Тем не менее, на что имеет смысл обращать внимание.

Как давно на рынке — это важная вещь. Вы слышали, что такое хайп? Про агрессивную рекламу. Т.е. если в Google внезапно в первых строчках вылезает какое-то решение, которое на рынке не проболталось еще и года, у которого сайт сделан в виде этих продающих сайтов, которые скролишь-скролишь-скролишь — «скачать». Эти длинные. Скорее всего, это тоже какая-то фигня. Либо это кто-то из Javascript-чуваков слепил какой-то новый супер-пупер модный фреймворк, который решает все проблемы предыдущих супер-пупер модных фреймворков, которые он же написал в предыдущей конторе, когда работал. Либо это какая-то фигня.

Ваш опыт — очень важно. Если вы до этого ничего не программировали сложного, то если вы возьметесь за вот этот дрын, которым можно и копать, и гвозди забивать, и все, то, скорее всего, вы обречены на провал.

И время. Насколько вы готовы во всем этом поковыряться. Потому что, я за другие языки не скажу, но в PHP, например, есть четкая градация фреймворков (плюс-минус) по скорости ввода человека в суть процесса. И есть такой Макаров Саша, один из разработчиков Yii, который утверждает, что у Yii вход прям чуть ли не в разы быстрее, например, чем в Symfony войти. Эта штука тоже важна, потому что вам нужно врубаться, либо вам нужно уже сейчас взять и бежать-копать.
Про «бежать и копать» есть совершенно классная штука, например, если вам очень-очень быстро-быстро нужен интернет-магазин, то его можно очень-очень быстро-быстро купить готовый. И не надо, вообще, его писать. И за время, пока вы будете его раскручивать, вы напишете свой. Тем не менее, если у вас нет времени на изучение, зачем за это, вообще, браться, зачем?

Процесс разработки. Сколько лет, вообще, планируется эту штуку поддерживать? У каждого фреймворка, вообще, у любого open source софта есть как в DNS time to live, что называется, т.е. время, которое эту штуку потенциально готовы поддерживать. Кто-то анонсирует это, кто-то не анонсирует, кто-то показывает, кто-то не показывает. Где-то есть прям четкий, как у взрослых, time line, когда «30 декабря 2016-го года выпустим вот это, потом вот это и вот это». Это признак того, что продукт качественный. Если чуваки просто пилят и ничего не говорят, то, скорее всего, этот продукт не очень качественный. Но если мы возьмем топ 5-10, они все плюс-минус одинаково анонсируются, другой вопрос, что за сроками этими никто не следит.

Автоматизация, документация, стилевые библиотеки, т.е. например, где-то прикручена поддержка Bootstrap’а из коробки, где-то поддержка Bootstrap’а из коробки не прикручена. Если вам нужно что-то сделать быстро и «на коленке», то, конечно, будет прикольнее взять то, что у вас с поддержкой Bootstrap’а, потому что она тоже уже есть, не надо будет мудохаться.

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

По большому счету, их навалом, и есть даже целые хранилища этих навалов, где можно посмотреть, там даже есть рейтинги — можно в GitHub’е посчитать звездочки. Это то, что нужно обязательно учитывать в процессе выбора. Если вы можете, например, взять фреймворк, взять три каких-то его дополнения, прикрутить простенькую мордочку и разом решить все свои проблемы — это то, что доктор прописал (с моей точки зрения). Если вы вынуждены искать ночами, гуглить так, что Google вас уже просто банит, говорит, что вы бот, и показывает вам капчу на слово «фреймворк», например, то, скорее всего, что-то не то.

Тестирование — тоже очень важный момент. Не все фреймворки одинаково подлежат тому же юнит-тестированию. Есть фреймворки, которые поддерживают его легко и замечательно, есть такие, с которыми вы будете кривляться и проще, вообще, отдельно все написать. Есть со всякими юнит-штуками — JUnit, PHPUnit и др. — уже все это завязано. Вам уже ничего делать не надо. Это все уже есть. Если тестировать код, который вы написали, сложно, т.е. если у вас, например, для того чтобы протестировать какой-то код нужно сил приложить больше, чем его написать, зачем вам такая ерунда? Что вы с ней будете делать? Если вы, конечно, не какой-нибудь там mail.ru, например, компания, в которой здоровенный отдел тестирования, который может себе позволить много тестировать. Скорее всего, в вашем отделе тестирования только вы. Даже несмотря на то, что вы не инженер по тестированию. Сейчас с учетом всех псевдокризисов и т.д. все-таки на тестировании народ экономит, как может.

Производительность и отладка. Эти все вопросы, перед тем как что-то выбрать, надо бы посмотреть. Есть бенчмарки практически по всем языкам, по всем фреймворкам, которые показывают, что, например, пирамида Python’овская работает гораздо быстрее, чем непирамида Python’овская. Если вам это важно, то, пожалуйста, смотрите, выбирайте.

Есть ли обратная совместимость? Например, что сделали с той же Yii на PHP. Они версию 1 сделали не совсем совместимой с версией 2. Отличия не принципиальные, но тем не менее, взять и просто обновить фреймворк с версии 1 до версии 2, чтобы поиметь все плюсы версии 2, фиг получится. А, например, если вы берете какой-нибудь Symfony и программируете без деприкейтед методов, которые заранее были объявлены, то вы потом просто возьмете, накатите свежую версию и получите все плюшки.

В принципе, такая же история, как с языками программирования, когда у вас язык мигрирует. Python возьмем — «двойка» с «тройкой» что-то не очень дружат. Языки разные, протоколы разные в API этих фреймворков. Сейчас, например, модно выкидывать xml, везде вкидывать json. Т.е. ваше поделие было сделано с учетом того, что там xml, теперь бац — json.

Как с этим бороться? Понятно как — нужно, чтобы все было гибко, логично, слоисто и сервисно. Если вы хотите и планируете все это развивать долго и замечательно.

На конференции, как раз, был доклад про то, что нужно заранее все это строить и думать. Про то, что у вас может вот тут отвалиться, вот тут отвалиться.
Даже несмотря на то, что сейчас у нас в Банках.ру есть Битрикс этот замечательный, который работает, мы на него смотрим, хихикаем, но не трогаем, потому что он работает. И пусть работает. Все новое мы делаем рядом. По сути, можно взять любой язык, потому что мы сервисно-ориентированную архитектуру запилили, придумали свои протоколы, уже как бы решили, что мы на json останемся, больше ничего делать не будем, и тем не менее.

Еще классный критерий — есть ли что-то работающее на рынке с использованием этого фреймворка? Более-менее серьезное, не какой-то там чатик клана какого-нибудь в world of tanks, а что-нибудь более навороченное, какой-нибудь солидный магазин запчастей и т.п. Скорее всего, если люди эту штуку используют, то почему нет?

Более того, современные социальные сети позволяют найти человека и спросить: «Слышишь, как у вас там, вообще, дела обстоят?». Они, скорее всего, всю правду честно расскажут.

Я, например, не стесняюсь никаких «косяков» наших, и если кто-то придет и спросит, как мы решили вопрос перехода с Yii 1-го, на Yii 2-ой, я скажу, что мы отказались от Yii и перешли на Symfony. Потому что у меня есть пара сильных инженеров, которые убедили меня, что возможности, которые предоставляет Symfony (это один из PHP-фреймворков), нам более подходят, чем те, которые у нас есть. Мы очень долго с ним бодались. Вообще, вопрос появления фреймворков — это совершенно отдельная штука. Они у нас появились случайно. Заказали на out source проект и забыли спросить, на чем они его «запилят», а когда они его уже «запилили», оказалось, что они его «запилили» не на том, на чем у нас все остальное было «запилено». Но не выкидывать же, поэтому оставили. Так появился еще один фреймворк.

Критериев, на самом деле, может быть до фига. Т.е. вам нужно удобство работы с данными — обращайте на это внимание. Можно почитать, народ пишет в интернетах кучу всякого. Правда, очень много ерунды написано, поэтому лучше сравнивать несколько ресурсов.

Самое главное, что ваш критерий будет основным. То, что нужно вам. Если вам, например, вообще все не уперлось, а нужно очень быстро, очень скоро, то нужно что-нибудь со словом «react», наверное, взять и наплевать на то, что у вас нет каких-нибудь функций — вы их как-нибудь допишете.

В заключение про камушки, которые собираются.

Это как в языках программирования. Перед тем, как выбирать что-то, перед тем, как спорить, ругаться и т.д., просто садитесь и, как уважаемый коллега из Акрониса, проводите сравнительный анализ фреймворков.

Делается это по старинке — рисуется табличка, в табличке указываются критерии, которые вам нужны. Критериев может быть n, где n лучше бы было побольше.
Если у вас есть время, пусть это n будет 20, например. Сначала нужно будет посидеть, покряхтеть придумать эти 20 критериев, тем не менее, когда вы их придумаете и потом аккуратно это все отсмотрите, я вас уверяю, решение окупится, и потраченное время вам тоже окупится.

Возможность следить за обновлениями. Если уж все-таки случилось чудо, вы что-то выбрали и решили не переходить пока никуда, то лучше бы смотреть за тем, что происходит с этим поделием, потому что в ряде случаев о прекращении поддержки вы можете узнать последним. А что означает прекращение поддержки?

Поэтому нужна стратегия. Стратегия выбора фреймворка на самом деле вот такая:

За все эти годы, сколько я кривлялся со всеми этими выборами, ничего более умного в голову не приходит.

Садишься, понимаешь свою задачку. Понимаешь, чего ты реально можешь — у тебя есть два-три-четыре инженера, которые умеют программировать.

Я вам сейчас расскажу, как мы шли к Symfony. Мы начали собирать инженеров, которые умеют программировать на Symfony. У меня сначала он был один случайно, так получилось, он не ушел. Потом их стало два, три, сейчас их стало целых пять, когда их стало пять, стало понято, что эти пять могут научить остальные 15. Когда он был один, он не мог этому научить. Сейчас мы почувствовали себя спокойно, мы попали в ситуацию, которую я показывал на одном из слайдов — мы оценили свои возможности, поняли, что да, мы можем. Мы провели этот самый сравнительный анализ, мы запустили пару пилотов.

Это тоже, кстати, классная тема — вы можете попилотить, посмотреть, погонять свои собственные бенчмарковые тесты. Берете какой-нибудь AB от Apache — самый простой апачевый бенчмарк, строите примитивное приложение из каркаса, прямо из коробки, в одну консольную командочку все это делаете, кладете на одинаковую виртуалочку, и все в вашей жизни становится хорошо.

Перспективы проекта — тоже очень важная вещь. Если вы сейчас не знаете, что с ним будет, но вам уже нужно получать profit сейчас, ну их на фиг эти фреймворки. Вы лучше сразу придумайте архитектуру, как бы вы хотели, чтоб она выглядела, а потом купите Битрикс 24 облако и все там уже запрограммируйте по-быстренькому мышкой.

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

Там еще есть profit — важный пункт, до него нужно дойти, т.е. по кругу вот так вот ездить.

Важный момент — если говорить про нагрузку, то фреймворк — это все-таки сложная штука. Сама по себе она, конечно, удобная, гибкая, она решает свои вопросы, но если ваш проект начинает нагружаться, скорее всего, вам придется от этого всего отказываться. Скорее всего. Возможно, нет, но скорее всего, да. Потому что только на прогрев этого фреймворка у вас будет тратиться память и все такое, все эти микросервисы, про которые тоже на конференции рассказывали…

В ряде случаев это работает. Как у нас — у нас не очень большая нагрузка, хотя на самом деле, около 500 тысяч уникальных посетителей в сутки мы принимаем, и сервисная машина — это одна машина, это просто, физически один сервер. Он один умеет обслуживать достаточно… Еще есть Битрикс на семи серверах — сзади такой притаился, но это его сервера, он на них же и живет. А то, что новое — новое просто, чтоб понимать. Т.е. взяли, переписали технологию, получили прирост по производительности примерно раз этак в семь. Сейчас мы еще перейдем на PHP 7. Это о языках и версиях, и парни из Badoo говорят, что вообще прямо рай наступит. Ну, не знаю, мы проверим. При переходе с 5.3 на 5.6 рай почти наступил, т.е. мы процентов 30% поимели. Тут говорят, еще 60% поимеем.

Фреймворков столько, что времени не хватит их всех детально изучить. Как же выбрать? Какие критерии использовать? Что стоит изучить, а что стоит лишь просмотреть?

Мы продолжим изучение этой темы 6 сентября на вебинаре Романа. Прослушав этот вебинар вы сможете лучше сориентироваться в мире хайлоад-разработки, выбрать направления и последовательность развития себя, как специалиста, подготовить нужный и наиболее эффективный список мероприятий для саморазвития.

Источник

Интернет-портал linguist-school.ru

Что такое framework в программировании

Веб-фреймворки для начинающих: простое объяснение с примерами