Всем привет!
15 февраля в офисе Badoo прошла очередная встреча PHP-разработчиков, посвященная теме легаси. Целый день мы слушали рассказы об опыте крупных компаний, общались и делились болью.
Получилось рассмотреть проблему с нескольких сторон:
Под катом делюсь видео и слайдами с этой встречи. Конечно, очень много ценного осталось в кулуарах и не вошло в отчет, так что приходите в нашу уютную группу поболтать о тяжелой жизни пэхэпэшника, обсудить доклады или просто за советом :)
Основополагающий рассказ о том, как провести рефакторинг legacy-кода без влияния на работу приложения, протестировать функциональность и производительность, а также бесшовно переключиться на новую версию на проде.
Подход SuperJob — последовательная борьба с устаревшим кодом. Тимлид команды «Платформа» рассказал об API как о способе изолировать плохой код от хорошего.
Проблема, которую мы решали, выглядит так: высокооплачиваемые инженеры постоянно читают мёртвый код. Данил из команды серверной разработки, о других проектах которой мы недавно рассказали. Его история — о том, как мы автоматизируем борьбу с легаси и какие методы применяем, чтобы контролировать его появление.
Распил монолита — верный способ найти устаревшие решения в собственном коде. Павел рассказал, как в Авито избавлялись от легаси:? выносили словари и другую статику, выделяли интерфейсы, упрощали иерархию наследования и совершенствовали покрытие тестами.
Несмотря на то, что тема DDD довольно непростая, да и последний доклад — испытание не для каждого, у Виталия здорово получилось на примерах и буквально на пальцах объяснить, как реанимировать устаревший код с использованием паттернов предметно-ориентированного программирования.
Фотографии с митапа лежат в наших группах VK и FB.
Анонсы новых событий проще всего получить в Telegram, подписывайтесь.
Спасибо всем, кто поддержал встречу, было здорово!
15 февраля в офисе Badoo прошла очередная встреча PHP-разработчиков, посвященная теме легаси. Целый день мы слушали рассказы об опыте крупных компаний, общались и делились болью.
Получилось рассмотреть проблему с нескольких сторон:
- организация процессов разработки по избавлению от легаси;
- тактика распила легаси-монолита на микросервисы;
- способы организации API, которые позволяют держать под контролем рост устаревшего кода;
- автоматические способы обнаружения «мёртвого» кода;
- а еще попробовали поговорить как рефакторить легаси-код с помощью DDD подходов;
Под катом делюсь видео и слайдами с этой встречи. Конечно, очень много ценного осталось в кулуарах и не вошло в отчет, так что приходите в нашу уютную группу поболтать о тяжелой жизни пэхэпэшника, обсудить доклады или просто за советом :)
«Безболезненная победа над legacy»
Антон Жуков, ManyChat
Основополагающий рассказ о том, как провести рефакторинг legacy-кода без влияния на работу приложения, протестировать функциональность и производительность, а также бесшовно переключиться на новую версию на проде.
Слайды
«Итерационный подход в борьбе с legacy»
Алексей Коротин, SuperJob
Подход SuperJob — последовательная борьба с устаревшим кодом. Тимлид команды «Платформа» рассказал об API как о способе изолировать плохой код от хорошего.
Слайды
«Мёртвый код: найти и обезвредить»
Данил Мухаметзянов, Badoo
Проблема, которую мы решали, выглядит так: высокооплачиваемые инженеры постоянно читают мёртвый код. Данил из команды серверной разработки, о других проектах которой мы недавно рассказали. Его история — о том, как мы автоматизируем борьбу с легаси и какие методы применяем, чтобы контролировать его появление.
Слайды
«Тактика распила PHP-монолита»
Павел Лакосников, Авито
Распил монолита — верный способ найти устаревшие решения в собственном коде. Павел рассказал, как в Авито избавлялись от легаси:? выносили словари и другую статику, выделяли интерфейсы, упрощали иерархию наследования и совершенствовали покрытие тестами.
Слайды
«Рефакторинг PHP-кода с применением DDD»
Виталий Чирков, FunCorp
Несмотря на то, что тема DDD довольно непростая, да и последний доклад — испытание не для каждого, у Виталия здорово получилось на примерах и буквально на пальцах объяснить, как реанимировать устаревший код с использованием паттернов предметно-ориентированного программирования.
Слайды
Плейлист целиком
Фотографии с митапа лежат в наших группах VK и FB.
Анонсы новых событий проще всего получить в Telegram, подписывайтесь.
Спасибо всем, кто поддержал встречу, было здорово!
Лондонская часть нашей серверной команды сильно расширяется. До 1 марта открыт тест, по результатам которого наиболее успешным участникам придет приглашение на собеседование в Москве, а с ним — шанс получить оффер в тот же день и уехать жить в Лондон. Билеты до интервью и релокация за счёт компании.
youROCK
Продублирую комментарии здесь, раз уж в ВК вы почему-то решили на них не отвечать :).
firt
Юра, привет.
Перестать экранировать можно опцией, если это кому-то надо будет, но пока просили мы сами себя как внутренние заказчики и потому она есть и выпиливать полностью пока не планируется.
Плюс это было очень удобно для дебага посмотреть что пишется одним воркером и никто не обязывать использовать плейсхолдер для имени файла. Это просто опция :)
youROCK
Я просто хотел обратить внимание на то, что это экранирование не нужно для LSD и вероятно не нужно для кого-то ещё (или нужно в каком-то другом варианте), кто будет использовать это расширение, поэтому мне кажется, что было бы логичным выключить эту опцию по умолчанию, поскольку она сбивает с толку.
Если эту опцию не использовать, то из-за того, что при записи в файл fwrite буферизует запись блоками по сколько-то Кб, а не построчно, записи будут перемешиваться. То есть, если опция выключена, нужно убедиться в том, что буфер сбрасывается вручную не реже чем в N Кб, где N — это, допустим, 4 Кб на Linux, хотя в других операционных системах или даже реализациях libc может быть по-другому.
То есть, я хочу сказать, что если не хочется периодически получать мусор в этом файле, то эта опция обязательна в текущей реализации.
Да, но если при этом возможно доказать, что этот метод и правда не используется, добавив логирование в продакшене и подождав ~полгода, почему бы и не выпиливать неиспользуемые методы автоматически :)?
В целом, я согласен, но с другой стороны это нужно делать относительно редко, и присутствие строчки с логированием в методе позволило бы сразу видеть (без необходимости писать плагины к PHPStorm), что метод потенциально нигде не используется.
Мне кажется, эти подходы друг другу не противоречат. Мне кажется, если разработчики будут сами знать о том, что неиспользуемый код будет выпилен автоматически через какое-то время, они будут меньше бояться сами выпиливать ненужный код и делать это более «аккуратно» и продуманно, чем автоматика.