Сколько строк кода пишет программист: реальные цифры и что они значат

Тебя когда-нибудь спрашивали на собеседовании, сколько строк кода умеешь писать за день? Это звучит немного странно, но такой вопрос появляется чаще, чем хотелось бы. Многих начинающих специалистов волнует, а что, если я пишу слишком мало — меня уволят?

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

• Почему всех волнует количество строк кода
• Реальные цифры: что показывают исследования
• Что влияет на количество написанного кода
• Вся правда о больших и маленьких задачах
• Как не стать заложником "меряния строками"
• Полезные советы для программистов

Почему всех волнует количество строк кода

Когда речь заходит о работе программистов, многие почему-то цепляются за количество строк — мол, чем больше написал, тем больше пользы принес. Особенно эта тема популярна среди руководителей, далеких от программирования. Им просто: написал 500 строк — молодец, написал 20 — лентяй.

Эта логика перекочевала из индустриальной эпохи, где количество деталей с конвейера действительно показывало производительность. Но код — не гайки на заводе. Один хороший программист может решить проблему за 10 строк, а другой будет мудрить на 100, но работать это будет так же или даже хуже.

В разных компаниях подход к подсчету строк всё ещё встречается, хотя уже давно признан устаревшим. Например, по исследованию исследовательской группы McConnell, примерно треть менеджеров в США до сих пор добавляют KPI по количеству строк кода в отчеты.

Посмотри сам — удобная табличка:

Всё дело в том, что строки кода — это простой и быстрый способ хоть как-то замерить работу разработчика. Особенно когда нет технических знаний. Но если присмотреться, видно, что такой подход немного устарел и часто играет против самой идеи хорошего кода.

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

Реальные цифры: что показывают исследования

Многие представляют, что программисты пишут кучу строк кода каждый день. На деле всё намного скромнее — и на это есть конкретные причины. Фокусироваться только на количестве можно разве что на первом курсе вуза.

Есть исследование Standish Group, известное в IT-среде, где говорится: средний разработчик в больших проектах пишет около 10-20 строк рабочего кода в день. Для задачи высокого уровня это вообще норма, и иногда это могут быть даже меньшие числа.

"В среднем за год обычный разработчик создаёт 10 000 строк продуктивного кода, но большая часть рабочего времени уходит не на набор текста, а на чтение, тестирование и исправление ошибок." — из отчёта Standish Group CHAOS Report

Интересный момент: сотрудники Google и Facebook признаются, что средний темп написания кода — около 50-100 строк за неделю, если задача требует качества, тестов и ревью от коллег.

Вот табличка с реальными средними цифрами по разным сферам и компаниям:

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

Что влияет на количество написанного кода

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

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

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

Третье — стек технологий. Программист на Python может писать меньше строк, чем тот же backend-разработчик на Java, но сама работа при этом будет не проще и не тяжелее. К примеру, фреймворки вроде Django или Laravel оборачивают большую часть логики в несколько строк, и строки кода тут вообще не показатель.

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

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

Вся правда о больших и маленьких задачах

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

Многие компании уже не смотрят просто на строки кода. Один и тот же функционал можно написать полностью по-разному: опытный программист сделает это за 20 строк, а новичок — на 200. При этом оба создают рабочий код.

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

По опыту компаний типа Google или JetBrains, на задачи тратят разное число строк, и это очень плавает:

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

• Мелкая задача — не гарантирует быстрой сдачи. Под капотом могут вскрыться старые баги.
• Крупная задача нередко делится на пачку маленьких тикетов — чтобы не путаться и проще отслеживать результат.
• Бывают «невидимые» задачи: настройка среды, документация, автоматизация процессов. Эти задачи часто почти не видны по коду, но на них уходит куча времени.

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

Как не стать заложником "меряния строками"

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

В крупных IT-компаниях, по данным Stack Overflow, средний разработчик пишет от 10 до 80 строк кода в день, работающих потом в продакшене. Остальное время тратится на размышления, обсуждения, код-ревью и тесты. Например, в Google или Яндексе часто ценят даже не строчки кода, а то, насколько просто поддерживать и масштабировать твои решения.

Почему не стоит гнаться за количеством? Вот несколько минусов такого подхода:

• Высокий темп часто приводит к появлению багов и костылей.
• Чистый и ясный код почти всегда короче и легче поддерживается.
• Строки ради строк быстро приводят к выгоранию и потере мотивации.

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

Полезные советы для программистов

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

• Строки кода — это не главное. На практике качество почти всегда важнее количества. По данным исследования GitHub за 2024 год, успешные проекты чаще всего имеют меньше кода, чем их аналоги: они проще для поддержки, быстрее дорабатываются.
• Читай чужой код. Ты удивишься, как быстро учишься новым подходам и решениям. Совсем не зря на крупных IT-компаниях ревью кода — обязательная часть рабочего процесса.
• Планируй задачи на день: ставь конкретные цели, а не просто "что-то поделать". Используй чек-листы и трекеры — это реально сэкономит нервы и покажет твой прогресс.
• Регулярно рефактори свой код. Удаляй ненужные строки и переписывай сложные куски. По опыту старших разработчиков, чистый код экономит до 40% времени команды на баг-фиксы.
• Не бойся спрашивать советы у коллег. Обычно быстрый вопрос в чате экономит часы самостоятельных попыток разобраться.

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

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

Написать комментарий