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

Роман Ивлиев

У сьогоднішній статті поговоримо про невід'ємною складовою великого числа сучасних веб-проектів — про фреймворках.
Роман Ивлиев на прикладі безлічі проектів порталу 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 в цілому. Приходить чоловік до знайомого ЦЕ шнику і каже: «Чуєш, чого там зараз на ринку, взагалі, круто?» — «На ринку круто — ось це». Він каже: «О! Хочу ось це». Завіса. Сльози, плач, печаль і т. д.



За великим рахунком чуваку треба, щоб це все реально працювало, йому більше нічого не потрібно. Йому потрібно, щоб це було просте рішення.

Ще є купа незв'язаних речей, які я виділив:



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

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

Звісно, щось не виходить. Ось саме оце «так» не можна зробити. Це вічний холівар, коли кажуть: «А ось тут потрібен 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 вересня на вебинаре Романа. Прослухавши цей вебінар ви зможете краще зорієнтуватися у світі хайлоад-розробки, вибрати напрями та послідовність розвитку себе, як спеціаліста, підготувати потрібний і найбільш ефективний список заходів для саморозвитку.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.