Перевод статьи «Exploring the path of a new and unfamiliar codebase».
Пару месяцев назад я сменила работу и начала работать в 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]