393
0
1
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

«Симба, это теперь твое!», или Как работать с легаси-кодом на своем первом проекте

Время чтения 1 минута
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
393
0
1
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Одно из самых потрясающих ощущений в карьере начинающий разработчик испытывает, когда он получает первую работу, прорвавшись через череду собеседований. У него на максимуме собранность, мотивация и готовность показать этому миру (ну, или хотя бы работодателю), что его взяли не зря. Увы, нередко стремительный подъем по кривой Даннинга — Крюгера может окончиться обрывом в первые недели или месяцы работы. Бюрократия, не идеально (или просто плохо) выстроенные процессы… В общем, всё, что называется словом «реальность», возвращает джуна на бренную землю и заставляет иначе взглянуть на процесс разработки программного обеспечения в частности и IT-индустрию в целом.

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

Меня зовут Георгий Наумов. Более 13 лет я работаю в сфере автоматизации промышленных предприятий, а последние 3,5 года занимаюсь профессиональной разработкой. Я ежедневно работаю с огромными легаси-проектами: разбираюсь в их внутренностях, дорабатываю, исправляю ошибки. Ну и создаю их, не без этого 🙂 За эти годы я прошел, кажется, все стадии принятия этой стороны разработки. В этой статье я постараюсь дать простые советы, которые помогут вам легче справиться с первым шоком от работы с проектами, доставшимися «в наследство» от более опытных товарищей, и начать эффективную работу с ними.

«Симба, это теперь твое!», или Как работать с легаси-кодом на своем первом проекте

Не навредите

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

Каким бы неоптимальным ни было приложение с точки зрения архитектуры и исходного кода, с большой вероятностью оно обслуживает десятки и сотни пользователей. Полная остановка сервиса из-за неудачно «исправленного» бага имеет в разы более негативные последствия (часто в денежном эквиваленте), чем пусть и медленная, но работа.

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

Соберите информацию

Максимум, до которого сможете дотянуться.

Обычно уровень документирования легаси-проектов очень низкий. Особенно этим «страдают» проекты, которые разрабатывались одним человеком или небольшой командой: зачем тратить время на документацию, если ты и так знаешь проект вдоль и поперек?

Разумеется, личные контакты никто не отменяет. Сами бывшие разработчики или их коллеги могут дать много ценной информации о проекте, если заданные вопросы будут конкретными (и не будут повторяться из раза в раз). Некоторые ответы могут удивить: «Никто не знает и не помнит, почему это работает именно так», «Какая разница, как это реализовано, если этот код выполняет свою задачу?!», — характер и личные качества коллег здесь практически не имеют значения. Если в проекте изначально не были определены правила передачи компетенций и документирования, вряд ли найдется человек, разбирающийся во всех нюансах кодовой базы.

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

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

Начните с правки багов

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

Исправляя баги, вы будете постепенно вникать в кодовую базу проекта. Разбирайтесь в назначении классов и методов, пока не исчезнет вопрос: «Зачем тут это нужно?» Разобрались? Зафиксируйте — задокументируйте или оставьте содержательный комментарий в коде.

По ходу исправления багов с целью улучшения качества кода стоит обновлять документацию проекта. Также очень эффективно использование комментариев в стиле JavaDoc в проектах на Java, XML-комментариев в проектах C# и других видов документирующих комментариев.

Проводите рефакторинг очень аккуратно. Не нужно сходу пытаться разделить 200-строчный метод или функцию на несколько частей. Аккуратно исправляйте откровенно неудачные блоки кода, например «многоэтажные» условные переходы и циклы. А вот именование переменных типа а, first, someValue можно смело исправлять сразу. Ни у одного разработчика не найдется оправданий, чтобы подобное оставалось в исходном коде. Давайте переменным содержательные имена, придерживайтесь принятого в организации соглашения о форматировании кода.

Максимально обдуманно вносите изменения пользовательского интерфейса

Говоря прямо, UI в большинстве случаев лучше не менять вообще.

Один из самых неочевидных моментов для начинающих специалистов. Особенно этот момент может быть сложен для frontend-разработчиков. При изменении проекта, функционирующего длительное время, необходимо максимально аккуратно подходить к изменению пользовательского интерфейса. Даже в тех случаях, когда эти изменения предусмотрены заданием на доработку ПО. Привычки пользователей значительно сильнее новых технологий. Изменение знакомых кнопок, полей ввода данных и переключателей, даже если оно сделано с самыми лучшими намерениями, может вызвать негатив и поток заявок в духе «верните, как было, стало невозможно работать!».

Я не разделяю подход «работает — не трогай», но в случае с пользовательским интерфейсом он часто оправдан. Если всё-таки решитесь, обязательно продумайте, каким образом донести нововведения до пользователей. Наверняка вы обращали внимание на уведомление и сторис в приложениях банков и маркетплейсов: «Ваша история заказов теперь здесь», «Избранные товары переехали в другой раздел». Да, подобные уведомления сделаны именно в этих целях.

Оставляйте хлебные крошки

Про документирующие комментарии уже было сказано выше. Помимо них, старайтесь оставить максимум информации о сути изменений. Комментарии к коммитам должны максимально полно отражать суть внесенных изменений. Содержание коммитов должно быть компактным. Не копите изменения, фиксируйте версию исходного кода сразу после исправления, несущего функциональную нагрузку: исправление бага, добавление какой-либо фичи. Этот совет не раз спасет вас от ситуации «одно исправляем — другое ломаем». В разы проще найти свежую поломку в коммите, который затрагивает 5–6 файлов и несколько десятков строк кода, чем откатывать коммит, повлиявший почти на весь проект и пару-тройку тысяч строк исходного кода.

Заключение

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

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

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

Комментарии1
Oleg_2_Oleg
3 месяца назад
Отмечу еще один момент: работа с самым сложным, большим и запущенным проектом не должна быть источником отрицательных эмоций. Доработка любого проекта в итоге станет тем самым бесценным опытом, который позволяет начинающему разработчику расти. Ценность этого опыта ничуть не меньше, чем владение самыми современными инструментами.
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники