Советы по работе с легаси кодом в PHP

Сколько раз, приходя в новую компанию, вы получали в руки “большой комок грязи“, к которому каким-то образом нужно прикручивать новый функционал?

Без документации.

Без контроля версий.

Без какой-либо надежды на душевное равновесие в будущем.

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

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

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

Советы по отладке

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

Разбиение пополам (Half Splitting)

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

Пример А: База данных или код?

Допустим, у вас возникли проблемы с получением данных о клиентах. Это проблема проистекает из базы данных или из кода? Вы можете вставить SQL-запрос непосредственно в клиент MySQL, чтобы сразу понять, с чем конкретно связан проблема.

Пример Б: Здоровенный контроллер.

Допустим, у вас есть злополучный скрипт, который дает сбой. Когда-то давно мне приходилось работать с контроллер длиной в 45 000 строк. Нет, это не опечатка.

К тому же он был процедурным, прямо посреди MVC framework, если до этого вы еще не прониклись моей болью.

Я бы даже не пытался постигать такой монолит плохих практик. Я бы просто всандалил оператор die() или error_log() где-то около строки 22500 и посмотрел, присутствует ли еще ошибка.

Затем убедившись, что переменная сеанса все еще неверна или я получаю сообщение об ошибке, я бы продолжил в том же духе: поставил бы те же проверки в районе строки 11250. И так далее и тому подобное.

Это глупо, это примитивно. Но очень часто это самый быстрый способ отладить что-то, особенно если это процедурно написанный код.

Пользовательское приемочное тестирование (User Acceptance Testing)

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

Как я уже говорил о превратностях работы с “большим комом грязи”, тут невозможно быть слишком осторожным.

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

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

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

Последнее изменение файла

Вы когда-нибудь встречали самодельные системы контроля версий, которые выглядели бы следующим образом?

oh dear

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

Берем все под личный контроль

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

Бэкапим все

“Все, что не сохранено, будет потеряно”

— экран завершения работы Nintendo Wii

Если еще не настроено автоматическое резервное копирование, то при необходимости создайте резервную копию вручную.

Вам нужны бэкапы:

• изображений

• баз данных

• кода

Иногда в кодовую базу может быть вмешано много мусора, например, adobe-файлы от дизайнера, фотографии в полном разрешении от фотографа и так далее.

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

Ограничиваем доступ

“Легче попросить прощения, чем получить разрешение” —

адмирал Грейс Хоппер

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

Я не могу сосчитать количество раз, когда на моей памяти производственный FTP-сервер использовался для хранения общих документов или архивов Outlook.

Если вы по какой-то причине не можете использовать службы обмена файлами, такие ​​​​как Dropbox или Google Drive, по крайней мере, создайте учетные записи FTP, которые ограничены выбранным каталогом. Хотя бы вы перестанете хранить PDF-файлы и шаблоны электронной почты в своей кодовой базе.

Контроль версий и локальная среда разработки

“Да, с помощью git легко отстрелить себе ногу, но также легко вернуться к предыдущей ноге и объединить ее с текущей ногой.”

— Джек Уильям Белл

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

Что хорошего в этих безнадежно устаревших кодовых базах, так это то, что они зачастую работают на очень простом стеке (Apache, PHP, MySQL).

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

Если в моем рабочем пространстве отсутствует какой-либо рабочий процесс, быстрой промежуточной мерой, которая может ускорить процесс, является использование одного из различных плагинов GIT-FTP (либо для GIT, но он может даже подключаться к вашей IDE). Это делает исправление катастрофических ошибок еще быстрее.

И вместе с этим вы сможете даже уйти так, чтобы никто этого не заметил.

Заключительные размышления и рефакторинг

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

Очевидно, что если у вас есть средства для замены старой системы или рефакторинга ее частей, то вы должны это сделать.

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

И, как всегда, не воспринимайте все близко к сердцу.

---

Перевод материала подготовлен в преддверии старта курса «PHP Developer. Professional».