Сколько раз, приходя в новую компанию, вы получали в руки “большой комок грязи“, к которому каким-то образом нужно прикручивать новый функционал? Без документации. Без контроля версий. Без какой-либо надежды на душевное равновесие в будущем. Большинство статей и книг, которые я читал, всецело фокусируются на создании нового программного обеспечения. Однако, по моему личному опыту я обнаружил, что мои самые распространенные задачи — это не создание новых систем, а поддержание старых трещащих по швам страхолюдин, изначальный архитектор которых уже давно покинул компанию. Это вполне реальная и чересчур распространенная ситуация, но говорим мы о ней не так уж и часто (если только не нужно покритиковать ныне ушедшего автора, который об этом точно не узнает, чтобы защитить себя). Именно поэтому я решил предложить вашему вниманию это небольшое руководство, которое раньше существовало только в моем собственном сознании. И вместе с тем призываю вас отнестись ко всему описанному ниже с долей скептицизма и не рассматривать его в качестве предписаний из какого-либо авторитетного источника. Помимо наличия подушки, в которую можно покричать, и обильного количества кофеина, что вообще можно посоветовать перед проведением хирургических операций одному из кошмаров Кроненберга? Процесс разбиения пополам — это старый приемчик со времен, когда я работал техником-связистом. Я нахожу этот фундаментальный принцип очень полезным, особенно при попытке выяснить, где же затаилась ошибка. Допустим, у вас возникли проблемы с получением данных о клиентах. Это проблема проистекает из базы данных или из кода? Вы можете вставить SQL-запрос непосредственно в клиент MySQL, чтобы сразу понять, с чем конкретно связан проблема. Допустим, у вас есть злополучный скрипт, который дает сбой. Когда-то давно мне приходилось работать с контроллер длиной в 45 000 строк. Нет, это не опечатка. К тому же он был процедурным, прямо посреди MVC framework, если до этого вы еще не прониклись моей болью. Я бы даже не пытался постигать такой монолит плохих практик. Я бы просто всандалил оператор die() или error_log() где-то около строки 22500 и посмотрел, присутствует ли еще ошибка. Затем убедившись, что переменная сеанса все еще неверна или я получаю сообщение об ошибке, я бы продолжил в том же духе: поставил бы те же проверки в районе строки 11250. И так далее и тому подобное. Это глупо, это примитивно. Но очень часто это самый быстрый способ отладить что-то, особенно если это процедурно написанный код. Я понимаю, что это то, что обычно приходит на ум, когда вы создаете новое программное обеспечение, однако все-таки выслушайте меня. Как я уже говорил о превратностях работы с “большим комом грязи”, тут невозможно быть слишком осторожным. Хорошей практикой, которая стоит на страже моего душевного равновесия, является то, что я сразу буду уделять особое внимание одной или двум основным частям функционала. Тому, из-за чего мне могут позвонить в 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».