В мире разработки программного обеспечения часто принято считать, что чем больше кода написано, тем значительнее вклад программиста и быстрее продвигается проект. Подсчёт строк кода долгое время выступал в качестве простого и наглядного показателя продуктивности инженеров, служил основой для оценки прогресса и планирования. Однако, практика показывает, что такой подход может быть поверхностным и даже вредным для качества конечного продукта. История Билла Аткинсона, ключевого разработчика интерфейса и автора системы Quickdraw в проекте Lisa от компании Apple начала 1980-х годов, ярко иллюстрирует эту проблему, став своеобразной знаменитой историей под названием «Отрицательные две тысячи строк кода». В начале 1982 года команда программного обеспечения Lisa активно работала над подготовкой к запуску системы, и менеджменту казалось разумным внедрить механизм контроля: инженеры должны были еженедельно отчитываться о количестве написанных строк кода.
Для этого была введена специальная форма, необходимая к заполнению каждому разработчику каждую пятницу. Целью было отслеживать трудозатраты и видеть прогресс каждого сотрудника через количественные метрики. Однако, именно эта система подсчёта строк кода столкнулась с критикой со стороны Билла Аткинсона. Он был не просто обычным программистом — в своей работе он старался создавать максимально эффективный, компактный и быстрый код. Его основное убеждение было в том, что качество важнее количества, и чтобы программа работала лучше, нужно избегать раздувания кода и излишних строк.
Аткинсон не считал, что написав много строк кода, можно автоматически утверждать успех или продуктивность. В процессе доработки Quickdraw он смог переписать механизм вычисления регионов — одной из центральных частей системы для работы с графикой и интерфейсом. Его новая версия использовала более простой и универсальный алгоритм, который позволял выполнять операции с регионами почти в шесть раз быстрее. К тому же, благодаря этой оптимизации, код удалось уменьшить примерно на 2000 строк. Такой сокращённый, но при этом более производительный код стал настоящим прорывом в плане архитектуры и производительности.
Когда же наступило время заполнить заветную форму с количеством написанных строк кода за неделю, Аткинсон задумался и без лишних сомнений вписал в поле число «-2000». Он как бы «выдал» отрицательное количество строк, что означало, что он не добавлял код — он убирал избыточные и негодные участки. Это был вызов устоявшейся системе метрик и переосмысление того, что означает «прогресс» в программной инженерии. Реакция менеджеров на такой ответ была, как можно предположить, неоднозначной, но вскоре они перестали требовать от Билла заполнения формы вовсе. Это является косвенным признанием того, что механистический подход к измерению продуктивности по строкам кода не может охватить все нюансы эффективной работы разработчика, особенно в сложных проектах с акцентом на оптимизацию и качество.
Опыт Аткинсона — исключительно важный урок для современного программирования и управления проектами. Он подчёркивает, что оценка работы разработчиков должна учитывать не только количество написанного кода, но и эффективность, чистоту, читаемость и производительность решений. В противном случае, стимулируя разработчиков писать больше строк, менеджмент может непреднамеренно поощрять создание запутанного, избыточного и плохого кода, что в конечном счёте замедляет развитие проекта и снижает качество продукта. Эта история указывает на необходимость внедрения более гибких метрик и подходов для измерения успеха в работе программистов. Вместо фокусировки на количестве строк полезнее смотреть на результаты, архитектуру программного обеспечения, количество исправленных багов, отзывчивость интерфейса, время выполнения задач и другие показатели, отражающие реальную ценность изменений.
Оптимизация, как показал Билл Аткинсон, может выразиться в сокращении кода при одновременном улучшении производительности и стабильности. Случай с «отрицательными двумя тысячами строк» также носит символический характер: иногда исключение лишнего и отказ от переусложнений важнее, чем добавление новых функций или раздутие программных модулей. Такой подход соотносится с философией минимализма и чистого кода, который пропагандируют многие ведущие специалисты в отрасли. Компактный, хорошо структурированный код легче поддерживать, тестировать и улучшать в будущем, что важно для долгосрочного успеха продукта. Для современных разработчиков и менеджеров проектов история подталкивает к пересмотру устаревших методов оценки производительности и внедрению инновационных инструментов, таких как статический анализ кода, автоматизированное тестирование, метрики качества кода, ревью и командное сотрудничество.
В конечном итоге, технологии и процессы должны работать на создание качественного программного обеспечения, а не на количественное измерение активности. В заключение, случай Билла Аткинсона и его «отрицательных двух тысяч строк» служит прекрасным примером того, как правильный взгляд на программирование помогает создавать более быстрые, надёжные и эффективные системы. Это напоминание, что развитие в сфере IT — не просто наращивание объёмов кода, а умение улучшать и упрощать, делая программу максимально совершенной и полезной для пользователей.
