Знакомство с новой кодовой базой

Перевод статьи «Exploring the path of a new and unfamiliar codebase».

Photo by Kit Suman on Unsplash

Пару месяцев назад я сменила работу и начала работать в DEV (сообщество разработчиков и сайт dev.to, — прим. перев.). Поскольку в своей карьере я уже дошла до уровня сеньора, мне неоднократно приходилось знакомиться с новыми для меня кодовыми базами, и каждое такое знакомство протекало легче и быстрее предыдущего.

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

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

Итак, с чего все начинается?

Исследуем конечный продукт

Прежде чем присоединиться к новой команде, я обычно знакомлюсь с их продуктом (в общих чертах). Я скачиваю приложения компаний, куда хочу устроиться работать, еще на стадии подготовки к собеседованиям. Бывает, что я уже и так пользуюсь платформой компании и, следовательно, хорошо знакома с ней. Так было, например, с DEV.

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

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

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

Теперь можно клонировать код и настроить свое окружение

После ознакомления с приложением я клонирую его код. Затем просматриваю документацию в поиске инструкций по настройке.

Я не стесняюсь сказать, что застряла на чем-то (не важно, касается это настройки или чего-то другого), а Google и Stack Overflow это вообще мои лучшие друзья. Но если самостоятельные поиски ответов не увенчались успехом, я задаю вопросы в командном чате. Все члены команды, пришедшие в проект до меня, уже занимались настройкой окружения, так что кто-нибудь из них наверняка сталкивался с такой же проблемой.

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

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

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

Беремся за простые задачи

Исследовать недостаточно: с кодом нужно работать. Во время работы над чем-либо наши знания об этом предмете становятся прочнее. Мы применяем на практике все, что уже узнали в теории.

В любом проекте есть баги, буквально в любом. Мне нравится браться за их исправление — в рамках знакомства с кодом.

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

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

Учитывая все вышесказанное, при выборе своих первых багов я стараюсь не браться за сложные, непонятные и тяжело воспроизводимые, потому что это будет меня подавлять и замедлит мое продвижение вперед. В мире open source, к которому относится и DEV, подходящие для ознакомления с кодовой базой баги могли бы быть помечены тегом «good first issue».

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

Отладка и работа с багами

Есть пара приемов, которые я использую при работе с багами. Они применимы не только для новой кодовой базы; это универсальные приемы для работы над любой задачей.

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

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

  • Я использую массу логов! Бывали случаи, когда я добавляла логи к каждой функции в файле, чтобы понять их путь. Разобравшись в этом пути, я легко могу определить, где что-то могло пойти не так. Одновременно я изучаю работу кода. Применяя этот подход, я обязательно даю хорошие названия логам, чтобы не потеряться в них, а также делаю пометки о порядке логов (особенно в JavaScript, где все работает асинхронно).
  • Если мне случилось застрять, я могу закомментировать кусок кода, просто чтобы посмотреть, чем это обернется (и не взорвется ли система). Отключая таким образом участки кода, можно понять, в правильном ли месте вы ищете источник проблемы. Если я закомментировала код, а интерфейс или функция по-прежнему работают, это означает, что я определенно работаю не в той части кодовой базы. Я всегда напоминаю себе, что не нужно бояться что-то испытывать, ведь сломать приложение в среде разработки практически невозможно. (По крайней мере, я на это надеюсь, потому что в противном случае у нас проблемы пострашнее бага!). P.S. Изменяя код в среде разработки, следите за тем, чтобы обновлять его там же, а не в продакшене (удивляясь при этом, почему же изменения ни на что не влияют). Да, со мной такое случалось многократно!
  • Я пользуюсь отладчиками для остановки выполнения кода. Так я могу поработать с отдельными частями, которые мне особенно непонятны.

Это все хорошо, но что, если я все равно застрял?

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

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

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

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

О чем следует помнить во время ознакомления с базой кода?

  • Я совершенно уверена, что все изменения должны вноситься инкрементально, а не путем одного огромного пул-реквеста. Также следует почаще все тестировать.
  • Важно придерживаться стиля написания кода, принятого для этой кодовой базы. Таким образом будет поддерживаться единообразие.
  • Вводя в работу новые инструменты или технологии, затрагивающие работу других команд или направление всего проекта, нужно обязательно ставить в известность всех, кого это коснется (тут все еще зависит от гибкости компании).
  • Независимо от уровня своих навыков нужно проявлять эмпатию и хорошее отношение к своему предшественнику, написавшему код, с которым вы работаете. Разработчики часто жалуются на то, как ужасен унаследованный ими код. Не следует забывать, что мы не знаем всего контекста и ситуации, в которой этот код был написан.
  • Порой мы что-то ломаем. Да, дерьмо случается, смиритесь с этим. Извлеките уроки и идите дальше!

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх