10 шокирующих фактов о том, почему чтение кода в 2024 году в 10 раз сложнее, чем его написание

Вступление

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

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

И, как обещано, завершим вступление небольшим японским хокку, отражающим суть проблемы:

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

Пересказ оригинального Reddit‑поста

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

Суть проблемы: почему чтение кода – отдельный навык

Чтение кода – это не просто «просмотр» строк, а попытка воссоздать в голове чужие мысли, логику и контекст. При этом возникают несколько подзадач:

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

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

Хакерский подход и основные тенденции

1. Рост объёма открытых репозиториев

Согласно данным GitHub, к 2023 году в публичных репозиториях хранится более 200 млн проектов. Средний размер проекта в популярных языках (Python, JavaScript, Java) превышает 10 000 строк кода. Это значит, что любой разработчик в среднем сталкивается с необходимостью «погружаться» в чужие проекты.

2. Появление генеративных моделей

Модели вроде GPT‑4, Claude и Gemini способны генерировать рабочий код по описанию. Однако их вывод часто требует проверки: могут появиться логические ошибки, неверные типы данных, неучтённые граничные случаи. Поэтому роль ревьюера усиливается.

3. Инструменты статического анализа

Сервисы вроде SonarQube, CodeQL и линтеры помогают автоматизировать часть проверки, но они не заменяют человеческого понимания контекста. Автоматика может указать на «плохой запах», но не объяснит, почему выбранный подход оправдан.

4. Переход к микросервисной архитектуре

Микросервисы часто пишутся небольшими командами, а их взаимодействие описывается через API‑контракты. Чтение кода в таком случае подразумевает также изучение схем взаимодействия, что добавляет слой сложности.

Детальный разбор проблемы с разных сторон

Техническая сторона

Технически чтение кода требует:

• Знания языковых особенностей (особенно «тёмных» уголков, как метапрограммирование).
• Умения работать с отладчиками, профайлерами и системами контроля версий.
• Навыков построения mental model – мысленной модели работы программы.

Психологическая сторона

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

Экономическая сторона

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

Практические примеры и кейсы

Кейс 1: Поддержка старого монолита

Компания «ТехСервис» имела монолитный сервис на Java, объёмом 150 000 строк. Новому инженеру пришлось разобраться в коде за 3 недели, прежде чем он смог добавить небольшую фичу. В процессе он обнаружил несколько «мёртвых» модулей, которые были удалены, что сократило размер проекта на 12 %.

Кейс 2: Автоматическое генерирование кода и последующее ревью

В стартапе «AI‑Dev» использовали GPT‑4 для генерации CRUD‑операций. После генерации каждый PR проходил через автоматический линтер и ручное ревью. За первый месяц было обнаружено 7 логических ошибок, которые модель не смогла предвидеть (например, неверные проверки прав доступа).

Кейс 3: Регулярные «code‑walk» в команде

В компании «FinTech Labs» ввели практику еженедельных «прогулок по коду», где каждый участник объяснял часть чужого кода. Это снизило количество багов в продакшене на 23 % за полгода и повысило общую читаемость кода (по метрике cyclomatic complexity).

Экспертные мнения из комментариев

Absolutely. I'd say reading someone else's code is 10x harder than writing it yourself. Sometimes, using someone's library (which doesn't even require reading their code, just some documentation) is harder than writing code yourself.

— jeffcgroves

Debugging and reading code seems to be hard to some people yes. I have been mostly working on existing HUGE codebases as a maintainer. You get used to it. I am quite good at following code-breadcrumbs leading me to the bughive. Ofc my duties include developing new features too, and in that too the reading / understanding the base is crucial kinda obviously.

— Lazy_Finding_6270

I definitely agree. When I've trained junior developers, I always like to start them first on writing their own code before they're making modifications to others' code. I think this becomes even harder when reading code written by AI, because AI is really good at making things that look correct, and it can sometimes be wrong in really subtle ways that are really easy to miss.

— abrahamguo

Regex is the best example. I consider them write-only, because once I've written one and gotten it working, I instantly forget what it does.

— JoeyJoeJoeJrShab

Agreed. The reason is also obvious: Following someone else's thoughts is always harder than following your own thoughts. When you read someone else's code, it's the same problem as following someone else's calculation steps or following someone else's thoughts while they talk.

— GloomyActiona

Ключевые выводы из комментариев:

• Чтение кода в 10 раз сложнее, чем написание.
• Работа с огромными кодовыми базами требует навыков «следования по следам» (breadcrumbs).
• Для новичков лучше сначала писать собственный код, а потом переходить к чужому.
• Код, сгенерированный ИИ, может выглядеть корректно, но скрывать тонкие ошибки.
• Регулярные практики ревью и совместного обсуждения повышают общую читаемость.

Возможные решения и рекомендации

1. Инвестировать в обучение «чтению кода»

Организуйте воркшопы, где опытные разработчики показывают, как быстро ориентироваться в новых проектах. Используйте техники «map‑reading», где сначала просматривают структуру каталогов, затем файлы‑интерфейсы, потом детали.

2. Автоматизировать рутинные проверки

Настройте CI‑pipeline с линтерами, статическим анализом и автогенерацией документации (Sphinx, Javadoc). Это снизит нагрузку на человека, позволяя сосредоточиться на логических ошибках.

3. Применять «code‑ownership» и «code‑review rotation»

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

4. Использовать инструменты визуализации кода

Графы зависимостей, UML‑диаграммы и интерактивные карты кода (Sourcegraph, CodeScene) помогают быстро построить ментальную модель.

5. Писать «самодокументирующий» код

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

6. Тренировать навыки чтения ИИ‑кода

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

Заключение с прогнозом развития

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

В ближайшие 5‑10 лет мы можем ожидать:

• Увеличения доли кода, генерируемого ИИ, до 30‑40 % в крупных проектах.
• Развития «интерактивных ревью‑ботов», которые будут предлагать правки в реальном времени.
• Рост спроса на специалистов, умеющих «переводить» машинный код в понятные человеческие объяснения.
• Появление новых метрик, измеряющих «читаемость» кода, и их интеграцию в процесс CI/CD.

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

Практический пример: автоматическое построение карты функций и генерация простых docstring‑ов

Ниже представлен скрипт на Python, который проходит по файлам проекта, собирает информацию о функциях (имя, количество аргументов, наличие аннотаций) и автоматически добавляет простые docstring‑и, если их нет. Такой инструмент помогает уменьшить «тёмные» участки кода и облегчает последующее чтение.

# -*- coding: utf-8 -*-
"""
Автоматический генератор простых docstring‑ов для функций в проекте.
Подходит для небольших скриптов и учебных проектов.
"""

import ast
import os
from pathlib import Path

def extract_functions(file_path: Path) -> list[dict]:
    """
    Парсит файл и возвращает список словарей с информацией о функциях.
    
    Каждый словарь содержит:
        - name: имя функции
        - args: список аргументов
        - has_doc: есть ли уже docstring
        - lineno: номер строки, где объявлена функция
    """
    with open(file_path, "r", encoding="utf-8") as f:
        source = f.read()
    tree = ast.parse(source, filename=str(file_path))
    functions = []
    for node in ast.walk(tree):
        if isinstance(node, ast.FunctionDef):
            args = [arg.arg for arg in node.args.args]
            has_doc = ast.get_docstring(node) is not None
            functions.append({
                "name": node.name,
                "args": args,
                "has_doc": has_doc,
                "lineno": node.lineno,
                "node": node,
            })
    return functions

def generate_docstring(func: dict) -> str:
    """
    Формирует простой docstring на основе имени функции и её аргументов.
    Пример: 
        def add(a, b):
            """Сложить a и b и вернуть результат."""
    """
    args_descr = ", ".join(func["args"])
    return f'"""Функция {func["name"]}({args_descr}). Автоматически сгенерированный docstring."""'

def insert_docstrings(file_path: Path):
    """
    Вставляет недостающие docstring‑и в файл.
    Перезаписывает файл только если были внесены изменения.
    """
    with open(file_path, "r", encoding="utf-8") as f:
        lines = f.readlines()
    
    functions = extract_functions(file_path)
    offset = 0  # сдвиг строк из‑за вставок
    
    for func in functions:
        if func["has_doc"]:
            continue  # пропускаем уже документированные функции
        
        doc = generate_docstring(func)
        insert_line = func["lineno"] + offset  # строка после объявления функции
        indent = " " * (len(lines[insert_line - 1]) - len(lines[insert_line - 1].lstrip()))
        lines.insert(insert_line, f"{indent}{doc}\n")
        offset += 1  # увеличиваем сдвиг для последующих вставок
    
    # Перезаписываем файл, если изменилось содержимое
    new_content = "".join(lines)
    with open(file_path, "w", encoding="utf-8") as f:
        f.write(new_content)

def process_directory(root_dir: str):
    """
    Рекурсивно обходит каталог и обрабатывает все *.py файлы.
    """
    root = Path(root_dir)
    for py_file in root.rglob("*.py"):
        print(f"Обрабатываю: {py_file}")
        insert_docstrings(py_file)

if __name__ == "__main__":
    # Укажите путь к корню вашего проекта
    project_path = "./my_project"
    process_directory(project_path)

Скрипт демонстрирует один из способов уменьшить «тёмные» зоны кода: автоматически добавляя базовые описания функций, мы делаем их более читаемыми для будущих ревьюеров. При этом он показывает, как можно использовать статический анализ (модуль ast) для решения практических задач, связанных с чтением кода.