- PVSM.RU - https://www.pvsm.ru -
Как только разработчик попадает в компанию и получает задачу, чаще всего оказывается, что ему нужно присоединиться к общему проекту какой-то команды, а не писать свой код с нуля.
Любой код имеет собственную логику, основан на определенных принципах, в нем встречаются паттерны и технологии, характерные для команды, к которой присоединился программист. Но как начать быстро понимать чужой проект, при том что он вряд ли небольшой, а документации часто либо вообще нет, либо она недостаточна и неточна?
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Skillbox рекомендует: Онлайн-курс «Профессия Frontend-разработчик» [1].
На самом деле лучшая документация — это сам код и те, кто этот код создавал (при условии, что они до сих пор где-то рядом, а не ушли из компании). Как можно снизить временные затраты до минимума и быстро приступить к работе, внося и свою лепту?
Я неоднократно сталкивался с такой ситуацией за последние 15 лет своей работы программистом, и вот мои размышления по этому поводу.
Первая вещь, которую вы должны сделать, — потратить немного времени на то, чтобы понять, какую задачу (задачи) выполняет приложение, код для которого вы создаете. Это глобальная задача; решив ее, вы справитесь и со всем остальным.
Нельзя работать над проектом, не представляя себе, зачем он вообще нужен. Общее понимание позволит вам быстрее разобраться в мелочах. Кроме того, ваша собственная работа будет выполняться более слаженно с остальным коллективом. Кирпичик за кирпичиком — так и строится дом.
После того как вы узнали основную задачу, посвятите себя разбору выполнения кода и его логики.
Архитектура некоторых проектов довольно сложна, в особенности если базовые технологии этих проектов вам не очень хорошо знакомы. В самом начале постарайтесь найти техническую документацию (или же поспрашивать о ней коллег), с тем чтобы видеть основную логику.
Держа в голове структуру проекта, вы быстрее сможете начать работу, причем так, чтобы не мешать функционированию всех остальных частей, которыми занимаются другие члены команды.
В проекте могут встречаться фрагменты, которые нарушают общую логику, но, зная идею и архитектуру, вы сможете исправить проблему, переставить или изменить «кирпичики» так, чтобы они идеально вписывались в общее здание.
Существует большое количество паттернов, используемых разработчиками при написании кода. Это структурные шаблоны, «поведенческие», технологические и другие. Все они помогают типизировать способы решения часто встречающихся проблем при проектировании программ.
Понимание того, какие шаблоны используются в вашем текущем проекте, поможет уже на уровне классов понять, как функции должны быть встроены в код. В итоге вы сможете создавать связный код, который будет соответствовать общей логике и паттернам, что в конечном итоге приведет к гораздо меньшему количеству комментариев к коду, лучшему его пониманию и оперативному устранению ошибок в случае необходимости.
Поработав немного над проектом, вы сможете с первого взгляда понимать, какие участки кода вписываются в общую структуру, а что требует рефакторинга.
В большинстве команд есть определенные правила, вернее, набор правил, согласно которым все действуют. Речь идет не только про общие принципы работы, но и про использование классов и уровней приложения. Если представители команды руководствуются одними и теми же руководящими принципами, то разрабатываемый код легче понимать и читать.
Скорее всего, у команды, к которой вы присоединитесь, тоже есть руководящие принципы, которые вам необходимо изучить. В первую очередь они касаются того языка программирования, который является основным при разработке.
Вы можете спросить, где вообще взять всю информацию о проекте, его архитектуре, шаблонах и руководящих принципах. Есть несколько методов получения необходимого, кроме тех, что уже озвучивались выше:
Вообще говоря, рефакторинг — лучшая возможность вовлечь вашу команду в обсуждение того, какие руководящие принципы стоит пересмотреть, а какие — использовать в дальнейшем.
Делитесь с командой собственными наработками, активно принимайте участие в рабочих встречах, обсуждайте текущие проблемы, архитектуру приложения и его элементов, шаблоны и другие важные моменты. Рабочие встречи могут стать надежным каналом получения дополнительной информации; на них же стоит рассказывать о своих наблюдениях/достижениях, о том, что может оказаться полезным для всех.
В итоге вы сможете не только быстро начать работу, но и влиться в команду, став незаменимым ее участником в течение короткого времени.
Конечно, вам будут встречаться люди, с которыми тяжело общаться; проблемы будут и с кодом. Но это случается почти всегда — бывают команды, где все идеально, но их мало.
Skillbox рекомендует:
- Практический курс «Мобильный разработчик PRO» [2].
- Онлайн-курс «С#-разработчик с нуля» [3].
- Двухлетний практический курс «Я — веб-разработчик PRO» [4].
Автор: Онлайн-университет Skillbox
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/309537
Ссылки в тексте:
[1] «Профессия Frontend-разработчик»: https://skillbox.ru/frontend-developer/?utm_source=skillbox.media&utm_medium=habr.com&utm_campaign=FRENDEV&utm_content=articles&utm_term=someonecode
[2] «Мобильный разработчик PRO»: https://skillbox.ru/agima/?utm_source=skillbox.media&utm_medium=habr.com&utm_campaign=AGIMA&utm_content=articles&utm_term=someonecode
[3] «С#-разработчик с нуля»: https://skillbox.ru/c-sharp/?utm_source=skillbox.media&utm_medium=habr.com&utm_campaign=CSHDEV&utm_content=articles&utm_term=someonecode
[4] «Я — веб-разработчик PRO»: https://iamwebdev.skillbox.ru/?utm_source=skillbox.media&utm_medium=habr.com&utm_campaign=WEBDEVPRO&utm_content=articles&utm_term=someonecode
[5] Источник: https://habr.com/ru/post/441356/?utm_source=habrahabr&utm_medium=rss&utm_campaign=441356
Нажмите здесь для печати.