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

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

1. Что такое фреймворк, и зачем их пишут.
2. Почему для некоторых языков их десятки, а для некоторых — единицы.
3. В чём плюсы и минусы применения.
4. Наиболее распространённые мифы.
5. Использовать или нет — примеры из жизни.
6. Как выбрать из множества доступных вариантов, на что стоит обратить внимание.

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

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

Я очень давно ковыряюсь в 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, или на любом замечательном языке. Если они не очень сильно разбираются в этом фреймворке, быстро у них не получится. Более того, понять, что ты разрабатываешь хорошо на том инструменте, которым ты пользуешься, можно только спустя какое-то время. Либо если у тебя уже есть какой-то специалист по этим вопросам — сходил к нему в гости. Поэтому есть комьюнити (чуть дальше про них будем говорить), и оно реально спасает.

Еще есть миф, что многие заказчики требуют конкретный фреймворк, они свято верят в то, что написанное с фреймворком будет стандартизовано, это будет все классно работать, быстро, он легко найдет людей, там все классно. Более того, под конкретные фреймворки собирают прям команды. У Бунина Олега, который организует эти конференции, есть студия по разработке высоконагруженных проектов, и очень давно у него был фреймворк на Perl. Кто-нибудь из вас программировал на Perl? Я сам программировал на Perl. И у них тоже был свой фреймворк, который был запрограммирован на Perl. Так вот, чтоб потом поддерживать это поделие, которое он отдавал людям, те люди вынуждены были искать разработчиков на Perl, потому что Perl, как известно, язык для записи, но не для чтения. Т.е. человеку прочитать то, что написал другой Perl -разработчик, достаточно сложно. В Касперском была целая здоровая система активации на этом написана, я там проработал четыре года, но так и не научился до конца читать предыдущего автора и в некоторых случаях я шел к нему и говорил: «Что это?».

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

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

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

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

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

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

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

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

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

Это, в первую очередь, на комьюнити, и на что у вас у самих, вообще, есть силы. Комьюнити — это все open source. Я сейчас не говорю про проприетарные решения, которые тоже есть. Есть коммерческие фреймворки, они стоят гозиллион денег, их поддержка стоит гозилион денег, инженеров вы под них хрен найдете. Но, тем не менее, они есть по факту. Так же, как и коммерческие CMS. Я не беру в расчет Битрикс 24, я про что-нибудь пожирнее — голландский какой-нибудь… Есть поделие, которое Касперский какое-то время внедрял, просто миллион денег стоил. C#, который сам по себе один большой жирный фреймворк. .Net и все такое. Тем не менее, насколько это решение популярно на рынке? Если в Google по названию, которое вы для себя выбрали, вы ничего не нашли, это, конечно, здорово, классный решительный шаг, но скорее всего вам это не подойдет, потому что вы не сможете найти на это документацию, вы не сможете найти людей. Вообще, это будет большая проблема.

Как давно на рынке — это важная вещь. Вы слышали, что такое хайп? Про агрессивную рекламу. Т.е. если в 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 критериев, тем не менее, когда вы их придумаете и потом аккуратно это все отсмотрите, я вас уверяю, решение окупится, и потраченное время вам тоже окупится.

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

Прекращение поддержки чаще всего означает то, что ПО перестали патчить по безопасности. Потому что уже никто этим не занимается, всем надоело, они «забили» на это и все. То, что уже произошло с Windows XP. Вот, пожалуйста, операционная система, которая сейчас де факто работает в огромном количестве банковских структур и т.д. Я это знаю, потому что к нам люди ходят с Internet Explorer 8. IE 8 умер с сервис паком 2. И это та причина, почему мы еще хоть как-то пытаемся его поддержать, потому что он есть во многих банках. XP, кстати, был сертифицирован вместе с NT ФСБ-шниками. Вот, пожалуйста, люди жили-не тужили, никого не трогали. А тут бац — и все. Т.е. любая уязвимость XP, которая сейчас найдется, может только энтузиастами какими-то исправиться. А скорее всего, будет дырень.

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

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

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

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

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

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

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

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

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

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

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

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