Как читать чужой код и не сойти с ума

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

Программирование — профессия, где читаешь в десять раз больше, чем пишешь. А учат почему-то только писать.

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

Почему чужой код читать так тяжело

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

Вторая беда — перегрузка рабочей памяти. Чтобы понять одну функцию, надо помнить, что делают пять других, которые она вызывает. А чтобы понять их, надо помнить ещё десять. Мозг переполняется, и наступает то самое ощущение «я ничего не понимаю».

Стратегия: сверху вниз, а не подряд

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

Сначала карта, потом улицы. Посмотрите структуру папок, README, точку входа. Поймите общую форму проекта, прежде чем нырять в детали.
Идите от вопроса, а не от начала. Не «прочитать весь проект», а «понять, что происходит, когда пользователь нажимает кнопку входа». Конкретный вопрос даёт нить, по которой можно идти.
Прыгайте по определениям. Используйте «перейти к определению» в редакторе. Видите вызов функции — прыгайте в неё, поняли — возвращайтесь. Так вы идёте по реальным связям, а не по порядку строк.

Не пытайтесь понять всё

Важнейший психологический приём: разрешите себе не понимать большую часть кода. Вам почти никогда не нужно понять весь проект. Вам нужно понять одну тропинку — путь от точки А до точки Б, по которому идёт интересующая вас логика. Всё остальное можно держать как «чёрные ящики»: знаю, что эта функция возвращает список пользователей, а как именно — пока неважно.

Приёмы активного чтения

Пассивное «глазами по экрану» работает плохо. Превратите чтение в действие:

Запустите и потыкайте. Поставьте точку останова или print в подозрительном месте и посмотрите, какие данные туда реально приходят. Живые данные объясняют код лучше любых комментариев.
Рисуйте схему. На бумаге или в заметках набрасывайте, кто кого вызывает и как текут данные. Вынесите граф из головы наружу — рабочая память скажет спасибо.
Переименовывайте мысленно. Если переменная названа x, а делает она «отфильтрованный список заказов» — так и держите её в голове. Понимание кода во многом про восстановление смысла плохих имён.
Смотрите историю. git blame и сообщения коммитов часто объясняют, зачем появилась странная строчка, которую иначе не понять.

Странный код — не всегда глупый код

Новичок, наткнувшись на непонятный костыль, думает «какой идиот это писал». Опытный инженер думает «интересно, какую проблему этим решали». Очень часто за уродливым куском кода стоит реальный баг или граничный случай, который не виден на первый взгляд. Это правило даже называют «забором Честертона»: прежде чем сносить непонятную ограду, выясни, зачем её поставили.

Чтение кода — это тренировка

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

Так что не паникуйте, открыв чужой проект. Никто не понимает его целиком с первого взгляда — даже его автор через полгода. Берите одну тропинку, идите по ней, рисуйте карту по пути. Город перестаёт быть страшным, как только у вас появляется маршрут.