Писать свой код учат всех, читать чужой — почти никого
Принято считать, что если человек стал сильным разработчиком, то навык чтения чужого кода придёт сам собой. Практика и исследования говорят об обратном.
Принято считать, что если человек стал сильным разработчиком, то навык чтения чужого кода придёт сам собой. Практика и исследования говорят об обратном.
Писать и читать код — разные когнитивные процессы. В первом случае вы создаёте собственную модель системы. Во втором — пытаетесь восстановить чужую. И чем больше кода появляется благодаря AI, тем чаще разработчику приходится не сочинять решение с нуля, а проверять, действительно ли оно делает то, что кажется на первый взгляд.
Содержание
Примечание Adviser
В этой статье ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Пятница, вечер, в очереди на ревью — 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 году
«На дашборде всё отлично»: что делать инженеру, если внезапно понадобился матстат
«На дашборде всё отлично»: что делать инженеру, если внезапно понадобился матстат
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Михаил Левин, можно поинтересоваться: вы написали эту статью с советами - из собственного опыта, или опросили программистов, или попросили ИИ?
К сожалению, после этой статьи кто-то действительно может поверить, что читать чужой код - это такое быстрое рутинное занятие, которому легко обучаются по каким-то книгам, и начнет требовать этого от сотрудников.
Выглядит как новый пункт для оценочного списка "рекрутеров".
Книга - это готовый продукт для потребителя (читателя).
Программный код - это скрытое от потребителя "внутреннее устройство" какого-то продукта.
Поэтому "читать код" - это скорей смотреть на какой-то механизм изнутри, как сейчас говорят, "под капотом", не видя его с внешней стороны, и определять, что перед вами, автомобиль, самолет или кухонный комбайн.
Вы видели программы с многотысячными строками кода, создаваемые на протяжении многих лет разными разработчиками, в разных стилях, с исправлениями и т.п.? Это огромный объем символов, знаков, который нужно переработать на нескольких уровнях, находясь в особом состоянии, чтобы в результате перевести полученный смысл в слова естественного языка для обсуждения с кем-то. (Когда рекрутеры требуют от программистов умения общаться, понимаешь, что сильные специалисты останутся за бортом).
Все это возможно, это часть профессии со своими приемами и секретами, но какова цена? Поэтому, когда вы популяризируете аналогию чтения кода с чтением книги, хочется вас быстрей остановить.
Если вы взялись читать чужой код, как вы узнаете, что задумано? Прочитаете стостраничную несовершенную спецификацию чужой задачи, разберетесь в ней, а потом будете читать бесконечные строки кода и сличать смыслы там и там?
Кстати, до ИИ, ревью чужого кода этого даже не требовало. Конечно, если вам нужно изменять код ушедшего коллеги, тогда да, придется во всем разбираться.
Для вашей же задачи - с кодом ИИ могут быть разные варианты. Если вы хорошо знаете, что хотите получить, сумели внятно донести это до ИИ, понимаете что ИИ вам советует и кодит - это одно. Если же вы толком не понимаете задачи, не очень хорошо владеете используемыми инструментами, как вы сможете оценить результат?
Можно я зайду на вашу территорию и поищу аналогию (даже похожую на используемую вами) там?
Представьте, что вам как журналисту поручили написать статью на какую-то незнакомую тему. Читатели бы ожидали, что вы выедете на место и увидите все своими глазами (если речь о событии), поговорите с кем-то компетентным или почитаете множество первоисточников (если о каком-то явлении), а затем хорошим журналистским языком расскажете это. Вместо этого вы, например, просите написать статью AI-ассистента. И получаете гладко написанный текст с некоторой убедительной для вас завершенной картиной. (Которая на самом деле далека от реальности, но вы этого не знаете). Как вы сможете "быстро понять, проверить и объяснить" ее, если у вас нет собственных знаний об этом?
Фельетон ?