Как научиться читать и понимать код программирования

Разработчики проводят до 80% рабочего времени за чтением кода. Этот навык зачастую важнее, чем умение писать его с нуля.
Есть несколько популярных методов, которые помогут разобраться, как читать код, — их стоит запомнить. Расскажем о них ниже.

Зачем читать чужой код

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

В идеале код нужно хорошо написать, задокументировать, структурировать и протестировать. Но такие идеальные ситуации случаются редко.

Писать, читать и тестировать свой и чужой код на ошибки учат на курсе Skypro «Python-разработчик». В программе минимум теории и много практики — так новые навыки усвоятся быстрее. А центр карьеры подготовит к собеседованиям и поможет написать классное резюме, чтобы вы быстрее нашли работу в новой профессии.

Допустим, вы пришли на проект, делаете задачу. Нужно прочитать код, который написал предыдущий программист, и вы понимаете, что ничего не понимаете: надо проникнуть в ход мыслей предыдущего разработчика, попытаться понять, о чём он думал, когда писал, и вообще — он ли его писал.

Давайте разберемся, каких принципов придерживаться, чтобы понимать код быстро и легко.

Как правильно читать код

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

С чего начать

Вместо того чтобы читать код сверху вниз, как книгу, лучше идти от конкретной задачи. Сначала найдите знакомые фрагменты или простые участки — от них и стройте понимание всей программы. Ниже — несколько шагов, которые помогут начать разбор кода.

Поиск понятной части кода

Найдите понятную часть кода и раскрутите ее. Допустим, перед вами отчет по месячным расходам пользователя.

1. Сначала определите, в каком конкретном месте код создает этот файл.
2. Потом поймите, в каком месте отчет заполняется.
3. Сделайте еще один шаг и выясните, откуда взялась информация о пользователе и так далее, шаг за шагом следуйте из конца в начало.

Так вы поймете, как организована основная масса кода: где определены функции и переменные, как называются файлы, которые отвечают за бизнес-логику. А еще поймете логику программистов, которые писали этот код.

Этот процесс чем-то похож на судоку: сначала вы решаете легкие клеточки, а они приводят к решению сложных и неочевидных.

Git blame и git log

Скорее всего, код, который вы пытаетесь понять, импортировали из общей системы контроля версий, например Git или SVN. Посмотрите историю изменения непонятной строчки с помощью команд git blame и git log — они выдадут историю всех коммитов и изменений.

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

Git blame может дать информацию об авторе этого кода — расспросите его лично.

Работать в Git и GitHub учат на курсе Skypro «Веб-разработчик». Опытные наставники рассказывают об основных инструментах разработчика и помогают студентам освоить их на реальных задачах. Больше половины программы — практика. А результаты выполненных заданий можно добавить в портфолио.

Картина целиком

Если есть документация, обязательно ее прочтите. Сначала может показаться, что код сложный и непонятный, продолжайте изучать. И скоро поймете, что в этих неясных строках есть смысл. Сначала получи́те общее представление, а потом погружайтесь в детали.

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

Чтение спецификации

Если в репозитории, который вы изучаете, есть test suite (набор тестов, которые проверяют, правильно ли работает код), то половина дела сделана за вас.

Тесты — отличное место, откуда стоит начинать читать код. Они рассказывают о намерениях разработчика.

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

Если кажется, что процесс всё равно непонятен, запустите конкретный тест в формате отладки программы: большая часть тестов не требует запуска всего приложения, поэтому на этот шаг вы потратите меньше времени, чем на полный трейсинг — отслеживание всего пути работы программы.

Комментарии как подсказки

Оставляйте закладки в тех местах программы, которые показались наиболее интересными или непонятными. Такие пометки поддерживают почти все редакторы кода.

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

Поиск Main

Когда получаете код, который нужно прочитать и понять, первое, что нужно сделать, — запустить его и посмотреть, что он делает: что принимает в качестве входных и каковы выходные данные.

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

Структура и стиль

Обратите внимание на стиль, когда читаете код. Потому что в итоге нужно будет писать его в таком же стиле.

Изучите даже такие вещи, как соглашения об именах, интервалы между строками и расстановка скобок.

Определите общий уровень абстракции. Если это высокоабстрактный код со многими слоями, то вы будете писать такой же.

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

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

Мусорная часть кода

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

Не переживайте и смело удаляйте эти части. Человек, который придет на проект после вас, скажет спасибо.

Повторение и закрепление

Повторите процесс чтения и запуска несколько раз. Это нужно, чтобы начать понимать общую кодовую базу.

Типичные ошибки при чтении кода

Даже опытные разработчики иногда читают код неэффективно. Назовем распространенные ошибки, которых стоит избегать.

Читать строку за строкой «в лоб». Пытаться сразу понять всё с первой строчки — утомительно и бесполезно. Без контекста даже простой код может показаться запутанным.

Как лучше: сначала просмотрите структуру, потом погружайтесь в детали.

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

Как лучше: изучите архитектуру проекта перед чтением функций.

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

Как лучше: сначала определите, зачем функция нужна, а потом разбирайте, как она работает.

Пропускать комментарии и документацию. Иногда документация скучная или устарела, но чаще всего она дает важные подсказки.

Как лучше: бегло прочитайте комментарии — особенно над модулями и ключевыми методами.

Игнорировать запуск и процесс отладки. Пытаться всё понять только мысленно — сложно. Если вы не запустите код, вы не увидите, как работает логика на практике.

Как лучше: ставьте точки останова — места, в которых вы хотите преднамеренно остановить работу программы, выводите переменные, запускайте в песочнице.

Пренебрегать контекстом задачи. Понимать код вне контекста задачи — всё равно что читать сцену без знания сюжета.

Как лучше: сначала разберитесь, что делает программа и зачем, а уже потом — как.

Краткие итоги

• Читать код — часть работы: разработчики тратят на это до 80% времени.
• Нельзя читать код «в лоб»: сначала — структура, потом — детали.
• Системы контроля версий, например, Git — ваш друг: используйте git blame и git log, чтобы понять, кто и зачем написал непонятную строку.
• Начните с тестов: они показывают, что ожидается от кода.
• Изучите документацию и структуру проекта: архитектуру, названия файлов, слои кода.
• Главное — понять, зачем написали код, а не как именно.
• Не бойтесь «мусорных частей»: бесполезные файлы можно удалять.
• Будьте последовательны: стиль кода важнее красоты — он делает проект понятным другим.