Как только разработчик попадает в компанию и получает задачу, чаще всего оказывается, что ему нужно присоединиться к общему проекту какой-то команды, а не писать свой код с нуля.
Любой код имеет собственную логику, основан на определенных принципах, в нем встречаются паттерны и технологии, характерные для команды, к которой присоединился программист. Но как начать быстро понимать чужой проект, при том что он вряд ли небольшой, а документации часто либо вообще нет, либо она недостаточна и неточна?
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Skillbox рекомендует: Онлайн-курс «Профессия Frontend-разработчик».
На самом деле лучшая документация — это сам код и те, кто этот код создавал (при условии, что они до сих пор где-то рядом, а не ушли из компании). Как можно снизить временные затраты до минимума и быстро приступить к работе, внося и свою лепту?
Я неоднократно сталкивался с такой ситуацией за последние 15 лет своей работы программистом, и вот мои размышления по этому поводу.
Цели и задачи проекта
Первая вещь, которую вы должны сделать, — потратить немного времени на то, чтобы понять, какую задачу (задачи) выполняет приложение, код для которого вы создаете. Это глобальная задача; решив ее, вы справитесь и со всем остальным.
Нельзя работать над проектом, не представляя себе, зачем он вообще нужен. Общее понимание позволит вам быстрее разобраться в мелочах. Кроме того, ваша собственная работа будет выполняться более слаженно с остальным коллективом. Кирпичик за кирпичиком — так и строится дом.
Архитектура
После того как вы узнали основную задачу, посвятите себя разбору выполнения кода и его логики.
Архитектура некоторых проектов довольно сложна, в особенности если базовые технологии этих проектов вам не очень хорошо знакомы. В самом начале постарайтесь найти техническую документацию (или же поспрашивать о ней коллег), с тем чтобы видеть основную логику.
Держа в голове структуру проекта, вы быстрее сможете начать работу, причем так, чтобы не мешать функционированию всех остальных частей, которыми занимаются другие члены команды.
В проекте могут встречаться фрагменты, которые нарушают общую логику, но, зная идею и архитектуру, вы сможете исправить проблему, переставить или изменить «кирпичики» так, чтобы они идеально вписывались в общее здание.
Паттерны (шаблоны)
Существует большое количество паттернов, используемых разработчиками при написании кода. Это структурные шаблоны, «поведенческие», технологические и другие. Все они помогают типизировать способы решения часто встречающихся проблем при проектировании программ.
Понимание того, какие шаблоны используются в вашем текущем проекте, поможет уже на уровне классов понять, как функции должны быть встроены в код. В итоге вы сможете создавать связный код, который будет соответствовать общей логике и паттернам, что в конечном итоге приведет к гораздо меньшему количеству комментариев к коду, лучшему его пониманию и оперативному устранению ошибок в случае необходимости.
Поработав немного над проектом, вы сможете с первого взгляда понимать, какие участки кода вписываются в общую структуру, а что требует рефакторинга.
Руководящие принципы
В большинстве команд есть определенные правила, вернее, набор правил, согласно которым все действуют. Речь идет не только про общие принципы работы, но и про использование классов и уровней приложения. Если представители команды руководствуются одними и теми же руководящими принципами, то разрабатываемый код легче понимать и читать.
Скорее всего, у команды, к которой вы присоединитесь, тоже есть руководящие принципы, которые вам необходимо изучить. В первую очередь они касаются того языка программирования, который является основным при разработке.
Вы можете спросить, где вообще взять всю информацию о проекте, его архитектуре, шаблонах и руководящих принципах. Есть несколько методов получения необходимого, кроме тех, что уже озвучивались выше:
- Ищите любую информацию, даже ту, что можно считать неактуальной; постройте собственную базу знаний общих терминов, аббревиатур и концепций, которые использует ваша команда.
- Как только эта база готова, вы можете обсуждать все интересующие вас вопросы с руководителем проекта, поскольку уже говорите на одном языке.
- Кроме того, стоит поговорить с архитекторами приложения и тимлидами об общей архитектуре вашего проекта. Затем попробуйте узнать больше об этой архитектуре и методах оптимизации кода, связанных с ней. Если вы видите что-то, что, по вашему мнению, нарушает общую логику приложения, обязательно обсудите это с тимлидом.
- Выясните у коллег по команде какие шаблоны и правила используются в ходе работы над кодом — как при написании, так и при дальнейшем обслуживании. После того как узнаете основные моменты, сравните, что лучше работает, и действуйте соответствующим образом в дальнейшем.
- Попробуйте почистить участок кода от потенциальных и реальных проблем — это поможет вам получить более глубокое представление о проекте и его коде. Что ваша команда использует при наведении порядка в коде?
Вообще говоря, рефакторинг — лучшая возможность вовлечь вашу команду в обсуждение того, какие руководящие принципы стоит пересмотреть, а какие — использовать в дальнейшем.
Делитесь с командой собственными наработками, активно принимайте участие в рабочих встречах, обсуждайте текущие проблемы, архитектуру приложения и его элементов, шаблоны и другие важные моменты. Рабочие встречи могут стать надежным каналом получения дополнительной информации; на них же стоит рассказывать о своих наблюдениях/достижениях, о том, что может оказаться полезным для всех.
В итоге вы сможете не только быстро начать работу, но и влиться в команду, став незаменимым ее участником в течение короткого времени.
Конечно, вам будут встречаться люди, с которыми тяжело общаться; проблемы будут и с кодом. Но это случается почти всегда — бывают команды, где все идеально, но их мало.
Skillbox рекомендует:
- Практический курс «Мобильный разработчик PRO».
- Онлайн-курс «С#-разработчик с нуля».
- Двухлетний практический курс «Я — веб-разработчик PRO».
