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

Перевод поста 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 млн. строк.

Не нашли ответ на свой вопрос? Возможно, вы найдете решение проблемы на нашем канале в Youtube! Здесь мы собрали небольшие, но эффективные инструкции. Смотрите и подписывайтесь на наш youtube-канал!

Смотреть на Youtube

Руководства и обзоры

1 Что нужно восстановить?

Видео

MP4, AVI и HD видео хранятся на телефоне и / или по ошибке удаляются вместе с фотографиями и другими медиафайлами.

Контакты

Номера телефонов друзей и знакомых из приложения «Контакты Android», журналы вызовов; Восстановление SIM-карты.

Фото

Удалены файлы JPG / PNG из Галереи Android; фото, загруженные на мобильный, файлы повреждены после восстановления.

Смс и сообщения

Чаты WhatsApp и Facebook, текстовые сообщения в соцсетях, информация на сим-карте

2 Где пропали файлы?

На sd-карте

Фотографии и документы хранятся на SD-картах. Часто на них случайно удаляются файлы

На телефоне

Программы для восстановления не распознают внутреннее хранилище телефона как диск, но есть другие решения.

На USB флешке

Эти небольшие устройства хранения данных часто выходят из строя или на них появляются ошибки чтения.

На HDD или SSD

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