В Воронеже решил познакомиться с местным php сообществом. Оказывается Александр Макаров (тот самый в шляпе из yii) живет здесь. Первая моя php конференция была с его участием в Киве :)

20 февраля состоится митап на котором мне предложили рассказать про наш опыт перехода на php 7.2 из древнего 5.3.

Продуктовых аналитиков учат - вывод сначала. Попробуем.

Вывод

1. Джуны и стажеры помогают экономить
2. Используйте анализаторы кода
3. Переходите с 5х когда нужны новые зависимости или производительность

История

Ветменеджер - это CRM-комбайн для ветеринарных клиник.

Размер проекта к 2018 году достиг 281к строк php кода и 41к js кода.

Я попал в проект в 2009 году. К этому моменту кода было уже много. Заказчиком был владелец клиники, который загорелся перенести свою старую программу написанную на Delphi в веб.

Стоял сервер с debian у него в клинике и вебсервер крутился на нём. Для обновления был написал скрипт, который обновлял репозиторий в директорию и rsyncал файлы в продакшн директорию и запускал миграции.

Через определенное время мы это опубликовали в веб и каждый мог зарегистрировать клинику при этом и возможность локальной установки у нас осталась. При регистрации клиники создавалась папка с кодом и отдельная база данных, в неё мы rsyncали файлы с гитхаб и запускали миграции. Имя папки было хостом. Типа domains/mydomain/ тут лежит код и mydomain.vetmanager.ru так я попадаю в свою программу. В момент обновления мы rsyncали каждую папку и запускали миграции. В конце жизни такой архитектуры миграции занимали минимум 2 ночи и днем не делались.

Появились клиенты. Кол-во пользователей стало рости достаточно быстро, для такой узкой ниши.

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

Версии php инрементировались, но все это проходило мимо нас. Бюджеты были небольшие и выделить на это средства не было возможности. Поддержка php 5.3 была прекращена в 2014 году, мы перешли на новую версию языка только в конце 2018 года.

Можно ли использовать 5.3 в 2021?

Да, это все еще возможно. Если у вас нет нужды в новых сторонних библиотеках, вы даже сможете развивать этот продукт. Мы до сих пор поддерживаем биллинг-сервис на yii1, который отлично работает на 5.3. Его задача отдавать данные о тарифе и отправлять напоминания. 1-2 раза в год в код даже добавляются какие-то незначительные фичи.

Стоит ли переходить?

Даже после прекращения поддержки php 5.3 в 2014г Ветменеджер активно развивался, писались новые фичи и софт активно сопровождался. Конечно, мы начали замечать неудобства.

Сильно выросло время настройки проекта локально

Докеры и прочий Ansible не были так популярны. Для локальной разработки нужно было переключаться на старую версию чем-то вроде phpbrew. Чем больше 5.3 устаревала, тем страшнее было убить рабочий линукс и потерять неделю с бубном. Когда появился докер в нем тоже были проблемы с 5.3 и нашим проектом, нахрапом мы не смогли запуститься.

Используемые библиотеки перестали обновляться

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

Новые интеграции были нам недоступны

Интеграции с новыми сервисами требовали самостоятельной разработки SDK, поскольку все новое уже писалось под новые версии языка. Несколько перспективных фич мы откладывали именно из-за этого. До некоторых пор, можно было скачать библиотеку и поменять в ней [] на array(). Потом разница стала более существенной.

Как переходили мы?

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

Конечно, потребовалось и смена архитектуры. Единый код, который обслуживал бы все запросы. Stateless приложение. Это тема отдельного доклада.

Условия были такие, что опытные программисты были отправлены перепиливать архитектуру. Им было что пилить. Ресурсов на смену версий практически не было. У меня был контакт с одной местной ИТ школой и куча голодных к первой работе студентов и выпускников. Итого: зеленные студенты и один опытный джун, но было достаточно много времени.

В репозитории с статическими анализаторами кода нашел решение phpmar.

При запуске на одной из директорий получал такое:

2017-11-09T15:09:17+02:00
Scanning /home/otis/myprojects/manager/application/components
Including file extensions: php
Processed 73704 lines contained in 350 files.
Processing took 6.4349660873413 seconds.

# critical
#### /home/otis/myprojects/manager/application/components/DataSource/DataSource.php
* oldClassConstructors
 * Line 27: `    function DataSource(`

#### /home/otis/myprojects/manager/application/components/Debug/Debug.php
* oldClassConstructors
 * Line 97: `	function Debug()`

#### /home/otis/myprojects/manager/application/components/Debug/Frame.php
* oldClassConstructors
 * Line 72: `    function Debug_Backtrace_Parser_Frame(&$frame)`
* funcGetArg
 * Line 543: `		$arr = func_get_args();`

Да, тут еще конструкторы с php 4, мы с ними жили и они нас совсем не беспокоили. На весь проект было найдено около 1800 строк требующих исправлений. Все исправления в проекте были сделаны руками стажеров, от нас было только кофе, печеньки, рабочее место и общение.

Алгоритм работы был такой:

1. Я запускал утилиту и выбирал одну самую популярную проблему из отчета
2. Опытный джун писал простую инструкцию по исправлению этой проблемы
3. Стажер запускал утилиту и искал эту проблему в отчете
4. Делал 1 коммит на каждые 10 правок и пил кофе с печеньками
5. Опытный джун делал ревью
6. Когда все ошибки были исправлены мы решали следующую проблему. Одна проблема за 1 раз.
7. В конце прошлись еще несколькими тулами

Инструкции для стажеров выглядели так:

Инструкция по работе с ошибкой funcGetArg
При переходе на PHP7, следует 
- проверить, чтобы эти функции находились первой строкой в методе(функции) в которой они вызываются 
- проверить входящие параметры функции(метода), чтобы не изменялись перед вызовом func_get_arg() и func_get_args()

Ссылка на источник:  http://php.net/manual/en/migration70.incompatible.php 

Плюсы

• Переход на новую версию обошелся нам всего несколько часов работы опытного джуна + затраты на кофе и печеньки.
• Среди стажеров мы нашли толковых ребят
• Подход оказался эффективным и для других случаев
• Наш опытный джун начал что-то объяснять, а значит учиться
• Стажеры получили реальный опыт и инструкции по дальнейшему развитию, а кто-то и трудоустройство

Минусы

• Дешево, но долго

Один рабочий компьютер. Стажеры делили время на нём, этот хотел но не пришел - часы простоя. Но нас это устраивало.

Развитие

Используя этот способ мы:

• избавились от deprecated функций
• переходили на php 7.4
• избавлялись от sql инъекций
• постоянно верстаем клиентам crm простые html шаблоны (в crm есть кастомизируемые клиентом печатные формы, которые верстают такие же студенты, но уже за деньги)
• нашли не только программистов но и сотрудников в саппорт

Если работы много, она простая и однотипная, она несрочная - используйте стажеров. Стажеров сейчас полно. Совсем без опыта, обычно, они никому не нужны.

Материалы:

• Архитектура высоких нагрузок
• Анализаторы кода на любой вкус
• Другие инструменты для перехода
• Ссылка на статью про историю архитектуры для пользователей