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

https://stackoverflow.com/questions/1373980

21-09-2019
|

Вопрос

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

Какие подходы являются экономически эффективными для того, чтобы такие работы можно было откопать и повторно использовать?

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

Решение

Я не согласен со всеми ответами, в которых говорится "пишите комментарии".Это предлагается в качестве универсального объяснения того, что сам код непонятен.

Купите себе копию Код Завершен (Стив Макконнелл, 2-е издание).Если вы в первую очередь освоите методы написания поддерживаемого кода, это не займет у вас больше времени, и вы сможете вернуться к своей работе позже с меньшими трудностями.

Что бы вы предпочли:

Зашифрованный код с комментариями?
В основном ОК-код без?

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

"оболочка изоморфизма графа"
"имитация отжига полимера"
"строка соответствует фейнману"
"равновесие"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С уважением

Отметка

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow