Перевод статьи «How To Take Over An Existing Project».
Каждый разработчик должен знать, как начать работу с уже существующей кодовой базой. В проекте, который достается вам «по наследству», бывает много специфических вещей, о которых вам ничего не известно. Например, вы не можете знать, почему какой-то код написан именно так, а не иначе. Поэтому, когда приходит пора вводных митингов, вам нужно знать, о чем спрашивать. Это самый подходящий момент, чтобы получить необходимую для работы информацию.
Возможно, вы сменили работу, а может, просто взялись за другой проект, оставаясь в своей компании, — это не имеет значения. Вопросы из этой статьи возникают в каждом новом для разработчика проекте. Поэтому их обязательно следует задавать на ваших первых митингах.
Узнайте, для чего предназначен этот проект, что вообще должна делать эта программа
Для чего конкретно используется это приложение и кто им пользуется? Без этого контекста вам будет очень сложно реализовывать новый функционал или исправлять баги. Спросите, где и как применяется ваше новое приложение в целом. Затем ознакомьтесь с рабочими процессами в различных его частях. Если есть список задач, пробегитесь по нему, обращая внимание на детали.
Вводный митинг это как раз тот случай, когда все готовы отвечать на ваши вопросы по проекту. Поэтому, если вам что-то непонятно, не уходите с митинга, не прояснив этот момент. Конечно, многие непонятные вещи вы обнаружите позже, когда начнете углубляться в работу, но, задав нужные вопросы сейчас, вы можете избавиться от изрядной доли непонимания.
Постарайтесь разобраться в работе приложения на высоком уровне, прежде чем перейти к более специфическим вещам. Кроме того, вы можете познакомиться поближе с индустрией, где применяется это приложение: это также поможет вам найти ответы на многие вопросы, которые возникнут в дальнейшем.
Узнайте, как организован контроль версий кода
Хотя в большинстве проектов в качестве системы контроля версий используется Git, далеко не везде при этом используется и GitHub. Какие-то проекты могут хоститься на BitBucket, Azure DevOps или даже на SVN.
Вам нужно узнать, где хранится код, чтобы вы могли вытянуть его на свою машину, а также чтобы иметь возможность оперативно разобраться с проблемами, когда (и это именно «когда», а не «если») в продакшене проявятся баги. Убедитесь, что у вас есть доступ к коду и уровень прав, достаточный для вашей работы. Получив логин и пароль, проверьте их сразу же.
Чем быстрее вы обнаружите мелкие проблемы, связанные с доступом к коду, тем более плавно будет идти ваша работа в дальнейшем. Исправьте какой-нибудь маленький баг и сделайте коммит, чтобы удостовериться, что вы можете отправлять свои локальные ветки на удаленный репозиторий (где бы он ни хостился). Также обратите внимание на то, кто вообще имеет доступ к репозиторию. Эта информация будет вам полезна, когда дело дойдет до пул-реквестов и ревью кода. Также это хороший момент, чтобы проверить, нет ли доступа к коду у людей, которым он не нужен. Обратите внимание на всех пользователей, которых вы не знаете, и попросите менеджера проекта или еще кого-нибудь проверить, действительно ли этим людям по-прежнему нужен доступ.
Узнайте, как запустить проект
Когда начинаешь работать над новым проектом, самое сложное это все настроить и первый раз запустить на своей машине. В процессе запуска выполняется много «одноразовых» команд, и при отсутствии хорошей документации они могут просто потеряться. Вам нужно проверить несколько не слишком очевидных вещей, включая переменные PATH, версии запускаемых программ и имена файлов, к которым вы обращаетесь. Также может возникнуть необходимость настроить новую локальную базу данных, получить начальные данные и внести изменения в строки подключения.
Если, занимаясь начальной настройкой, вы сталкиваетесь с какими-то трудностями, обязательно задокументируйте найденные решения, чтобы облегчить жизнь следующему разработчику, которому придется этим заниматься. Кроме того, возможно, когда-нибудь вам придется выполнить сброс настроек компьютера до заводских, и тогда эти записи пригодятся вам самому. После запуска приложения убедитесь, что все работает так же, как в среде разработки или в продакшене. До внесения новых изменений поведение должно быть одинаковым во всех средах.
Познакомьтесь с процедурой тестирования
Ваше приложение может проходить различные виды тестирования, и вы должны знать, как включиться в этот процесс. Модульные тесты это распространенное явление во многих проектах (в той или иной степени), так что всегда проверяйте их наличие. Где-то проводят интеграционное тестирование, чтобы убедиться, что в конвейер сборки или деплоймента не попадут никакие изменения, способные их сломать. В других местах могут работать специальные тестировщики, которые запускают пользовательские сценарии, чтобы посмотреть, как все будет работать у настоящих пользователей. Вам нужно быть в курсе всех этапов тестирования, через которые должно будет пройти ваше приложение.
Когда вы начинаете работать над новым для себя проектом, просмотр тестов может дать вам хорошее представление о том, как работает приложение. Если вдруг в проекте нет тестов, это хороший шанс для вас начать их добавлять. Покрытие тестами может сыграть большую роль в будущем, так что по мере продвижения разработки тесты должны добавляться.
Вам также нужно узнать, как в новом проекте налажено сотрудничество с тестировщиками. Обычно в компаниях бывает какая-нибудь система, вроде Jira или Basecamp, где в ходе спринтов можно обсуждать и отслеживать баги и функционал. Следуйте заведенной в компании процедуре, и вы будете доводить ваш код до стадии пул-реквеста гораздо быстрее и стабильнее.
Познакомьтесь с процедурой развертывания
Хотя в большинстве компаний облачные сервисы взяли на себя все заботы, связанные с хостингом, вам может случиться поработать с физическим сервером. Вам нужно получить информацию о стратегии деплоймента, с которой вы будете работать. Поинтересуйтесь, применяется ли в этом проекте непрерывная сборка/развертывание или вам нужно будет осуществлять развертывание приложения вручную, со своей машины. Узнайте, что делать с миграциями в разных средах. Выясните, как происходят все обычные этапы развертывания.
С облачными сервисами случаются разные неприятности, о которых знают только люди, проводившие развертывание ранее, поэтому не забудьте спросить, на что следует обращать внимание. Поскольку вы уже попробовали исправить маленький баг, чтобы проверить, можете ли без проблем отправлять в репозиторий свои изменения, сделайте еще шаг и разверните это маленькое исправление в среде разработки. Надеемся, вы будете работать с CI/CD конвейерами и процесс работы будет более-менее постоянным.
Начинать работу над существующим проектом это особый навык, потому что это делается не каждый день. Некоторые люди работают над одним продуктом или линейкой продуктов значительную часть своей карьеры, так что начинать работу над уже существующим, но новым для них проектом им приходится довольно редко. А вот если вы станете консультантом или фрилансером, вы должны будете уметь уверенно включаться в работу, ведь вам придется делать это достаточно регулярно.
Обычно в начале работы над проектом бывает нужно внести некоторые небольшие изменения в настройки. Когда вы выясните, что и как именно нужно изменить, вам больше не придется беспокоиться об этом.
В этой статье я рассказала лишь о нескольких вещах, на которые я сама обращаю внимание в начале работ над уже существующим проектом. Частично эти советы применимы и к проектам с открытым кодом. А у вас есть какой-то свой список вещей, которые нужно проверить и узнать до начала работы?
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]