Хорошие стратегии разработки одноразового кода?

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

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

Вот практический совет по хранению фрагментов. Вместо полноценных комментариев добавьте несколько ключевых слов:

• «оболочка изоморфизма графа»
• «полимер, имитирующий отжиг»
• «строка соответствия Фейнмана»
• «равновесие»

, а затем поместите код где-нибудь с возможностью поиска в Google, например учетная запись GMail.

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

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

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

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

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

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

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

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

Код, как если бы вы планировали запустить это в производство, даже когда вы просто возитесь. Код для:

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

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

Нет, Нет, Нет, Нет, Нет!

Не пишите одноразовый код даже в исследовательской среде. Пожалуйста!

На данный момент я возился с таким "одноразовым кодом", а именно с проектом BLAST. Дело в том, что он начинался как игровая площадка, но затем оказался в некоторой степени успешным. Теперь это изящный инструмент, в котором реализовано множество концепций, но код практически не поддерживается. Но не в этом суть.

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

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

( EDIT : взято из комментариев ниже) Чтобы помочь будущим разработчикам вашей кодовой базы, вам не нужно много. Сначала прокомментируйте, что делает каждая функция . Во-вторых, убедитесь, что каждое неочевидное исправление сложной ошибки помещается в отдельный коммит в системе контроля версий (конечно, с соответствующим комментарием). Этого вполне достаточно. И если вы даже сделаете вещи модульными (даже если они не готовы к прямому повторному использованию - это в три раза дороже, по словам Брукса), вас будут обожать инженеры, которые реализуют ваши исследования.

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

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

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

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

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

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

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

Некоторые стратегии:

1. Хорошо Комментарии. Трудно повторно использовать то, что вы не можете найти или понять позже.
2. Сохраняйте каждый запрос в папку, для которой создана резервная копия или находится под контролем источника.
3. Имейте общую библиотеку полезных функций, которые вы "продвигаете" что-то один раз он был использован повторно.

[Ответ на собственный вопрос] Есть несколько других аспектов проблемы, которые не были затронуты и которые я нашел бы полезными при повторном рассмотрении. Некоторые из них могут быть «самоочевидными», но помните, что этот код был до SVN и IDE.

• Возможность обнаружения . На самом деле было трудно найти код. Я считаю, что это в моем проекте SourceForge, но за 7 лет существует так много версий и веток, что я не могу его найти. Так что мне нужна была система, которая искала код, и я не думаю, что до появления IDE они были.
• Что она делает? . Текущая проверка содержит около 13 классов (все в одном пакете, поскольку в то время было непросто провести рефакторинг). Некоторые из них прозрачны ( DynamicAligner ), но другие непрозрачны ( MainBox , названный так, потому что он расширил Swing Box). Всего четыре программы main () , и на самом деле в дистрибутиве около трех подпроектов. Поэтому очень важно иметь внешний манифест о том, что это за компоненты на самом деле.
• инструкции по его запуску . При запуске программы main () предложит краткое использование командной строки (например, DynamicAligner file1 file2 ), но не скажет, как на самом деле выглядит содержимое файлов. Я, конечно, знал это тогда, но не сейчас. Таким образом, в дочерних каталогах должны быть связанные примерные файлы. Это более ценно, чем попытки задокументировать форматы файлов.
• это все еще работает? . Должна быть возможность запускать каждый пример, не задумываясь. Первый вопрос будет заключаться в том, актуальны и доступны ли все еще связанные библиотеки, среды выполнения и т. Д. Один бывший коллега написал систему, которая работает только с определенной версией Python. Единственный ответ - переписать. Поэтому, конечно, мы должны избегать любой блокировки, где это возможно, и я обучил себя (хотя и не обязательно коллег) этому.

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

Затем возникает вопрос, как должны быть организованы проекты. Они могут' По умолчанию он находится на Sourceforge, поскольку код (а) тривиален и (б) по умолчанию не открыт. Нужен сервер, на котором могут быть как коммунальные проекты, так и частные. Я бы посчитал, что усилия по настройке и запуску составляют около 0,1 FTE - это 20 дней в году со всех сторон (установка, обучение, обслуживание) - если есть более простые варианты, я хотел бы знать, так как это большой расходы в некоторых случаях - трачу ли я время на настройку сервера или пишу статьи?

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

1. Шаблон необходимых компонентов (манифест, README, журнал коммитов, примеры, необходимые библиотеки и т. Д. Не все проекты могут работать под maven - например, FORTRAN).
2. Средство поиска мнемонических строк в большом количестве (по крайней мере в сотнях) небольших проектов (мне понравилась идея сбросить код в Googledocs, и это может быть плодотворным путем, но требует дополнительных усилий по обслуживанию).
3. Четкие соглашения об именах. Это более ценно, чем комментарии. Теперь у меня регулярно есть имена типа iterateOverAllXAndDoY. Я пытаюсь использовать createX (), а не getX (), когда процедура фактически создает информацию. У меня есть дурная привычка вызывать процедуры process (), а не convertAllBToY ().

Я знаю, но не использовал GIT, Mercurial и GoogleCode. Я не знаю, сколько усилий требуется для их создания и на сколько из моих проблем они отвечают. Я был бы рад, если бы существовал плагин IDE, который помог бы создать лучший код (например, «плохой выбор имени метода»).

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

Если это одноразовый код, выбросьте его !

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

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

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

Если я сделаю этот код многоразовым, смогу ли я найти его снова, когда он мне понадобится? (Кто-нибудь когда-либо знал с абсолютной уверенностью, что где-то в вашем репозитории кода есть именно тот фрагмент, который вам нужен, но не имел понятия, как он был вызван, ни где искать, ни что искать с помощью grep?)

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

1) Задокументируйте код как черный ящик. Входы, выходы, операции. Тщательно храните этот документ.

2) Напишите инструкции о том, как собрать / интерпретировать / установить код, на случай, если вам когда-нибудь придется его переносить. Тщательно храните эти инструкции.

3) Только если стоит усилий - улучшите качество исходного кода, чтобы его можно было сопровождать в будущем.

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

1. Чтение тестового кода довольно ясно передает намерение выброса: в конце концов, он выражает свои ожидания на том же языке: код.

2. Это также поможет с четвертой проблемой вашего самообслуживания. ответ: "еще работает?". Что ж, это просто: просто запустите модульные тесты, и они скажут вам, что и где (и если повезет), почему (это) не работает.