Обзор кода в академических кругах

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

Похоже, что обзоры кода среди ученых здесь были бы полезны для (а) методов обучения других людей и (б) выявления недостатков в вашем коде. (Иногда мне кажется страшно, что есть публикации, которые публикуются там, где теория создается в коде, который никто не знает, но автор когда-либо смотрит!) Должны ли академики иметь обязательные обзоры кода со своими сверстниками? (Кто-нибудь видел такую вещь раньше?)

Что еще более важно, сколько времени требуется для эффективного обзора кода в этом контексте? Кажется, трудно оправдать дополнительное время, когда этот конкретный ресурс всегда очень скуден.

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

Вы можете написать багги-код, который дает результаты, которые выглядят правильно, и никогда не знаю там там ошибки!

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

Ответ 1

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

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

Если рецензент не знаком с базой кода, а количество кода очень мало (пару тысяч строк?). Обзор кода будет либо очень трудоемким, либо не очень строгим.

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

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

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

Ответ 2

Мой совет состоит в том, чтобы иметь 1 или 2 сеанса и посмотреть, как это делают команды/пэры. Ответ "эффективен" в том, что он в основном зависит от людей.

Я был во многих отзывах, где рецензии людей на самом деле не нашли времени, чтобы сесть и проследить код. Иногда люди просто замаскивают источник и записывают орфографические ошибки и "требуют комментариев здесь" типа "дефектов". Несмотря на то, что эта информация хороша, она действительно не помогает причинам a, b, указанным выше.

Обратите внимание, что я также был в обзорах, которые были очень продуктивными.

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

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

Ответ 3

Продолжительность проверки кода зависит от:

Длина кода
Сложность кода
Навык рецензента

поэтому трудно точно определить, сколько времени это займет. Я знаю некоторых людей, где я работаю, которые могут просматривать ~ 400loc/h, но несколько проектов поставили ограничение на максимальную скорость loc/h на 200, поскольку они считают, что ускорение снижает качество проверки кода.

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

Ответ 4

Разве исследовательские статьи не проверяются перед публикацией? И само исследование, разве есть какая-то наставница? (Не знаю правильного термина, я не в академических кругах...)

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

Чтобы уточнить, я предположил, что экспертная оценка (до публикации?) проверит все допущения, подтвердит выводы, проверит следы данных и т.д.
Часть проверки правильности трассировки данных (и, следовательно, обоснованности выводов из этих данных) должна изучать программу, которая обрабатывает или генерирует эти данные. Поэтому анализ кода является своего рода необходимым...

Ответ 5

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

Когда я учился в школе, мы не делали обзоров кода (кроме случаев, когда мы были в тупик!, а затем только для поиска ошибки), но, конечно, было бы хорошо взглянуть на более код.

При выполнении обзоров кода моя команда обычно предоставляла код рецензентам на пару дней раньше времени (в зависимости от объема кода) и немного разбивала на куски, которые были логически сгруппированы вместе, если бы LOT кода), и пусть рецензенты проверяют это. Затем мы встретимся около часа или около того и проведем выводы. Есть много способов сделать это, но это сработало достаточно хорошо для нас.

Я думаю, это немного удивило меня, что уже не было такого, что было на месте.

Ответ 6

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

Кодовые обзоры обычно выполняются как часть команды с общей повесткой дня. Мы получаем оплату, если приложение продает. Им всем интересно, что они понимают весь код и что код как можно лучше.

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

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

В обзорах кодов нет (часто) исправлять ошибки или действительно проверять код. Они просто разделяют понимание этого и обеспечивают обратную связь.

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

В какой-то степени я считаю, что ad-hoc-код может быть правильным инструментом для работы, если эта работа не является профессиональной разработкой программного обеспечения. Там, где я работал с Matlab (во время моей математической диплом), что я не буду мечтать сейчас, но код, который я пишу сейчас, разделяется моей командой и регулярно пересматривается, код, который я написал, с тех пор не просматривался, так как я закончил.

Ответ 7

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

Ответ 8

Мой фон - физический академик в не-вычислительно интенсивном поле.

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

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

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

Ответ 9

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

Ответ 10

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

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