Писать свой код учат всех, читать чужой — почти никого

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

Пятница, вечер, в очереди на ревью — PR коллеги на несколько десятков файлов. Половина изменений написана AI-ассистентом, и сам автор честно признаётся: «Вроде все работает, но объяснить каждую строчку не смог». Вы открываете diff и понимаете: писать здесь почти нечего. Нужно читать  и разбираться, что из этого на самом деле работает так, как задумано.

Именно это сегодня составляет основную часть работы большинства инженеров. По данным исследований, разработчики тратят около 60% рабочего времени на понимание существующего кода, а не на написание нового. На эту цифру ссылается профессор информатики Фелиенн Хермманс в книге The Programmer’s Brain, её же приводят в докладе GOTO и обсуждают в Gotopia.

Почему опыт перестаёт помогать

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

Марит ван Дейк (JetBrains) и Ханнес Ловетте (Axxes) обращают внимание на любопытную вещь: в университетах нас учат писать программы, но почти никогда не дают задания разобраться в чужой кодовой базе. В результате инженеры приходят в реальные проекты подготовленными к созданию нового кода, но не к работе с уже существующим. Именно поэтому многие senior-разработчики достигают своеобразного плато. Они научились быстро писать код, но не научились быстро понимать чужой.

AI сделал эту проблему заметнее

Можно подумать, что виноваты AI-ассистенты. На самом деле нет. Они лишь ускорили существующую тенденцию.

Если раньше коллега писал код самостоятельно, сегодня значительная часть изменений появляется уже готовой — после Cursor, Copilot, Claude или другого помощника. Но проверить этот код все равно должен человек.

Более того, AI иногда генерирует решения, которые выглядят абсолютно правдоподобно и даже проходят часть тестов, но содержат очень тонкие ошибки. По данным разбора CodeRabbit, проблемы с читаемостью втрое чаще встречаются именно в AI-сгенерированных PR, чем в написанных человеком: такой код кажется правильным почти до самого момента, когда обнаруживается проблема.

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

Люди, которые быстро разбираются в чужом коде, делают совсем не то, что кажется

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

Не начинать с первого файла

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

Сначала открывать тесты

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

Следить за данными, а не за функциями

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

Периодически переписывать код только для себя

Фелиенн Хермманс называет это когнитивным рефакторингом: временно заменить тернарный оператор на обычный if, развернуть цепочку вызовов или встроить небольшую функцию внутрь другой, чтобы понять логику. Так сразу становится видно, что обе ветки на самом деле почти одинаковы, а разница спрятана глубже. Эти изменения не попадут в Git — они нужны только вашему мозгу.

Что действительно стоит почитать и попробовать

Мы сознательно не включали материалы, которые учат «хорошему коду» вообще. Цель подборки — начать быстрее ориентироваться в чужих проектах.

The Programmer’s Brain — Фелиенн Хермманс

Пожалуй, лучшая книга про чтение кода — объясняет, почему незнакомый код перегружает рабочую память и как с этим бороться с помощью чанкинга, маяков (beacons), схем и аннотаций.

Из минусов — некоторые упражнения (например, карточки для запоминания синтаксиса или распечатка кода с ручными пометками) сначала кажутся непривычными опытным разработчикам. Но именно они основаны на исследованиях когнитивной психологии.

Exercism (бесплатно)

Большинство использует Exercism для решения задач. Попробуйте наоборот.

После выполнения упражнения откройте раздел Compare Solutions и разберите десяток чужих реализаций. Это одна из лучших тренировок чтения кода в безопасной среде: вы уже знаете постановку задачи, поэтому можете полностью сосредоточиться на чужих решениях.

Минус — качество треков зависит от языка. Например, Python и Go проработаны значительно лучше некоторых менее популярных.

Code Reading Club (бесплатно)

Наверное, самый необычный проект в подборке. Его участники вообще ничего не пишут. Они собираются и вместе читают код, обсуждая, как каждый пришёл к пониманию архитектуры.

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

Working Effectively with Legacy Code — Майкла Физерса

Практически вся современная работа с legacy так или иначе описывается на идеи Майкла Физерса: сначала понять систему, затем создать точки безопасности в виде тестов и только потом менять код.

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

Ultimate Clean Code Masterclass for 2026 — курс на Udemy

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

Вас ждет 13 часов видео, 21 квиз и восемь реальных кейсов рефакторинга. Автор курса, Krystyna Ślusarczyk (.NET Technical Lead с 10-летним опытом), разбирает принципы SOLID на живых примерах на C# и показывает, как применять их при рефакторинге существующего, не учебного кода.

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

Официальная страница курса

Что можно сделать уже сегодня

Есть упражнение, которое не требует ни денег, ни нового курса. Возьмите любой незнакомый open-source проект или свежий PR. Поставьте таймер на 20 минут.

За это время попробуйте:

• найти точку входа;
• открыть связанные тесты;
• проследить путь одной сущности через систему;
• объяснить назначение этого участка кода одним предложением.

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

Вывод

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

Читать чужой код — методика со своими приёмами и тренировками, а не бонус за выслугу лет. И чем больше кода пишут AI-ассистенты, тем ценнее инженеры, которые умеют быстро понять, проверить и объяснить уже готовое решение.

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

Переоцененные навыки: чему не стоит учиться на всякий случай в 2026 году

По теме

Переоцененные навыки: чему не стоит учиться на всякий случай в 2026 году

«На дашборде всё отлично»: что делать инженеру, если внезапно понадобился матстат

По теме

«На дашборде всё отлично»: что делать инженеру, если внезапно понадобился матстат