Feature framework что это
Microsoft NET Framework — что это такое?
Наверное, вы знаете, что основное занятие программистов — написание кода. При этом они используют различные языки программирования, позволяющие сказать компьютеру, что он должен делать:
Но есть одна проблема — языки программирования довольно примитивны. С их помощью можно легко выполнять простые действия вроде сложения и умножения. А всё остальное требует долгой и усердной работы. Хотите вывести текст или изображения на экран? Тогда придётся написать много кода, используя самые простые элементы языка.
Как установить Microsoft NET Framework
Microsoft предлагает два вида установщиков: веб-установщик и автономный установщик. Веб-установщик весит меньше 2 МБ, и скачивает все необходимые компоненты во время инсталляции. Поэтому вам потребуется стабильное соединение с интернетом.
Автономный установщик весит около 60 МБ, и не требует доступа к интернету во время инсталляции.
.NET Framework 4.7 Веб-установщик
.NET Framework 4.7 Автономный установщик
По умолчанию NET Framework инсталлирует английскую версию независимо от того, какой вы используете установщик. Для локализации нужно скачать соответствующий языковой пакет. На данный момент языковые пакеты для версии 4.7 доступны только в виде автономных установщиков.
Перейдя по ссылке, приведенной ниже, выберите необходимый язык, дождитесь, пока страница перезагрузится, и нажмите « Скачать ».
Ещё кое-что о Microsoft Net Framework
Дайте знать, что вы думаете по данной теме в комментариях. Мы очень благодарим вас за ваши комментарии, лайки, отклики, дизлайки, подписки!
Пожалуйста, оставьте ваши отзывы по текущей теме материала. За комментарии, дизлайки, подписки, лайки, отклики огромное вам спасибо!
Фреймворк — что это такое простыми словами
Здравствуйте уважаемые читатели блога INFOZET.RU. Фреймворк — что это такое простыми словами? Поймём казалось бы сложные вещи довольно быстро и просто.
Фреймворк (framework) — это программная оболочка, так называемый “каркас” или набор инструментов нацеленный на то, чтобы ускорить ваш сайт.
Фреймворк — что это такое простыми словами?
Фреймворком ещё называют ряд программных библиотек, которые позволяют значительно упростить язык программирования, а так же в следствии этого упрощается и сам сайт (сама структура). И уже после этого соответственно ускоряется работа проекта.
Определение слова Фреймворк
В любом проекте встречаются разные типовые задачи, которые требуют нашего вмешательства. В переводе с английского framework означает каркас (это если переводить буквально). Так и получается, что фреймворк это каркас из определённых программ, и вам уже останется только соорудить “стены” для своего проекта, чтобы всё успешно работало.
Примеры фреймворка
Фреймворк это простыми словами, любая программа из библиотек, которая призвана помочь веб-мастеру или программисту. И как мы поняли, фреймворки бывают разными, и их достаточно много.
Вообще, понятие Framework не много расплывчатое значение. Но как мы поняли, в основном его используют программисты. Но его ещё используют и ряд других специалистов. Термин одинаково достаточно подходит и для объяснения того или иного контекста, и для уточнения.
Можно так же привести пример с Conceptual Framework (что в переводе означает — “концептуальная основа“). Это довольно расплывчатая структура, которая больше напоминает абстрактное значение. Его в основном используют в разработках исследования, чтобы определить существующие способы решения задач.
Другой пример, тоже связанный с данным значением. Но определяется он как Software Framework (что в переводе означает как — “программная платформа”). Его используют для того, чтобы обозначить “каркас” либо всей системы, с которой программист будет работать, либо с частью системы, или подсистемой. К нему будут относиться различные части кода библиотек, разные вспомогательные программы и другие языки сценария. Всё это призвано для того, чтобы облегчить работу той или иной разработки действительно крупного веб-проекта.
Есть ещё очень не малозначительный пример — Application Framework. Переводится как открытая и доступная инфраструктура каркаса, или приложения.
Мы уже достаточно узнали, и ответили на самый главный вопрос, фреймворк что это такое простыми словами. Теперь пойдём “вглубь”, и попробуем понять что дало бы это нам на практике.
Фреймворк — важный инструмент программиста
Для того чтобы начинающему программисту понять, нужно объяснить одну простую вещь, фреймворк что это простыми словами. И после того как он поймёт это, он уже решит: нужно ему это, или нет. Данные инструменты необязательны, но по словам самих программистов, довольно необходимы.
Мы можем более глубже понять значение этой процедуры, если обрисуем всё в примерах.
Фреймворк это простыми словами примеры:
Все вышеперечисленные примеры идут рука об руку с пониманием, и с тем, с чем придётся столкнуться программисту, и с чем он сталкивается “в полях”.
Существуют классификации фреймворков, которые будут описаны ниже:
net framework это простыми словами
Иными словами, net framework это программная платформа, которую очень многие используют и любят за её простоту, и за её необходимость.
Платформа была выпущена компанией Microsoft, ещё в далёком 2002 году. С тех времён на платформе произошло масса изменений. Она и по сей день постоянно обновляется, и рекомендуется web-программистам для пользования.
Её основа — Common Language Runtime. Это среда исполнения которая используется на разных языках. Все функции CLR так же используются на разных языках, и потому программисты по всему миру используют именно эту платформу. В основном сильное распространение идёт в Индии, где программистов стало больше, чем пожалуй там существует компьютеров в целом.
На этом в принципе всё! Мы с вами разобрали, фреймворк что это такое простыми словами. Если есть вопросы, задавайте их ниже в комментариях. А вы читали блог INFOZET.RU. До встречи!
Вам так же может быть интересно узнать: Мишпуха — значение данного слова.
Статья обновлена в 2021 году.
Фреймворк: что это?
Суть фреймворка заключается как раз в переводе слова. Это программная среда специального назначения, своеобразный каркас, используемый для того, чтобы существенно облегчить процесс объединения определенных компонентов при создании программ. Это основа, которая позволяет добавлять компоненты в зависимости от потребностей. База, на которой можно сформировать программу любого назначения достаточно быстро и без особых затруднений.
Классификация фреймворков:
Наша статья рассмотрит фреймворки, используем ые для разработки современных веб-проектов и принадлежит второму пункту в классификации.
Сравниваем CMS, чистый код и фреймворк
Если у программиста стоит задача создать сайт, ему необходимо сразу же определить дальнейшую стратегию работы. Есть три пути разработки, каждый программист может выбрать тот, который больше всего подходит под его умения.
Рассмотрим фреймворки, их типы, особенности, чтобы помочь каждому, кто захочет воспользоваться данным способом для создания сайта.
HTML/CSS-фреймворки и библиотеки: их главные особенности
Bootstrap стал столь популярным из-за огромного количества достоинств, в нем практически отсутствуют недостатки. Это не только HTML/CSS-фреймворк, в Bootstrap также включены плагины и готовые стили JS/Jquery. Знание Bootstrap часто является одним из обязательных требований работодателей.
Официальная страница getbootstrap.com
Обратите вниманию, что для изучения HTML-фреймворков вам потребуются базовые знания HTML и CSS. Изучить HTML/CSS можно на наших курсах: курс HTML/CSS, курс HTML/CSS Advanced.
PHP-фреймворки: основные особенности
Прежде чем приступать к изучению каких-либо PHP фреймворков, вам потребуются знания основ PHP. Изучите язык PHP с помощью нашего интерактивного курса PHP.
Python-фреймворки: главные особенности
Javascript фреймворки и библиотеки
Язык Javascript очень популярный в 2021 году и на нем создается большое количество веб-приложений. Javascript используют как в Frontend, так и в Backend. Что такое Frontend и Backend вы можете узнать в этой статье:
Прежде чем приступать к изучению React или VueJS вам необходимо освоить современный Javascript. Изучить современный Javascript вы можете с помощью различных онлайн-курсов, в том числе с помощью нашего интерактивного курса Modern Javascript. Начните обучение современному Javascript прямо сейчас.
Также вам потребуются знания NodeJs. О том, что такое NodeJS вы можете прочитать здесь.
Также для того, чтобы разрабатывать современные веб-приложения (веб-сайты) вам потребуются знания верстки веб-сайтов. С помощью наших курсов по HTML/CSS и HTML/CSS Advanced, вы сможете изучить верстку веб-сайтов.
О фреймворках
В сегодняшней статье поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Роман Ивлиев на примере множества проектов портала 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 сентября на вебинаре Романа. Прослушав этот вебинар вы сможете лучше сориентироваться в мире хайлоад-разработки, выбрать направления и последовательность развития себя, как специалиста, подготовить нужный и наиболее эффективный список мероприятий для саморазвития.