Числа Норриса в программировании кода

Перевод поста Norris Numbers, автор Lawrence Kesteloot

В 2011 году Джон Д. Кук написал следующее сообщение в блоге:

Мой друг Клифт Норрис выявил фундаментальную константу, я называю ее числом Норриса. Это средний объем кода, который неподготовленный программист может написать, прежде чем он или она упрется в стену. Клифт оценивает его в 1500 строк. Код становится настолько запутанным, что автор не может отладить или изменить его, не затратив на это титанические усилия.

Я не знаю начинающих программистов, чтобы подтвердить этот эффект, но я заметил следующую стену в путешествии программиста, которая встает на пути после 20000 строк кода. Я изменю номер Норриса на 2000, чтобы получить хорошую силу в десять прыжков.

Я проходил через 20000-строчную стены неоднократно - во время моей первой работы в колледже. Так же как и мои коллеги (которые были такие же молодые, как и я). В DreamWorks у нас было 950 программ для аниматоров в использовании, и количество строк колебалось между 20000 и 25000 строками. После чего нужно было приложить слишком много усилий, чтобы добавлять новые функции.

В середине 1996 года мне и двум программистами была поставлена ??задача написать инструментарий для освещения DreamWorks. Я знал, что планируется намного больше, чем 20000 строк кода. Я изменил свой ??подход к программированию - программа была успешно написана через год на отметке 200,000 строк. (с запланированным выходом "на пенсию" в 2013 году; ежедневно она использовалась более 16 лет, сделано 32 фильма). С тех пор я написал еще несколько программ в диапазоне от 100000 до 200000 строк кода. Я уверен, что я упираюсь в следующий стену - я чувствую это.

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

Эдсгер Дейкстра написал в 1969 году:

Ребенок ползает на четвереньках со скоростью, скажем, одна миля / час. Но скорость в тысяча миль / час может развить сверхзвуковая волна. Сравнивать объекты с движущимися способности ребенка и самолета некорректно, так как "рожденный ползать летать не может".

Начинающий программист, Клифт Норрис имеет в виду обучение ползать, затем ковылять, ходить пешком, бегать спринт, и он думает, что, "При таких темпах ускорения я могу достичь сверхзвуковой скорости!". Но он работает в пределах 2000 строк, потому что его навыки не выросли. Он должен двигаться по-другому, используя машину, ехать быстрее. Затем он учится водить машину: сначала медленно, потом все быстрее, но работая в пределах 20000 строк. Навыки вождения не позволяют управлять самолетом.

Мой друг Брэд Грэнтхам объясняет это тем, что у начинающего программиста есть проблема "грубой силы" . Думаю, это верно: если код преодолевает планку в 2,000 строк, вы можете написать любой запутанный мусор и полагаться на свою память. Продуманные классы и пакеты позволят вам масштабировать код до 20000 строк.

В моем случае это позволяет упрощать задачу. Можно отказаться от добавления любого объекта или строки кода, если вы не нуждаетесь в этом прямо сейчас, если это не нужно в крайней степени. Я уже касался этого в статье Каждая строка - потенциальный баг (и до этого - в публикации Простота - это благо). Главный архитектор эффектов при DreamWorks выразился так:

Для меня, гениальность [осветительного ПО] заключалась в выборе небольшого набора функций, которые были удобны при написании и поддержке инструментов освещения.

Как технический руководитель я вижу свой основной вклад как сказать "нет" функциям, которые, как полагают коллеги, важны, но неуместны. Реальный трюк - знать, когда новая функция добавляет линейную сложность (за счет собственного веса) или геометрическую сложность (взаимодействуя с другими функциями). Обоих вариантов следует избегать, но последний требует экстра-убедительного обоснования.

Например, в 2012 году ядро Linux'а содержало 15 миллионов строк кода. Из них 75% имели линейную сложность (драйверы, файловые системы и архитектурно специализированный  кода); у вас могли быть десятки видеодрайверов, которые не взаимодействуют друг с другом. Остальные - более геометрические.

Точка зрения Дейкстры такова: трудно научить этим передовым методам, потому что они имеют смысл только в 20000- или 200000-строчных программах. Любой класс или учебник должен ограничивать свои примеры до нескольких сотен строк, а метод грубой силы при этом работает на ура. Вам действительно нужен учебник, чтобы показать программу в 30000 строк, а затем продемонстрировать новую функцию, которую легко добавить, потому программа не слишком сложна. Но это невозможно.

Я не знаю, что мне придется изменить, чтобы пройти через стену в 200000 строк. Недавно я переключился на более функциональный стиль. Возможно, это позволит мне "прорваться".

И мне действительно любопытно посмотреть на линию барьера в 2 млн. строк.