Является ли научный код достаточно другой областью, чтобы игнорировать общие стандарты кодирования?

В последнее время я пытался обдумать следующий факт.

С одной стороны, существует множество руководств и стандартов кодирования для того, что считается «здоровым», «чистым», «хорошо написанным» и т. Д. Кодом. См. «Чистый код», который также широко обсуждается здесь. Пример правила: 7 длинных методов и 1 или 2 уровня отступа. Код, который не следует, каким-то образом должен умереть от плохой ремонтопригодности.

С другой стороны, я начинаю работать с OpenCV, OpenCascade, VTK и т. Д. Это научный код. У них есть 2-страничные методы (я сам), в OpenCascade есть метод или класс, разбитый на 10 файлов (здесь без шуток), иногда VTK тоже беспорядок. Все же эти проекты процветают, поддерживаются и широко используются!

Где подвох? Разрешено ли нам писать научный математический код таким образом, чтобы он просто работал, и мы можем его поддерживать? Является ли ты отдельным набором стандартов для таких проектов, если таковые имеются?

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

Является ли научный код достаточно другой областью, чтобы игнорировать общие стандарты кодирования?

Нет, это не так.

Исследовательский код часто «выбрасывают» и пишут люди, которые не являются разработчиками по образованию, какими бы сильными они ни были. Некоторый код исследования, который я написал, заставил бы меня плакать . Но это сработало!

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

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

Это еще сложнее, если весь этот код работает. Потому что это не сломано. Зачем это исправлять?

Все же эти проекты процветают, поддерживаются и широко используются!

Это ответ, в некотором смысле. Рабочий код все еще полезен, и поэтому он более вероятен.

Это может быть беспорядок, особенно на начальном этапе. Некоторые из этих проектов, вероятно, начинались как одноразовый проект, который «не нужно было бы повторно использовать никогда и можно было бы выбросить».

Также учтите, что если вы реализуете сложный алгоритм, может иметь смысл иметь более крупные методы, потому что вы (и другие, знакомые с научной стороной) можете концептуально лучше понять алгоритм. Моя дипломная работа была связана с оптимизацией. Иметь логику основного алгоритма в качестве одного из методов было гораздо легче понять, чем пытаться разбить его на части. Это определенно нарушало правило «7 строк на метод», но это также означало, что другой исследователь мог посмотреть на мой код и быстрее понять мои модификации алгоритма.

Если бы эта реализация была абстрагирована и разработана хорошо, эта прозрачность была бы потеряна для непрограммистов .

Другим ответчикам: Этот вопрос относится к кодовой базе библиотек с открытым исходным кодом для сложных вычислительных задач в одной или нескольких научных областях. Этот вопрос не о одноразовом коде. Пожалуйста, остановитесь на мгновение, чтобы убедиться, что вы понимаете каждый выделенный аспект, прежде чем писать ответ.

Я думаю, что люди часто думают, что все проекты с открытым исходным кодом начинаются со слов: «эй, у меня есть отличная идея для библиотеки, которая будет безумно популярна и будет использоваться тысячами / миллионами других», и тогда каждый проект происходит таким образом.

Реальность такова, что многие проекты начинаются и умирают. Смехотворно небольшой процент проектов «делают это» до уровня OpenCV или VTK и т. Д.

OpenCV начинался как исследовательский проект от Intel. Википедия описывает это как часть «серии проектов». Его первый не бета-релиз был в 2006 году, или через семь лет после его запуска. Я подозреваю, что изначально целью были осмысленные бета-версии, а не идеальный код.

Кроме того, «владение» OpenCV значительно изменилось. Это приводит к изменению стандартов, если все ответственные стороны не примут одинаковые стандарты и не будут соблюдать их на протяжении всего проекта.

Я также должен отметить, что OpenCV существовал в течение нескольких лет, прежде чем был опубликован Agile Manifesto, который вдохновляет Clean Code (а VTK почти 10). VTK был запущен за 17 лет до публикации Чистого кода (OpenCV был "только" за 9 лет до этого).

Ученые не разработчики. Их работа не в том, чтобы писать код как таковой. Их задача - решать проблемы, а программирование - это лишь один из инструментов, которые они могут использовать.

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

Будет ли все практикует фактические профессиональные узнает разработчиков во время ее карьеры пользу ученого? Абсолютно. Удастся ли каждому ученому потратить пять-десять лет своей жизни на разработку программного обеспечения? Возможно нет. Поэтому качество кода такое, как есть.

Другим фактором является культура. Если ваши пары не пишут чистый код, почему бы вам? Так как никому нет дела, вы на самом деле не склонны делать дополнительные усилия.

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

Игнорировать? Нет. Пересмотреть и отрегулировать? Конечно. Много научного кода интенсивно использует математику и критичен к производительности. Такие вещи, как накладные расходы на вызовы функций, могут на самом деле стать проблемой, поэтому вы можете получить более глубоко вложенные структуры, чем вы видите в типичном коммерческом приложении. Это не значит, что вы должны сначала погрузиться в тысячу микрооптимизаций. Вы все равно должны сосредоточиться на выборе правильного алгоритма и делать только те оптимизации, влияние которых вы можете измерить.

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

Все существующие ответы охватили этот вопрос всесторонне. Тем не менее, я хотел бы указать, что является истинным антиподом между подобными OpenCV и т. Д., По сравнению с, скажем, кодом, который разработан в соответствии с хорошей деловой практикой (Code Complete, Clean Code, SOLID и т. Д.)

В целом, исходный код для KISS имеет много преимуществ для бизнеса - « будь проще, глупее». Есть также связанный ЯГНИ - «Вам это не нужно».

К сожалению, для программного обеспечения с интенсивными вычислениями в научных областях исходный код редко бывает простым или скудным .

Традиционно OpenCV страдал от недостатка обобщений (много дублирования кода для поддержки различных опций), тогда как VTK страдал от чрезмерных обобщений (шаблонов).

В первые дни некоторые части OpenCV изначально разрабатывались на C. Позже OpenCV принял API C ++, с которым мы знакомы сегодня. Некоторые алгоритмы переписаны для использования преимуществ интерфейсов C ++ (абстрактные базовые классы) и шаблонов C ++. Другие алгоритмы были просто обертками для оригинального C-кода. Остатки этого кода можно найти в модуле imgproc.

OpenCV содержит множество SIMD-программ (векторизация). На сегодняшний день SIMD-программирование на C ++ все еще требует использования встроенных функций (intel.com) , (arm.com) .

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

Человек, который не занимается программированием SIMD, может легко прийти к выводу, что SIMD можно элегантно инкапсулировать и что программирование SIMD низкого уровня больше не требуется. Это на самом деле довольно далеко от истины. Я бы бросил вызов любому, кто попытается реализовать полезный алгоритм в SIMD (не фракталах) и увидеть трудность использования в этих предлагаемых инкапсуляциях.

Ниже приводится длинный список идей, когда я пытаюсь проанализировать, почему вычислительное программное обеспечение не может быть KISS или YAGNI. Однако все эти идеи являются чрезмерными обобщениями, и они, кажется, не подтверждают вышеприведенное наблюдение.

Основными способствующими факторами являются:

• Производительность программного обеспечения
• Необходимость поддержки многих вариантов алгоритмов и компромиссов
• Необходимость поддержки множества различных аппаратных платформ и компиляторов.
  • Это связано с проблемой производительности программного обеспечения - производительность должна быть хорошей для многих аппаратных платформ и компиляторов.
• Отсутствие постоянной модернизации кодовой базы из-за нехватки ресурсов, нехватки знающих людей, которые могут улучшить качество кода без ущерба для других факторов и т. Д.
  • Проекты с открытым исходным кодом страдают от трагедии общего .
  • Проекты с открытым исходным кодом, получающие гранты, должны были соответствовать конкретным результатам - качество кода, как правило, не является его частью.
  • В частности, даже не хватает знающих людей, которые могли бы сделать или предложить постепенное улучшение качества кода . Это проблема «отсутствующих глазных яблок» - многие люди извлекают пользу из кода, но мало кто нашел время, чтобы прочитать код.
• Исторический недостаток качества кода таких как проверка кода, модульные тесты, статический анализ и т. Д.
  • Для крупномасштабного проекта эти параметры качества кода - это не просто этапы, выполняемые вручную - для каждого требуется инфраструктура (веб-система, система модульного тестирования, система автоматизации сборки и т. Д.).

Некоторые из перечисленных факторов являются антиподами при разработке программного обеспечения для бизнеса:

• Как правило, деловое программное обеспечение не должно иметь дело с такими же высокими объемами передачи данных, как в вычислительном программном обеспечении.
• Программное обеспечение для бизнеса может быть привязано к одной операционной системе и компьютерной архитектуре.
• Программное обеспечение для бизнеса может быть скромным в решении, какие функции включать. На самом деле, разработка программного обеспечения для бизнеса побуждает менеджеров отказываться от новых функций, если нет хорошего бизнес-кейса.
  • Пользователи внутреннего делового программного обеспечения могут быть обучены тому, как действовать по-другому, избегая необходимости вносить изменения в код.
  • Если коммерческое программное обеспечение для бизнеса теряет одного клиента из-за одной отсутствующей функции, но приобретает двух новых клиентов из-за улучшенной простоты и простоты использования (см. «Парадокс выбора» ), в целом это чистая выгода - это хорошо Дело в том, что эта особенность отсутствует.
• Программное обеспечение для бизнеса поддерживается непрерывным потоком доходов, так что оно может позволить себе потратить часть его на непрерывную модернизацию кодовой базы.

Является ли научный код достаточно другой областью, чтобы игнорировать общие стандарты кодирования?

Это зависит от того, что вы называете «общими стандартами кодирования». Я бы не назвал крайности Agile «общими». В частности, считать, что функция, длина которой составляет восемь строк, слишком длинная или имеет более двух уровней отступа, чтобы быть слишком сложной, является нелепым стандартом в области численного / научного программирования.

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

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

Давайте рассмотрим пример кода, который я считаю «чистым кодом» с точки зрения компьютерного зрения и понимания изображений:

https://github.com/opencv/opencv/blob/05b15943d6a42c99e5f921b7dbaa8323f3c042c6/modules/photo/src/seamless_cloning_impl.cpp

Для тех, кто знаком с MATLAB и научными вычислениями, код на C ++ почти такой же лаконичный, как и самый чистый код MATLAB.

Теперь мы должны спросить, почему не вся база кода библиотеки (в данном примере OpenCV) написана в том же стандарте, что и этот пример кода?

Мы должны разделить кодовую базу большой научной библиотеки на уровни абстракции .

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

https://github.com/opencv/opencv/blob/master/modules/core/src/hal_replacement.hpp

На среднем уровне мы находим «самый грязный» код, в котором тратится, возможно, 80% - 90% времени процессора. (Точно так же, возможно, 80% - 90% усилий на разработку были потрачены на среднем уровне, если мы будем считать отдельно усилия по разработке программного обеспечения от научных исследований.)

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

Чтобы убедиться, что эти уровни не смешиваются, необходимо сильное превосходство в организации исходного кода. Это выходит за рамки стандартов кодирования , больше касается управления открытым исходным кодом .

Например, иногда принимается решение разделить один проект с открытым исходным кодом на два. Вы не можете сделать это с помощью коммитов кода.