Рефакторинг и второе рождение проекта на примере Zend Framework 2.0

РЕФАКТОРИНГ
И ВТОРОЕ РОЖДЕНИЕ ПРОЕКТА
на примере Zend Framework 2.0

Докладчик: Алексей Пархоменко
alexey@iprojects.com.ua

Теория

Что такое рефакторинг?

— изменение исходного кода
программы без изменения его
внешнего поведения.

Теория

Проблемы рефакторинга

● потребность вносить изменения в существующий код;
● необходимость строго придерживаться поставленной
задачи;
● покрывать код проверочными тестами;

теория

Нужен ли Вам рефакторинг?

теория

Ваш программный продукт работает, но внесение новой
функциональности иногда затягивается на недели;

теория


В определенных местах Ваш код работает совершенно
не так, как Вы того ожидали;

теория



Вы часто ошибаетесь в сроках реализации поставленной
задачи;

теория



Вы часто ошибаетесь в сроках реализации поставленной
задачи;

Вам приходится вносить однотипные изменения в разных
местах проекта;

теория

“... в реальном мире все иначе ...”

теория

Рефакторинг всегда
подразумевает,
что вы производите его с какой-то целью и
опираетесь на какие-то данные строго преследуя
поставленные задачи.

теория

Например

теория

Например:
● Улучшение читаемости кода;

теория

Например:
● Уменьшение зависимостей между

определенными частями системы;

теория

Например:

● Оптимизация каких-либо компонентов системы

вследствие замены архитектурных решений;

теория

Например:

● Оптимизация каких-либо компонентов системы

вследствие замены архитектурных решений;
● и так далее;

теория

На каждом этапе вы должны
четко знать несколько вещей:

● Зачем это нужно делать?
● Какую проблему вы решаете?
● Что на выходе вы должны получить?

теория

Какие есть методы рефакторинга?
● Инкапсуляция поля (Encapsulate Field);
● Выделение класса (Extract Class);
● Выделение интерфейса (Extract Interface);
● Выделение локальной переменной (Extract Local Variable);
● Выделение метода (Extract Method);
● Генерализация типа (Generalize Type);
● Встраивание (Inline);
● Введение фабрики (Introduce Factory);
● Введение параметра (Introduce Parameter);
● Подъём поля/метода (Pull Up);
● Спуск поля/метода (Push Down);
● Замена условного оператора полиморфизмом
(Replace Conditional with Polymorphism);
● и так далее;

теория

Вспомним о тестах и их
преимуществах:

теория

Тесты предотвращают появление ошибок
в новом коде

теория

Тесты позволяют рефакторить код без
риска его сломать

теория

Тесты могут использоваться в качестве
документации

теория

Тесты улучшают дизайн кода

теория

Тесты способствуют повышению
квалификации разработчиков

теория

Тесты способствуют повышению
квалификации разработчиков

Тесты ускоряют процесс разработки

теория

Мифы о тестах:
В нашем приложении внедрить тесты невозможно, у нас
слишком быстро все меняется;

теория


В нашем приложении такая архитектура, что нам
требуется много mock объектов;

теория



Написание тестов отнимает слишком много времени;

теория




Мы не делаем код для “академиков”, нам нужны
решения проще;

теория




Мы не делаем код для “академиков”, нам нужны
решения проще;

Рефакторинг, как методика весьма дорогая для нашей
компании. Лучше тратить время программистов на создание
новой функциональности;

теория

Рефакторинг не существует без:

Сопутствующих
Тестов Инструментов

иначе это не рефакторинг и ваши действия никак не направлены
на улучшение существующего кода.

история

Под прицелом:

Zend Framework Zend Framework
1.11.11 VS 2.0.0beta3
2011-09-29 релиз релиз 2012-03-02

история

Для ZF2 были поставлены цели:

“Zend Framework 2.0's focus
in on improving consistency
and perfomance”

(фреймворк сфокусирован на улучшении
согласованности и производительности)

история

Основные проблемы ZF1:
● Неудовлетворительная производительность;

история

● Дублирование некоторой функциональности
используемых загрузчиков плагинов (plugin loader);

история

● Слишком много ответственности выдано View;

история

● Один тип исключения (Exception) на компоненту;

история

● Слишком много путей для реализации одних и тех же задач;

история

● Очень тяжелая начальная загрузка (bootstrap) приложения;
● Отдельные компоненты сложно оптимизировать из-за
длинных цепочек вызова;

история

● Очень тяжелая начальная загрузка (bootstrap) приложения;
● Отдельные компоненты сложно оптимизировать из-за
длинных цепочек вызова;
● Ресурсоемкие тесты и необходимость служебных классов
«живущих» вместе с ними;

история

Знаковые нововведения в ZF2:
● ZendDi — использует популярный паттерн в мире Java
Dependency Injection (внедрение зависимостей);

история

● ZendEventManager — построен на замыканиях
(лямбда-функиях);

история

● Иной взгляд на MVC;

история

● Иной взгляд на MVC;
● Центральное хранилище модулей
(http://modules.zendframework.com/) для повторного
использования кода, по примеру bundles для symfony;

Но следует понимать, что
PHP !== JAVA

JAVA имеет сильные стороны и большой
опыт реализации успешных интерфейсов.

Как это применимо для PHP?

практика

ZendEventManager
Менеджер событий

практика

use ZendEventManagerStaticEventManager,
ZendLogFactory as LogFactory;

$log = LogFactory($someConfig);
$events = StaticEventManager::getInstance();
$events->attach('Foo', 'bar', function ($e) use ($log) {
$event = $e->getName();
$target = get_class($e->getTarget());
$params = json_encode($e->getParams());

$log->info(sprintf(
'%s called on %s, using params %s',
$event,
$target,
$params
));
});

практика

// Later, instantiate Foo:
$foo = new Foo();

// And we can still trigger the above event:
$foo->bar('baz', 'bat');

// results in log message:
// bar called on Foo, using params
// {"baz" : "baz", "bat" : "bat"}"

практика

ZendDi
Паттерн Dependency Injection
Внедрение зависимости

практика

Цель

— выделить доступ к определенному
сервису / объекту в отдельный слой, дабы
стать менее зависимым от реализации самого
сервиса / объекта.

практика

class SomeClass
{
}

$di = new ZendDiDi();
$someClass = $di->get('SomeClass');

● Делегируем создание объекта контейнеру;

практика

class SomeClass
{
protected $_injectionClass;

public function __construct(InjectionClass $injectionClass) {
$this->_injectionClass = $injectionClass;
}
}

$di = new ZendDiDi();
$someClass = $di->get('SomeClass');

● В результате, в переменной $someClass будет новый инстанс
объекта с инициализированным свойством injectionClass.

практика

Откуда Di контейнер узнает
как необходимо инициализировать
тот или иной объект?

практика

ZfcUser/config/module.config.php
'di' => array(
'instance' => array(
'alias' => array(
'zfcuser' => 'ZfcUserControllerUserController',
'zfcuser_user_service' => 'ZfcUserServiceUser',
'zfcuser_auth_service' => 'ZendAuthenticationAuthenticationService',
'zfcuser_uemail_validator' => 'ZfcUserValidatorNoRecordExists',
'zfcuser_uusername_validator' => 'ZfcUserValidatorNoRecordExists',
'zfcuser_captcha_element' => 'ZendFormElementCaptcha',

// Default ZendDb
'zfcuser_zend_db_adapter' => 'ZendDbAdapterAdapter',
'zfcuser_user_mapper' => 'ZfcUserModelUserMapper',
'zfcuser_usermeta_mapper' => 'ZfcUserModelUserMetaMapper',
'zfcuser_user_tg' => 'ZendDbTableGatewayTableGateway',
'zfcuser_usermeta_tg' => 'ZendDbTableGatewayTableGateway',
),

/* …. */ ● модуль обеспечивает очень простую и настраиваемую
)
); систему аутентификации и регистрации пользователя

практика

Конфигурационный файл только
объектов маленького модуля
занимает 159 строк.

Любая неточность == частично
инициализированный объект

практика

Для реализации Di паттерна
ZF2 использует рефлексию
(reflection)

практика

Проблемы:

● Сложность отладки программы;

практика

Проблемы:

● Потеря производительности;

практика

Проблемы:

● Потеря производительности;
● Приложение трудно читать из-за
неочевидности какой объект отдает
Di контейнер в данный момент;

практика

Di контейнер внутри ZF2

● Используется в основе нового
взгляда на парадигму MVC;
● “Тяжелый Bootstrap” ZF1 переместился
в Zend/Mvc/Bootstrap.php

практика

Zend/Mvc/Bootstrap.php
$di = new Di;
$di->instanceManager()->addTypePreference('ZendDiLocator', $di);

// Default configuration for common MVC classes
$diConfig = new DiConfiguration(array('definition' => array('class' => array(
'ZendMvcRouterRouteStack' => array(
'instantiator' => array(
'ZendMvcRouterHttpTreeRouteStack',
'factory'
),
),
'ZendMvcRouterHttpTreeRouteStack' => array(
'instantiator' => array(
'ZendMvcRouterHttpTreeRouteStack',
'factory'
),
),
'ZendMvcViewDefaultRenderingStrategy' => array(
'setLayoutTemplate' => array(
'layoutTemplate' => array(
'required' => false,
'type' => false,
),
),
)

практика

Ваше приложение зависимо от Di
● С ростом проекта вызовы Di расползаются
по всему приложению и в какой-то степени
он становиться схож с Singleton'ом;

● Вы получаете узкое место и потенциально
жесткую архитектуру, хоть и с возможностью
подмены одного объекта другим.

практика

Cобрав все за и против –
произведем
нагрузочное тестирование

тестирование

Команда ZF2 ставила для себя задачи
улучшения согласованности и
повышения производительности.
А также заявляла о некоторых решениях:

● Переход на Namespace (пространство имен);
● Рефакторинг исключений;
● Переход ZF исключительно на автозагрузку
без использования require_once;
● Совершенствование и стандартизация
системы плагинов;


Замеры производительности
производились на железе следующей
конфигурации:

Процессор:

CPU cores: 2
CPU family: 6
CPU MHz: 2999.748
Model Name: Intel Core 2 Duo CPU E8400
Cache size: 6144 KB


Оперативная память: Операционная система:
RAM: 2011 MB Debian: 6.0.5
Linux core: 2.6.32-5-amd64

ZF2 Приложение: ZendSkeletonApplication
(https://github.com/zendframework/ZendSkeletonApplication)

ZF1 Приложение: Default Welcome Application


Окружение:

Nginx: 1.2.0
Php: 5.4.0

Php modules: Core, ctype, curl, date, dom, ereg, exif, fileinfo,
filter, ftp, gd, hash, iconv, json, libxml, mbstring,
mcrypt, mysql, mysqli, mysqlnd, pcre, PDO,
pdo_mysql, pdo_sqlite, Phar, posix, Reflection,
session, SimpleXML, soap, sockets, SPL, sqlite3,
standard, tokenizer, xml, xmlreader, xmlwriter,
zip, zlib


Тестирование через Apache jMeter
Задача

Протестировать отказоустойчивость фреймворка
при нагрузке 3000 пользователей в минуту на протяжении
10-ти минут в локальной сети.

Решение

2 ноутбука через wifi каждые 400 миллисекунд осуществляют
10 одновременных подключений к серверу;


Тесты ZF1


Результаты ZF1:

В среднем ZF1 выдавал страницу за 26ms;
Может обслуживать клиентов в минуту ~1200-1400;
Минимально клиент ждал 19ms;
Максимально клиент ждал 250ms;

Пиковая нагрузка на сервер составила:

RAM ~10 MB;
CPU ~38%-50%;
Load Average 0.39;


Тесты ZF2


Результаты ZF2:

В среднем ZF2 выдавал страницу за 102ms;
Может обслуживать клиентов в минуту ~1000-1200;
Минимально клиент ждал 47ms;
Максимально клиент ждал 341ms;

Пиковая нагрузка на сервер составила:

RAM ~20MB;
CPU ~92%-100%;
Load Average 3.98;


Под прицелом:

Zend Framework Zend Framework
1.11.11 VS 2.0.0beta3
2011-09-29 релиз релиз 2012-03-02

Из приведенных графиков видно,
что ZF2 не только медленнее ZF1,
но и весьма прожорлив по ресурсам сервера.

профилирование

Профайлер Xdebug

практика

Архитектура
ZF2 изнутри


Основная проблема
производительности
ZendDi


Основная проблема
производительности
ZendDi
● слишком много обращений за один сеанс скрипта;


Компромиссы, оптимизация?
В связи с текущей архитектурой, единственный выход,
который мне видится — выпустить Di контейнер в виде Си
расширения для PHP;


Компромиссы, оптимизация?
В связи с текущей архитектурой единственный выход,
который мне видится — выпустить Di контейнер в виде Си
расширения для PHP;

Я реализовал пробный вариант решения, в котором учтены
еще далеко не все возможные инъекции, задуманные
разработчиками, и благодаря которому быстродействие
фреймворка уже увеличилось на 20%;

выводы

● ZF2 существенно медленнее ZF1;

выводы

● Dependency injection в PHP сложно
организуемый паттерн.

выводы

● PHP !== Java — эти границы следует очень
четко понимать;

выводы

● Тестирование решает многие проблемы
выбора инструмента или методик;

выводы

● Тестирование решает многие проблемы
выбора инструмента или методик;
● Любое заявление среди разработчиков,
и мое в частности, должно быть перепроверено
вами лично и сделаны собственные выводы;

Спасибо ;)

Докладчик: Алексей Пархоменко
alexey@iprojects.com.ua

Рефакторинг и второе рождение проекта на примере Zend Framework 2.0

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Рефакторинг и второе рождение проекта на примере Zend Framework 2.0 (20)

Рефакторинг и второе рождение проекта на примере Zend Framework 2.0