Не навредите
Первое и главное, что нужно помнить всегда, — практически любой легаси-код является основой работающего приложения. Скорее всего, в текущем его виде оно функционирует в течение нескольких лет. Стоит принимать как данность, что большинство приложений и сервисов создаются в условиях постоянных жестких дедлайнов, регулярно меняющихся требований и различных технологических и инфраструктурных ограничений. Последнее, к слову, крайне важно: всегда учитывайте, что многие технические решения в проектах принимаются по причине ограничений со стороны служб информационной безопасности или местного законодательства. Найдите время и поинтересуйтесь ими у руководителей вашей группы разработки. Они прямо заинтересованы в том, чтобы вся команда четко знала все подобные ограничения.
Каким бы неоптимальным ни было приложение с точки зрения архитектуры и исходного кода, с большой вероятностью оно обслуживает десятки и сотни пользователей. Полная остановка сервиса из-за неудачно «исправленного» бага имеет в разы более негативные последствия (часто в денежном эквиваленте), чем пусть и медленная, но работа.
Обратите особое внимание на данные, с которыми работает приложение. Структура хранимой информации может быть ужасной, а таблицы совершенно денормализованы, но последнее, чем стоит заниматься, — это пытаться внести изменения в структуру данных проекта. Помните, что любая база данных может быть источником сведений для нескольких систем и информационных хранилищ либо использоваться для интеграции со сторонним сервисом. Со временем вы обязательно узнаете все эти аспекты, но начинать переработку системы с данных — это однозначно плохая идея.
Соберите информацию
Максимум, до которого сможете дотянуться.
Обычно уровень документирования легаси-проектов очень низкий. Особенно этим «страдают» проекты, которые разрабатывались одним человеком или небольшой командой: зачем тратить время на документацию, если ты и так знаешь проект вдоль и поперек?
Разумеется, личные контакты никто не отменяет. Сами бывшие разработчики или их коллеги могут дать много ценной информации о проекте, если заданные вопросы будут конкретными (и не будут повторяться из раза в раз). Некоторые ответы могут удивить: «Никто не знает и не помнит, почему это работает именно так», «Какая разница, как это реализовано, если этот код выполняет свою задачу?!», — характер и личные качества коллег здесь практически не имеют значения. Если в проекте изначально не были определены правила передачи компетенций и документирования, вряд ли найдется человек, разбирающийся во всех нюансах кодовой базы.
Источником информации в подобных условиях могут быть записи (в том числе рукописные) бывших разработчиков и даже почтовая переписка: в ряде случаев к ней можно получить доступ, но обязательно надо посоветоваться со службой безопасности организации. Небольшой лайфхак: многие разработчики стараются держать сколь угодно базовое описание проекта рядом с папкой, в которой размещен исходный код проекта.
И еще немного про рукописные заметки: не пренебрегайте ими! Соглашусь, что, имея под руками Notion или любой аналогичный сервис, можно организовать свои записи эффективнее. Но записная книжка и ручка по-прежнему остаются отличными рабочими инструментами, благодаря которым можно быстро и надежно зафиксировать информацию.
Начните с правки багов
На мой взгляд, самый очевидный и эффективный способ начать погружение в бизнес-логику проекта и исправлять неэффективный код — исправление ошибок. Их источники довольно очевидны: баг-трекер, заявки пользователей. Про какие-то баги, переходящие из версии в версию, могут рассказать тестировщики.
Исправляя баги, вы будете постепенно вникать в кодовую базу проекта. Разбирайтесь в назначении классов и методов, пока не исчезнет вопрос: «Зачем тут это нужно?» Разобрались? Зафиксируйте — задокументируйте или оставьте содержательный комментарий в коде.
По ходу исправления багов с целью улучшения качества кода стоит обновлять документацию проекта. Также очень эффективно использование комментариев в стиле JavaDoc в проектах на Java, XML-комментариев в проектах C# и других видов документирующих комментариев.
Проводите рефакторинг очень аккуратно. Не нужно сходу пытаться разделить 200-строчный метод или функцию на несколько частей. Аккуратно исправляйте откровенно неудачные блоки кода, например «многоэтажные» условные переходы и циклы. А вот именование переменных типа а, first, someValue можно смело исправлять сразу. Ни у одного разработчика не найдется оправданий, чтобы подобное оставалось в исходном коде. Давайте переменным содержательные имена, придерживайтесь принятого в организации соглашения о форматировании кода.
Максимально обдуманно вносите изменения пользовательского интерфейса
Говоря прямо, UI в большинстве случаев лучше не менять вообще.
Один из самых неочевидных моментов для начинающих специалистов. Особенно этот момент может быть сложен для frontend-разработчиков. При изменении проекта, функционирующего длительное время, необходимо максимально аккуратно подходить к изменению пользовательского интерфейса. Даже в тех случаях, когда эти изменения предусмотрены заданием на доработку ПО. Привычки пользователей значительно сильнее новых технологий. Изменение знакомых кнопок, полей ввода данных и переключателей, даже если оно сделано с самыми лучшими намерениями, может вызвать негатив и поток заявок в духе «верните, как было, стало невозможно работать!».
Я не разделяю подход «работает — не трогай», но в случае с пользовательским интерфейсом он часто оправдан. Если всё-таки решитесь, обязательно продумайте, каким образом донести нововведения до пользователей. Наверняка вы обращали внимание на уведомление и сторис в приложениях банков и маркетплейсов: «Ваша история заказов теперь здесь», «Избранные товары переехали в другой раздел». Да, подобные уведомления сделаны именно в этих целях.
Оставляйте хлебные крошки
Про документирующие комментарии уже было сказано выше. Помимо них, старайтесь оставить максимум информации о сути изменений. Комментарии к коммитам должны максимально полно отражать суть внесенных изменений. Содержание коммитов должно быть компактным. Не копите изменения, фиксируйте версию исходного кода сразу после исправления, несущего функциональную нагрузку: исправление бага, добавление какой-либо фичи. Этот совет не раз спасет вас от ситуации «одно исправляем — другое ломаем». В разы проще найти свежую поломку в коммите, который затрагивает 5–6 файлов и несколько десятков строк кода, чем откатывать коммит, повлиявший почти на весь проект и пару-тройку тысяч строк исходного кода.
Заключение
Работа с легаси-кодом часто становится первым испытанием для начинающих разработчиков на проекте. И, не будучи к нему готовыми, вы рискуете начать карьеру с негативных впечатлений.
Но всегда стоит помнить, что абсолютное большинство разработчиков когда-то проходили этот этап. Да-да, мир не состоит только из стартапов. Практически всё промышленное программное обеспечение, очень многие операционные системы в своей основе имеют код, остающийся неизменным на протяжении нескольких десятилетий. Люди, продолжающие его поддерживать, дорабатывать и развивать, — это профессионалы высочайшего уровня, которые сталкиваются с абсолютно теми же проблемами, что и программист, увидевший этот код первый раз.
Отмечу еще один момент: работа с самым сложным, большим и запущенным проектом не должна быть источником отрицательных эмоций. Доработка любого проекта в итоге станет тем самым бесценным опытом, который позволяет начинающему разработчику расти. Ценность этого опыта ничуть не меньше, чем владение самыми современными инструментами.
