Должен ли я делиться своим ужасным программным обеспечением?

Да, ты должен.

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

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

Потенциальные плюсы: возможные новые соавторы, исправления, расширения, публикации.

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

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

Пройдитесь по нему и прокомментируйте его на любом уровне, на каком сможете. Оставьте в «неудачных попытках» и прокомментируйте их как таковые. Скажите, почему они потерпели неудачу, и что вы пытались. Это ОЧЕНЬ полезная информация для тех, кто придет после вас.

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

Слишком много людей сдерживают что-то, потому что это не идеально!

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

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

¿Вы думаете, что ваш код грязный? Я видел (и пытался работать) код, который вызывал у меня кошмары:

• Пять уровней if Trueвложенности, разбросанных в случайных местах по коду.
• Создайте массив нулей, преобразуйте его в градусы, возьмите косинус и вернитесь в радианы. Затем выбросьте результат.
• В программном обеспечении, находящемся в стадии интенсивной разработки, список «поддерживаемых архитектур» настолько древний (и они сами говорят), что в наши дни было бы трудно достать один из этих компьютеров.
• Функции, сломанные или измененные несколько версий назад, по-прежнему рекомендуются в документации.
• Код, который переходит от использования стандартного формата ввода к некоторому собственному формату. Как его сгенерировать? На самом деле никто не знает, и разработчики машут рукой в ​​ответ.
• Релизы, которые даже не компилируются. (Вы его даже тестировали?)
• Меню графического интерфейса, к которым вы должны получить доступ в определенном порядке. В противном случае вы получите ошибку сегментации и вам придется начинать сначала.
• Жестко запрограммированные пути разбросаны по коду./home/someguy/absurd_project/working/

И, мой личный фаворит, определенная программа из тысяч строк кода, использовала комментарии только для исключения случайных фрагментов кода, за исключением одного:

Здесь мы пробиваем карты.

Тем не менее, понятия не имел, что он делал.

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

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

На мой взгляд, важные вещи, о которых вы должны заботиться, по порядку:

1. Форматы ввода и вывода. Упростите использование вашей программы в качестве черного ящика.
2. Прокомментировано.
3. Разборчивость. Использование идиоматического кода, хорошие имена переменных...
4. Состав.

Итак, выпускайте свое программное обеспечение всякий раз, когда у вас есть 1 (2 и часть 3 должны появиться, когда вы их пишете).

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

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

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

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

Теперь, если вы хотите произвести впечатление еще больше, это поможет ...

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

... если ваш код содержит файл readme, который связывает утверждения из вашей статьи с исходным кодом. Таким образом, когда я прочитаю статью и захочу узнать больше, я могу использовать файл readme, чтобы перейти к соответствующему месту в коде. Типичными фразами из такого ридми могут быть: «Алгоритм из раздела 3.2 статьи находится в файле algorithm/newversion/related/secondtry/foo.c» или «Повторить прогон с небольшим набором данных, описанным в разделе 2 статьи». бумага, запустить "сделать; сделать второй_шаг; наборы данных foo_bar_2/christmas.dataset. Этот запуск занимает около 2 дней на моем ноутбуке».

Вас также может заинтересовать CRAPL Мэтью Майта (лицензия на общественные исследования и академическое программирование), доступная по адресу http://matt.might.net/articles/crapl/ . Он содержит этот термин: «Вы соглашаетесь освободить Автора от стыда, смущения или насмешек за любые взломы, кладжи или прыжки веры, обнаруженные в Программе». Мне не ясно, имеет ли эта «лицензия» какую-либо юридическую силу, но цель ясна: выпустите свой уродливый код и не думайте плохо о уродливом коде других.

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

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

def main():
    get_foobar(x, y)


def get_foobar():
    return x**y


def get_foobar_legacy_1():
    """
    This attempt did not work for values > 100
    """
    return x + y


def get_foobar_legacy_2():
    """
    This attempt did not work on Wednesdays in September
    """
    return x - y

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

Конечно, вы должны поделиться исходным кодом.

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

Я думаю, вы должны поделиться этим. Прежде всего, вы должны сделать некоторые основные очистки. (например: нет более раннего кода, который больше не используется; нет кода в комментарии; допустимый способ комментирования и т. д.). ваши намерения. (например: todo: это должно быть изменено на перечисление) Я также думаю, что вы должны поделиться наиболее важной частью ваших алгоритмов. Когда я делюсь кодом, я никогда не делюсь неважными частями. Каждый может справиться с чтением/записью файлов, взаимодействием между потоками, графическим интерфейсом и так далее. Но не делитесь нечитаемым кодом. Это не имело бы смысла. Так что я думаю, что срединный путь является лучшим во многих случаях. :-)

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

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

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

Если их усилия по рефакторингу провалятся, вы отстанете не дальше, чем были. Если это так, отказ от ответственности — замечательная вещь. Просто поделитесь кодом, но добавьте оговорку: «Это некрасиво. Когда я писал это, я пытался провести свое исследование — я не думал, что оно когда-либо выйдет за пределы моей компьютерной лаборатории. посмотреть, если вы действительно хотите».

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

• Вам разрешено публиковать код?
  • Можете ли вы гарантировать, что использовали только те фрагменты кода, которые вам разрешено распространять? Или вы, возможно, использовали код из закрытых источников, который вы можете использовать для своего собственного внутреннего программного обеспечения, но который вам не разрешено публиковать? Можете ли вы гарантировать, что весь код, который вы использовали, может быть опубликован в одном полном пакете? Совместимость лицензий — нетривиальный вопрос.
  • Можете ли вы хотя бы достоверно узнать? Вы отдавали на аутсорсинг какие-либо части своей работы по кодированию или интегрировали неопубликованный код из других источников? Например, курировали ли вы каких-либо студентов во время их выпускных работ или нанимали ли каких-либо студенческих помощников-исследователей, чья работа была основана на ваших исследованиях, и поэтому их код был добавлен в вашу кодовую базу? Вносили ли какие-либо коллеги код в вашу кодовую базу? Они получили часть своего кода от студентов? Все ли эти вовлеченные люди должным образом обращали внимание на вопросы лицензирования (если у них вообще были знания, чтобы вынести обоснованное суждение по этим вопросам лицензирования)? Можно ли еще определить, откуда взялись те или иные части кода? Люди, которые внесли свой вклад в каждую часть, все еще знают? Являются ли они для вас все еще «в пределах досягаемости»?
  • Был ли код разработан в рабочее время на средства третьих лиц? Если да, разрешают ли условия контракта о финансировании публиковать код или включают ли они какие-либо требования о том, что программное обеспечение, созданное в рамках финансируемого проекта, должно предоставляться исключительно партнерам по проекту?
• Достаточно ли у вас ресурсов (времени и прочего), чтобы потратить усилия на очистку кода и его комментариев таким образом, чтобы он по-прежнему имел смысл, но не предоставлял никакой информации, которая не должна стать общедоступной?
  • Есть ли у вас какие-либо комментарии, раскрывающие, кто работал над кодом? Было ли людям, которые предоставили код, официально разрешено работать над соответствующим исследованием в соответствии с их финансированием? (Разработчики программного обеспечения хорошо осведомлены о том, что командная работа и повторное использование компонентов являются ключевыми аспектами разработки программного обеспечения. К сожалению, финансирующие агентства обычно очень не осведомлены об этом и предполагают, что если разработчик A финансируется из проекта X, а разработчик B финансируется из проекта Y, A работает исключительно над X, а B работает исключительно над Y, и раскрытие информации о том, что A потратил всего полчаса на то, что закончилось проектом Y, может привести к серьезным последствиям, таким как возврат части финансирования.)
  • Выдает ли что-либо в опубликованных данных какую-либо информацию об особенностях выполнения работы, которая не должна стать достоянием гласности?Это особенно важно, если вся история коммитов в системе контроля версий станет общедоступной (или, практически, означает, что история коммитов никогда не должна публиковаться), но может также сыграть роль в других ситуациях. Например: выполнялась ли какая-либо работа над кодом вне официально установленного рабочего времени (например, в выходные дни)? Выдает ли рабочее время, что вы работали больше установленного в вашей стране рабочего времени в день? Выдает ли рабочее время, что вы не соблюдали установленные законом перерывы? Выдает ли рабочее время, что люди, назначенные на другие проекты, внесли свой вклад? Предоставляет ли рабочее время какую-либо причину, чтобы не доверять каким-либо заявлениям, которые вы сделали в отношении своего рабочего времени (например, в отчетах об успешном выполнении проекта, требующих подробного распределения рабочего времени по заранее определенным рабочим пакетам с определенными максимальными отводами)? Выдает ли что-нибудь, что вы работали в ситуациях, когда вам не следовало работать (например, во время совещания по проекту)? Выдает ли что-нибудь, что вы работали в местах, где вам не следовало работать (например, из дома, когда ваш контракт не позволяет вам работать на дому, например, из-за осложнений, связанных со страховкой)?
  • Есть ли в коде какая-либо секретная информация , такая как пароли, имена учетных записей пользователей или URL-адреса, которые не должны быть общеизвестны (поскольку серверы не предназначены для обслуживания большего количества пользователей, помимо небольшого числа избранных людей, которым была предоставлена URL для тестовой настройки лично)?
• Может ли код использоваться кем-либо еще?
  • Будет ли работать код или он потребует значительных усилий по настройке? Можете ли вы потратить усилия, необходимые для объяснения того, какая конфигурация необходима?
  • Можно ли компилировать код? Использовали ли вы какие-либо неофициальные модифицированные или специально созданные компиляторы, которые не являются общедоступными? Если да, добавляет ли этот код что-либо сверх того, что уже может быть представлено в ваших статьях в качестве алгоритма псевдокода?
  • Требует ли код каких-либо внешних ресурсов? Будет ли код полезен только в том случае, если он может получить доступ к серверам, библиотекам или наборам данных, которые вы не можете опубликовать вместе с кодом по той или иной причине? Можно ли предоставить хотя бы описание этих ресурсов, или на их интерфейсы распространяется какое-то соглашение о неразглашении?
  • Вносит ли код какие-либо необратимые изменения в системы, на которых он работает? Например, изменяет ли он автоматически какую-либо конфигурацию системы (например, перезаписывает путь системного поиска)? Осуществляет ли он какой-либо низкоуровневый доступ к аппаратным компонентам, который в определенных сочетаниях (которых вы избегаете в своих тестовых установках) может привести к необратимому повреждению каких-либо компонентов? Можете ли вы надежно предупредить пользователей кода о таких возможных нежелательных побочных эффектах?

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

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

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

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

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

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

Делитесь, если хотите, не делитесь, если не хотите. Я знаю, что это звучит язвительно, но я думаю, что в наши дни слишком много давления, чтобы «делится всем», и люди попытаются сделать вас виновным в том, что вы не делитесь, но на самом деле вы не обязаны чем-либо делиться.

Вы обязательно должны поделиться своим кодом.

Для сортировки создайте области из одних и тех же частей кода, например, сделайте область неудачной попытки, и объясните, почему она не удалась. Кроме того, если вы разрабатываете в Visual Studio, установите расширение «CodeMaid» из Extension Manager и полностью очистите свое решение. Он удалит пробелы, а также удалит неиспользуемые ссылки, благодаря чему большинство вещей будет выглядеть лучше.

Если вы разрабатываете на C#, поделитесь со мной своим кодом. Я также могу помочь вам с сортировкой :)

Поместите заявление об отказе от ответственности, что код предоставляется «как есть», без обещаний поддержки и т. д. А затем поделитесь кодом.

Практический пример: Превращение облака изолированных точек в водонепроницаемую поверхность — чрезвычайно важная практическая задача, используемая везде, от робототехники до компьютерного зрения и обработки данных с 3D-сенсоров, таких как Microsoft Kinect.

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

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

И не беспокойтесь — один фрагмент исследовательского кода, над которым я работал, был разработан пятью постдоками с нейтральными способностями к программированию для серии проектов в течение примерно 8 лет.

Список глобальных переменных (только имена) занял примерно 4 страницы.

Примерно треть из них использовалась для установки поведения по умолчанию для изменения функций, которые функционировали в данный момент. Еще 20% были параллельными структурами данных — это означает, что они хранили примерно одни и те же данные — и, следовательно, функции в коде извлекались из структур данных более или менее случайным образом. Да. Иногда они были не синхронизированы. И иногда нужно было рассинхронизироваться.

Было примерно 50 недокументированных версий, хранившихся в случайных частях сервера группы, каждая из которых служила по крайней мере одной конкретной цели, и только один администратор держал эти конкретные цели в своей голове. Чаще всего люди использовали «неправильную» версию для определенной цели.

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

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

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

Было где-то между 0 и 1 способами работы с программным обеспечением и получения правильных результатов в любой момент...

И да, были гото.

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

Приблизительно 90% любой заданной функции совершенно достоверно не имели отношения к результату или к отладке результата — скорее, они состояли из краткосрочных проектов, вставленных, а затем никогда не удалявшихся. Серьезно - я написал полнофункциональную версию, которая действительно работала и была размером 1/10 от размера ... Значительные доли были скопированы вставленными функциями, многие из которых отличались друг от друга.

И нет Вирджинии, нет документации. Или описательные имена переменных.

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

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

Серьезно, ваш код не так уж и плох.

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