Що ми знаємо про Symfony: міфи і легенди?


Дізнайтесь більше про нові кар'єрні можливості в EchoUA. Цікаві проекти, ринкова оплата, гарний колектив. Надсилайте резюме та приєднуйтеся до нас.

Коли веб-розробника запитують про Symfony, у нього в голові, як правило, спливає певна картина, складається усталена думка. Що можна сказати про Symfony одним реченням? Це full-stack веб-фреймворк, написаний на PHP. Все так, але це не зовсім точне визначення. Поняття Symfony дещо ширше за стандартне розуміння.

Symfony – це набір автономних компонентів. У свою чергу компоненти, зв’язуючись між собою, утворюють веб-платформу, своєрідну екосистему. При цьому те, які компоненти вибирати, залежить від Вас і Ваших задач. Ви також можете скористатися мінімальним набором для створення простого додатка або прототипу, або розгорнути той самий повнофункціональний фреймворк Symfony.

Хлопці з Noveo поспілкувалися зі своїми PHP-розробниками і виділили загальні ключові моменти, які були визначені, і поставили запитання: “Чи дійсно все так добре / погано, як кажуть?”. Із цього вийшла пропонована до Вашої уваги підбірка міфів і легенд про Symfony.

Низька зв’язаність компонентів

Модульність – одна з найважливіших особливостей роботи із Symfony. Як вже було зазначено вище, Symfony являє собою набір перевикористовуваних і автономних компонентів – бандлів. У Symfony все є бандл, і все живе у бандлах – і компоненти ядра фреймворка, і код Вашого додатка. Таке архітектурне рішення надає можливість будувати додаток дуже гнучко. Крок за кроком Ви будуєте свою структуру – по цеглинці, далі Ваш додаток вже не являє собою монолітну стіну, і, щоб замінити якийсь модуль, Вам не треба руйнувати весь додаток. Кінцеву конфігурацію, зрозуміло, можна налаштувати “під себе”. Більше того, Ви можете використати окремі компоненти Symfony поза фреймворком. Даним підходом успішно користуються такі проекти, як Laravel, Drupal, Magento та багато інших.

Окремо слід зазначити підтримку Dependency Injection у Symfony як одну з головних фіч фреймворка. Використання DI знижує зв’язність і спрощує тестованість коду.

У Symfony багато готових розв’язань

Це дійсно так – розв’язання є для найрізноманітніших задач, від повсякденних до екзотичних. На сьогодні є понад 2500 бандлів, кожен з яких Ви можете підключити і використати, завдяки модульності. Якщо з якихось причин один з бандлів не підходить, його можна замінити на аналогічний, вибрати є з чого. Або ж, одночасно виправивши фатальний недолік і виконавши заповітну мрію програміста, написати свій – такий самий, але інший. Мабуть, добре мати можливість перевикористання готових компонентів і сторонніх бібліотек і водночас не бути обмеженим конкретною технологією або інструментом.

Symfony складний

Symfony занадто складний. Частково це так – у Symfony вищий поріг входження порівняно з іншими PHP- фреймворками. Відповідно, і часу на його освоєння потрібно значно більше. Новачкам доведеться непросто: використання інноваційних можливостей мови, застосування патернів проектування. Треба бути готовим до того, що вивченням тільки Symfony не можна обмежитись. Доцільно ознайомитися з технологіями та інструментами, які дозволять використати Symfony максимально продуктивно: Twig, SwiftMailer, Monolog, phpUnit, Doctrine, а також популярними бандлами, наприклад, FOS, Knp, Gedmo та ін.

Symfony спроектований дуже грамотно

Symfony вирізняється побудованою концепцією та ідеологією, але важливо розуміти, що він не дає готового і єдино правильного розв’язання при розробці проекту. Задача побудови кінцевої архітектури додатка (не забуваємо поважати стандарти!) повністю делегується розробникові й залишається на його совісті. Звідси можна виділити два наслідки: 1) досвідчений Symfony-розробник з більшим ступенем вірогідності має глибоке знання мови зокрема і володіє навичками проектування в цілому та 2) не такий життєрадісний: знайти грамотних Symfony-розробників складніше, а підготовка власних потребує часу.

Symfony робить Вас вільними

Вважаєте, що підключили бандли і можна працювати? Зачекайте, не все так просто. Оскільки фреймворк гнучкий, то і можливостей для його налаштування багато. Конфіги й анотації – все наше. У стандартному постачанні фреймворка базові конфігураційні файли вже є. Проте розробники Symfony не обмежуються yaml- файлами. Для конфігурації додатка або окремих його частин надана можливість використати анотації, конфіги у вигляді xml- або php-файлів. Єдиного стилю немає, і кожен використовує той спосіб, який уявляється йому найбільш зручним. Звичайно, є рекомендації, що використати в тій або іншій ситуації, але це не накладає на розробників додаткових обмежень, вони мають право самостійно робити вибір.

Що це свобода або хаос? Цю ситуацію можна розгорнути у будь-яку сторону. Все просто. Надаючи людям вибір, Ви покладаєте на них відповідальність. Очевидно, що за безладного використання додаток легко перетвориться на клаптеву ковдру, а якість продукту знизиться. Правильним рішенням буде таке: до початку активної стадії розробки домовитися в команді про підхід до конфігурації додатка і опису коду. Спілкування – ключ до успіху!

Symfony підходить тільки для великих проектів

Symfony повільний

Я б не назвав Symfony повільним. У рамках цієї статті ми не робитимемо виміри продуктивності, у нас немає такого завдання, але думаю, не становить великих труднощів знайти найрізномані бенчмарки php- фреймворків. Дивлячись на їх результати, стає ясно, що швидкість дії Symfony на достатньому рівні, хоча він і не є фаворитом за продуктивністю, є швидші фреймворки. Важливо розуміти, чому так відбувається. Всі переваги, які ми отримуємо від роботи з Symfony, потребують ресурсів, та й абстракція не безкоштовна. За все треба платити, і в програмуванні так само: за зручність, якість і швидкість розробки часто доводиться платити продуктивністю.

Тут відразу постає запитання: “Що має вищу ціну – вартість розробки або вартість хостингу?”. На мій погляд, легше додати сервер, у такий спосіб підвищивши продуктивність додатка, ніж знайти і додати нового розробника на проект. Зрозуміло, це абсолютно не означає, що не треба замислюватися про оптимізацію продукту і кінцеву швидкість дії. Треба, і дуже важливо завжди брати до уваги цей аспект. Не відкрию Америки, якщо скажу, що оптимізація продуктивності не є легкою задачею. Для її розв’язання слід розуміти, що відбувається всередині, і в деталях уявляти, що може призвести до уповільнення і як витримати навантаження.

Надто багато магії

Потужне співтовариство

Мабуть, цей аргумент можна почути в розмові про будь-який більш-менш популярний фреймворк або мову програмування. Кожен переконаний, що співтовариство масштабне, вкрай доброзичливе, чуйне і прихильно ставиться до кожного новачка. Як би це не звучало банально, але співтовариство Symfony насправді масштабне. Велика кількість розробників на github і stackoverflow, які відповідають на запитання (у тому числі core-розробники і розробники бандлів). При цьому спілкування не є одностороннім, будь-хто може створювати pull-request ‘и, вносити пропозиції, створювати свої бандли. Прихильникам живого спілкування слід знати, що співтовариством регулярно проводяться конференції як міжнародні, так і національні.

Підтримка і фінансування

Ще один важливий момент для open-source проекту, який не завжди виділяють, – підтримка комерційної компанії, в даному разі – SensioLabs. Компанія пропонує додаткові послуги, такі як консалтинг, навчання, різні сертифікації. Це надає додаткову упевненість у плані стабільності проекту, в подальшому зростанні та розвитку екосистеми фреймворка.

Якісна документація

Symfony не обмежує Вас у виборі, він надає свободу дій, але в той же час вимагає детального розуміння принципів роботи і покладає відповідальність за побудову структури додатка.

Суть анотацій Symfony в одному контролері:

/** * @Route ("/{id}/", requirements={"id": "d+"})  * @Method ("GET")  * @RestView (statusCode=200, serializerEnableMaxDepthChecks=true, serializerGroups={"details"})
* @ParamConverter ("user", class="AppBundle:User")  * @ApiDoc ( * description="Fetch info of a user", * requirements={ * { * "name"=" id", * " dataType"=" integer", * " requirement"="d+", * " description"="User id" *} * }, * resource=true, * section=" User" * ) */public function getUserAction (User $user){ return $user;}


Висловлюємо вдячність за наданий матеріал Міжнародній IT-компанії Noveo.

 

Київ, Харків, Одеса, Дніпро, Запоріжжя, Кривий Ріг, Вінниця, Херсон, Черкаси, Житомир, Хмельницький, Чернівці, Рівне, Івано-Франківськ, Кременчук, Тернопіль, Луцьк, Ужгород, Кам'янець-Подільський, Стрий - за статистикою саме з цих міст програмісти найбільше переїжджають працювати до Львова. А Ви розглядаєте relocate?


Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *