Доклады

Мутационное тестирование — это метод тестирования программного обеспечения, основанный на всевозможных изменениях исходного кода и проверке реакции на эти изменения набора автоматических тестов.
Оно помогает команде убедиться в том, что автотесты действительно проверяют бизнес-логику, а не просто покрывают код.

В этом докладе я расскажу о том, как мы у себя в команде внедрили мутационное тестирование и как оно помогает нам с нашими тестами. Расскажу про наш опыт, плюсы и минусы инструмента, который мы используем для мутационного тестирования.

Все мы знаем, насколько важны тесты. Также все мы хоть раз в какой-нибудь статье, презентации или книжке видели пирамиду тестирования, где в качестве уровней выступают различные виды тестов, такие как функциональные, интеграционные и unit-тесты. Везде описаны бенефиты, которые можно получить, правильно выстроив пирамиду тестирования. Однако на практике зачастую трудно разобраться, чем отличается один вид тестов от другого, в каком случае стоит написать unit, а в каком интеграционный или, может, вообще функциональный? А сколько тестов стоит написать на одну фичу? В этом всем еще предстоит разобраться…

В ходе доклада рассмотрим следующее:
* обсудим важность тестов;
* рассмотрим на примере, на основе чего формировать тест-кейсы;
* виды тестов: функциональные, интеграционные, юнит;
* в каком случае какой вид теста использовать, как правильно их разложить по пирамиде;
* что нужно мокать в тестах, а что нет;
* как можно переиспользовать моки.

Одна из фишек проекта Customer Support — приоритизация тикетов. Команде прилетают 100-200 задач в минуту: ученик пропустил урок или его нужно разбудить, опоздал учитель, возникла другая проблема или задача. А дальше этот поток тасков нужно упорядочить по важности, пропустив горящие вперед. Тикетная система у нас выстроена круто, операторы редко приходят с жалобами. При этом часто добавляются новые команды, количество задач растет.

Расскажу про процесс приоритизации со стороны разработки и бизнеса:
* какие коэффициенты и подходы взяли, чтобы рассчитывать веса, и почему;
* теория игр — как быть, если у задачи целый набор обстоятельств. Порой неочевидных;
* заезжает новая группа, нужна стратегия. Мы сделали процесс добавления стратегий универсальным;
* ручные задачи, автоматические и отложенные. Как уживаются между собой;
* как SLA влияет на вес задачи.

В своем докладе «Версионирование API, или Единая кодовая база для всех версий» на предыдущей конференции PHP Russia'21 я коротко рассказал о том, как благодаря нашему подходу к версионированию API мы добились существенного сокращения времени прохождения тестов. Я обещал, что вернусь и расскажу о том, как же именно мы тестируем версии нашего API.

В докладе я расскажу о популярном для PHP фреймворке для функционального тестирования Behat и языкe Gherkin. О том, как с их помощью мы тестируем поведение эндпоинтов нашего API, и как мы расширили функционал фреймворка для тестирования поведения разных версий API. Как боролись с ростом времени прохождения тестов, обусловленным ростом числа поддерживаемых версий, и как победили этот рост.

В процессе поиска работы соискатели тратят время на общение с рекрутерами, которое — давайте будем откровенны — далеко не всегда приводит к желаемому результату. А что, если автоматизировать эту рутину? Мы задались этим вопросом и решили создать HR-бота, который поможет соискателям и рекрутерам упростить взаимодействие, не отвлекаться на звонки и решить все вопросы в мессенджере.

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

Также расскажу о подводных камнях, о которых мы узнали во время реализации, о том, как мы их обходили, и о пользе, которую нам принес выбранный подход.

* Как эффективно выкачивать данные из тысяч xml-фидов, добавленных не доверенными пользователями.
* Набор жизненных кейсов — что может пойти не так в процессе загрузки и парсинга.
* Безопасные подходы к парсингу и оптимизации.
* Эффективная вставка данных в ElasticSearch (OpenSearch).

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

Ниже список тезисов:
1. Как понять, в какой момент использовать тот или иной тип тестов.
2. Как писать тесты до кода.
3. Как тесты помогают продумывать дизайн кода.
4. Ошибки, которые были допущены при написании тестов: стаб-базы, очереди, использование только одного типа тестов и т.д.
5. Как можно поменять поведение внешних http-запросов.
6. Подготовка данных для тестов: 
когда фикстуры становятся неудобными, 
почему не всегда стоит генерировать данные через поведение системы, когда неудобно использовать дамп базы перед запуском тестов.
7. Запускаем тесты на codeception. Особенности функциональных тестов, тестирования очередей.
8. Особенности codeception.

* Библиотеки для работы с Photoshop-файлами на PHP.
* Устройство Photoshop-файлов, а также ошибки документации.
* Решение проблемы чтения Photoshop-файлов в других языках и особенности переноса кода на PHP.
* Как получить основную информацию о файле, направляющих и борьба с legacy-данными в файле.

Знали ли вы, что в платформе 1С есть встроенное REST API по стандарту OData? А оно есть!

Без единой строчки кода на 1С можно:
* читать или записывать практически любые данные в 1С,
* создавать документы из PHP-приложения (например, выставлять счета клиенту).

Добавив немного кода на 1С, получаем:
* 1С как headless-систему с готовой бизнес-логикой,
* 1С как сервис для формирования PDF- и Excel-документов по заранее заданным шаблонам,
* 1С как сервис по отправке юридически значимых электронных документов (в итоге проще, чем писать это с нуля на PHP).

Как вы поняли, мы пишем документооборот на PHP (Laravel) в компании, где активно используется 1С. Я с радостью поделюсь нашим опытом интеграции 1C в PHP-приложение.

Пару лет назад мне стало интересно, почему в PHP до сих пор нет дженериков, хотя RFC по их добавлению был создан еще в 2016 году. Пока я это выяснял, у меня получилось покопаться во внутренностях движка и написать библиотеку на PHP для поддержки базового синтаксиса.

В докладе я подробно расскажу, как можно внедрить дженерики в PHP.

Также вы узнаете:
* зачем нужны дженерики в слаботипизированном PHP;
* о подходах и проблемах реализаций дженериков в движке PHP;
* о системе типов PHP;
* чем может помочь типизация PHP разработчику.

С ростом проекта и количеством серверов, классический подход к деплою PHP-приложений обычно сменяется на “докеризацию” приложений и релиз в kubernetes. И, помимо новых возможностей, этот переход имеет свои особенности, которые нужно учесть.

В докладе я расскажу вам про некоторые из таких особенностей и предложу варианты решения. Например:
* как изменится ваше приложение с переходом в k8s;
* как аккуратно работать с секретами при сборке;
* какие ещё контейнеры, кроме PHP-FPM стоит запускать в каждой реплике;
* как мониторить PHP-приложение в k8s и зачем это может быть нужно;
* как изменится ваш CI/CD.

После доклада вы будете более подготовленными к переходу в облако или сможете улучшить вашу текущую архитектуру.

Когда у вас очень много кода, его связность неуклонно растёт. Всё переплетено, и нельзя взять и переместить какую-то часть в отдельный пакет — каждая часть сотнями щупалец склеена с остальным монолитом. Нет-нет да и вставят разработчики новые зависимости, срезая углы, "потому что надо было ещё вчера", и шансы распутать клубок с течением времени стремятся к нулю.

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

Мало какой веб-проект обходится без базы данных. При росте проекта и росте нагрузки зачастую первые проблемы возникают не в PHP, а в СУБД и во взаимодействии приложения с СУБД.

В нашем проекте нагрузка на базы данных составляет ~100 000 tps, поэтому взаимодействие с СУБД всегда было в фокусе нашего внимания.

В докладе хотел бы всесторонне затронуть разные аспекты данной темы:
* эффективное подключение к БД;
* управление схемой данных;
* внедрение изменений схемы данных и миграции;
* создание эффективно работающих индексов и управление индексами;
* оптимизация запросов.

Темы буду раскрывать в контексте PHP-приложений, а именно на примере связки Symfony + Doctrine.

О том, что скрывают за собой современные PHP ORM.

Как оказалось, PDO далеко неидеален. В нём несчётное количество "весёлых" нюансов и граблей, вылезающих при абстрагировании слоя для работы с базами данных.

Опыт разработчика Yii3 из первых рук.

В нашем виртуальном "ресторане" НЛМК существует единый корпоративный портал, которым пользуются больше 50 000 сотрудников Группы НЛМК в России, в Европе, в Индии и США. Когда-то он был только гостем, то есть потребителем данных, но, развиваясь, встал на кухню и начал поставлять данные.

В докладе вы узнаете, как соотносятся потребитель и поставщик информации, как перейти из гостей в повара: секретный ингредиент GraphQL на базе PHP, а также советы от бывалых о том, как внедрить GraphQL в ваш рацион, где он может вызвать несварение, а где будет максимально полезен.

Современная реальность требует современных решений. Именно поэтому все сложнее удивить кого-то словами Docker, контейнер или Kubernetes. Они являются неотъемлемой частью современной разработки приложений в компаниях.

В докладе рассмотрим вопросы запуска современных PHP-приложений внутри контейнеров, их особенности и нюансы. Также разберем типовые схемы работы с контейнерами PHP на уровне CI/CD-процессов в компании.

Мы долго учились, много работали, покупали хорошие книги и общались в чатах. Но почему нам приходится иметь дело с плохим кодом? Его же писали не менее подготовленные коллеги?!

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

Я постараюсь логически доказать, почему определённые подходы подходят лучше других, сделаю несколько очевидных выводов и удивлю неожиданными. Расскажу, как уменьшить количество кода, избавиться от бессмысленных тестов, сделать правки конкретнее, инкапсуляцию изолированней, а жизнь легче и приятнее.

Тема безопасности веб-приложений со временем становится только актуальнее.

* Разберёмся, уязвимостям какого типа, по статистике, наиболее подвержены PHP-проекты.
* Рассмотрим различные типы статических анализаторов кода по качеству выявления таких уязвимостей.
* Узнаем, какие ещё инструменты позволяют "разминировать" свой код.

Почти восемь лет, занимаясь разработкой веб-приложений, я использовал для идентификации исключительно автоинкременты. И только 3,5 года назад я попробовал UUID в одном пет-проекте. С тех пор я и моя команда в Happy Inc. почти всегда выбираем UUID для идентификации чего бы то ни было. Мы научились коррелировать сущности разных модулей по идентификатору, пользоваться преимуществами разных типов UUID, одними из первых внедрили UUID v6. Автоинкременты мы тоже не списывали со счетов, они по-прежнему хороши в определённых случаях.

В рамках этого доклада я обобщу опыт моей команды и разложу по полочкам все “за” и “против” использования UUID и автоинкрементов в PHP-приложении. Мы обсудим актуальные способы генерации и хранения идентификаторов, изучим бенчмарки для разных сценариев и баз данных и подведём новую черту с пометкой "2022" под этим старым добрым холиваром.

* Постараемся разобраться с возможностями RoadRunner.
* Рассмотрим альтернативные решения.
* Посмотрим на возможность перехода с php-fpm на RoadRunner.
* Ответим на вопрос, возможно ли его использование без фреймворка.
* Рассмотрим метрики реального перехода и профит от него.
* Взвесим плюсы и минусы перехода.

Мы часто слышим: «PHP — крутой язык».

Он обзавелся модным синтаксисом, есть типизация, улучшена производительность. Но прошлое дает о себе знать.

Многие проекты используют старые версии PHP и фреймворков, пакетов и бандлов, так как обновление и рефакторинг равно время и трудности. Мейнтейнерам пакетов приходится больше тратить времени на поддержку обратной совместимости вместо создания новых фич. Все это мешает развиваться как проектам, так и самим разработчикам.

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

А ещё обсудим:
* как писать свои правила для автоматического рефакторинга под новые версии пакетов;
* как провести рефакторинг архитектуры активно развивающегося проекта и не стопать фич-релизы;
* как справиться с перечисленными проблемами поможет инструмент Rector.

Хоть PHP и был рождён, чтобы умирать, мы часто сталкиваемся с задачами, которые требуют работы нашего кода в течение более долгого промежутка времени, чем длится простой HTTP-запрос. Это могут быть как выгрузки данных для интеграции с партнерами, так и просто приложения, которые должны реагировать на события в системе в момент их появления. Конечно же, можно предложить использовать другие языки программирования, но это увеличит стек и усложнит систему.

Достаточно давно сформировался стереотип о том, что у PHP при долгой работе "течёт" память, да и, вообще, это не его пул задач. Но он уже неактуален, а нам стоит разобраться с тем, как же можно организовать работу приложений на PHP, которые работают существенно дольше, чем несколько секунд:
* какие классы задач могут решать такие приложения;
* какими средствами можно решать такие задачи;
* какие инструменты предоставляют сам язык и его сообщество;
* когда все-таки стоит двигаться в сторону расширения стека.

Подготавливая доклад на реальных примерах, объясняющих асинхронную обработку с нуля, я понял, что примеров слишком много и выделить самый актуальный затруднительно. Серьезно, вы можете себе представить процесс в природе, который следует определенной последовательности или организованной очереди? И асинхронный не означает хаотичный.

1. Структура файлов, генерируемая при создании Laravel-проекта, проблематична для проектов сложнее набора CRUD'ов. Файлы складываются по типам, и при работе с одной фичей приходится перелопатить несколько папок. Необходимость частичного выделения функционала в отдельный сервис превращается в головную боль.
2. Предлагается новый feature-based-подход, основывающийся на группировке кода и шаблонов по фичам.
3. Для реализации этого подхода докладчиком создана библиотека, о которой речь также пойдёт в выступлении.
4. Приведя в порядок структуру файлов, можно пойти дальше и реализовать на базе той же библиотеки полноценную функциональную модульность — такую возможность она тоже даёт.

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

Обсудим:
* откуда появилось аспектно-ориентированное программирование;
* зачем нужно АОП;
* как устроено классическое АОП от Xerox PARC;
* способы реализации АОП;
* что есть в PHP для АОП;
* опыт использования АОП.

А вы знаете, почему многие считают PHP небезопасным языком?
А как сделать так, чтобы он стал безопаснее?
Каким атакам больше всего подвержен PHP и его фреймворки в современном мире?

Расскажу о том, как сделать PHP безопасным.

* С чего начать писать тесты.
* Особенности API-тестов.
* Какие инструменты использовать.
* Метрики и отчеты.
* Как не стоит делать.