🧑‍💻 «Минус 2000 строк»: Как оптимизация кода перевернула подход к измерению продуктивности

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

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

Но обо всём по порядку.

📋 Как измерить то, что сложно измерить?

Менеджеры проекта Lisa в Apple решили отслеживать продуктивность своих инженеров с помощью очень простого показателя — количества написанных строк кода за неделю. Казалось бы, очевидная метрика, правда? Больше кода — больше работы сделано, проект продвигается вперёд, сроки соблюдаются.

Но Билл Аткинсон, автор знаменитой графической библиотеки Quickdraw, смотрел на это иначе. Для него эффективность означала писать не просто больше, а меньше. Звучит парадоксально, но чем меньше строк кода, тем он обычно чище, понятнее и быстрее выполняется. И это не пустые слова.

🧠 Эффективность против объёма

Работая над оптимизацией движка расчёта регионов в Quickdraw, Аткинсон полностью переписал механизм обработки, применив более простой и эффективный алгоритм. В результате его код стал работать почти в шесть раз быстрее, а объём кода сократился на две тысячи строк.

На момент, когда он получил бланк отчёта, ему оставалось лишь зафиксировать результат. Но как именно указать «прогресс» в сокращении строк? Аткинсон сделал самое логичное (и немного дерзкое) — указал минус две тысячи.

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

🔥 Последствия и реакция команды

Реакция менеджеров Apple не была задокументирована в деталях, но известно точно одно — Аткинсона перестали просить заполнять эти отчёты. Показательно, что инцидент оказался настолько показательным, что вошёл в историю IT как символ противостояния между формализмом и реальным качеством разработки.

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

💡 Авторское мнение

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

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

🌟 Технические детали

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

Это классический подход в программировании, известный как DRY (Don’t Repeat Yourself), который по сей день остаётся базовым принципом эффективной разработки.

📚 Выводы и уроки

История «минус 2000 строк» учит нас нескольким важным вещам:

• 📏 Количество строк кода — плохая метрика продуктивности.
• 🚀 Настоящая эффективность в разработке кода — это скорость и простота.
• 🎯 Уменьшение сложности улучшает качество и поддерживаемость кода.
• 🙌 Нужно быть готовым оспаривать бессмысленные правила и метрики.

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

🔗 Источник новости:

• «-2000 Lines of code» на folklore.org