Хорошие стратегии для разработки одноразового кода?
Я часто пишу одноразовый код (в исследовательской среде) - например, чтобы исследовать алгоритм или модель для научной собственности или процесса. Многие из этих "экспериментов" являются одноразовыми, но иногда я нахожу, что мне нужно использовать несколько позже. Например, я только что обнаружил код для сопоставления строк, который я написал 7 лет назад (остановлен из-за других приоритетов), но который сейчас важен для проекта коллег. Посмотрев на это (действительно ли я написал такой непробиваемый код?), Я понял, что мог бы кое-что сделать, чтобы помочь мне, когда я перезапустил "проект" ("эксперимент" - все еще лучшее слово). Предыдущий эксперимент "работал", но я знаю, что в то время у меня не было бы времени на рефакторинг, поскольку мои приоритеты лежали в другом месте.
Какие подходы являются экономически эффективными для обеспечения возможности повторного использования и повторного использования такой работы?
РЕДАКТИРОВАТЬ: я ответил на свой вопрос (ниже), потому что есть проблемы за пределами самого источника.
10 ответов
Я не согласен со всеми ответами, говоря "написать комментарии". Это предлагается как универсальное решение для самого кода, который непонятен.
Получите копию Code Complete (Стив Макконнелл, 2-е издание). Если вы сначала освоите методы написания поддерживаемого кода, это не займет у вас больше времени, и вы сможете вернуться к работе позже с меньшими трудностями.
Что бы вы предпочли:
- Загадочный код с комментариями?
- В основном без кода ОК?
Я настоятельно предпочитаю последнее, так как код ОК легче понять в ситуациях, когда загадочный код не был прокомментирован, а комментарии - это еще одно место, в котором первоначальный разработчик может ошибаться. Код может содержать ошибки, но он никогда не ошибается.
Как только вы освоитесь с Code Complete, я бы порекомендовал The Pragmatic Programmer, поскольку он дает рекомендации по разработке программного обеспечения несколько более высокого уровня.
[Отвечая на собственный вопрос] Есть несколько других аспектов проблемы, которые не были затронуты и которые я бы нашел полезными при повторном рассмотрении. Некоторые из них могут быть "самоочевидными", но помните, что этот код был до SVN и IDE.
- Обнаруживаемость. На самом деле было трудно найти код. Я верю, что это в моем проекте SourceForge, но за 7 лет существует так много версий и веток, что я не могу его найти. Поэтому мне нужна система, которая искала бы код, и пока не появились IDE, я не думаю, что они были.
- Что оно делает?, Текущая проверка содержит около 13 классов (все в одном пакете, так как в то время было нелегко провести рефакторинг). Некоторые понятны (
DynamicAligner) но другие непрозрачны (MainBox, названный потому, что он расширил Swing Box). Есть четыреmain()программ и на самом деле есть около 3 подпроектов в дистрибутиве. Поэтому очень важно иметь внешний манифест относительно того, какими были компоненты на самом деле. - инструкции о том, как его запустить. При запуске программы,
main()предложит краткое использование командной строки (например,DynamicAligner file1 file2) но это не говорит о том, как на самом деле выглядит содержимое файлов. Я знал это в то время, конечно, но не сейчас. Таким образом, должны быть связанные файлы примеров в одноуровневых каталогах. Это более ценно, чем пытаться документировать форматы файлов. - это все еще работает?, Должна быть возможность выполнить каждый пример, не задумываясь. Первый вопрос заключается в том, являются ли связанные библиотеки, среды выполнения и т. Д. По-прежнему актуальными и доступными. Один бывший сотрудник написал систему, которая работает только с определенной версией Python. Единственный ответ - переписать. Так что, конечно, мы должны избегать любой блокировки, где это возможно, и я приучил себя (хотя и не обязательно коллег) к этому.
Так как же мне и коллегам избежать проблем в будущем? Я думаю, что первый шаг заключается в том, что при создании кода должна быть дисциплина создания "проекта" (пусть и небольшого), и что эти проекты должны находиться под контролем версий. Это может показаться очевидным для некоторых из вас, но в некоторых средах (академических, внутренних) создание системы управления проектами сопряжено со значительными издержками. Я подозреваю, что большая часть академического кода не находится под контролем версий.
Тогда возникает вопрос о том, как проекты должны быть организованы. Они не могут быть в Sourceforge по умолчанию, так как код (а) тривиален и (б) не открыт по умолчанию. Нам нужен сервер, на котором могут быть как коммунальные, так и частные проекты. Я бы посчитал, что усилия по его настройке и запуску составляют около 0,1 FTE - это 20 дней в году от всех сторон (установка, обучение, техническое обслуживание) - если есть более простые варианты, которые я хотел бы знать, так как это большой в некоторых случаях расходы - трачу ли я время на настройку сервера или пишу бумаги?
Проект должен стремиться поощрять хорошую дисциплину. Это действительно то, что я надеялся получить от этого вопроса. Это может включать в себя:
- Шаблон необходимых компонентов (манифест, README, журнал коммитов, примеры, необходимые библиотеки и т. Д. Не все проекты могут работать под Maven - например, FORTRAN).
- Средство поиска мнемонических строк в большом количестве (по крайней мере, сотнях) небольших проектов (мне понравилась идея выгрузить код в Googledocs, и это может быть плодотворным способом, но это дополнительное усилие по обслуживанию).
- Четкие соглашения об именах. Это более ценно, чем комментарии. У меня теперь регулярно появляются имена типа iterateOverAllXAndDoY. Я пытаюсь использовать createX(), а не getX(), когда процедура фактически создает информацию. У меня есть плохая привычка вызывать процедуры process(), а не convertAllBToY().
Я знаю, но не использовал GIT, Mercurial и GoogleCode. Я не знаю, сколько усилий они предпринимают, и на сколько моих проблем они отвечают. Я был бы рад, если бы был плагин IDE, который помог создать лучший код (например, "неправильный выбор имени метода").
И какие бы подходы они ни использовали, они приходят естественным образом к людям, у которых нет естественной дисциплины в коде, и они того стоят.
Как показывают отличные ответы в вашем другом посте, и из моего собственного опыта, существует труднопреодолимый разрыв между программным обеспечением, используемым для исследований, и программным обеспечением, которое было разработано. На мой взгляд, Code Complete может помочь немного, но не сильно. С экономической точки зрения, стоит ли проводить рефакторинг всего для повторного использования по сравнению со случайной наградой за более позднее использование чего-либо? Ваш баланс может отличаться.
Вот практический совет для хранения фрагментов. Вместо полноценных комментариев добавьте несколько ключевых слов:
- "Оболочка изоморфизма графа"
- "полимерный моделируемый отжиг"
- "Струнное совпадение Фейнмана"
- "Равновесие"
и затем поместите код где-нибудь с возможностью поиска в Google, например, в аккаунт GMail.
Изменить: я мог бы добавить, что бесплатные Сайты Google - это действительно доступные для поиска вики, которые являются хорошим местом для размещения кода, либо в виде вложений, либо вставленных в него.
Кроме того, я должен сказать, что я фанат Code Complete и в течение нескольких лет давал копии студентам, пишущим программы для научных исследований. Это хорошее начало, но без серебряной пули. Сейчас я пишу статью об использовании сред с открытым исходным кодом для решения проблем управления научными данными, и один из выводов заключается в том, что некоторые знания в области разработки программного обеспечения необходимы для долгосрочных систем. Многие научные проекты, вероятно, должны изначально предусматривать это.
Я бы повторил то, что сказали другие, комментируя "почему" того, почему был написан код и его предполагаемое использование, но я бы также добавил это:
Кодируйте, как если бы вы планировали запустить это в производство, даже когда вы просто бездельничаете. Код для:
- Ясность и читаемость
- Следуйте правилам кодирования того времени. (соглашения об именах и т. д.). Даже если такие соглашения со временем меняются, если вы будете придерживаться стандартов, у вас будет больше шансов понять это позже.
- Безопасность (если применимо)
- производительность (если применимо)
В частности, я бы подчеркнул первый момент, но другие также важны. Я обнаружил, что если я буду использовать "тестовый код" позже, я буду использовать его, если он работает, а не рефакторинг.
Я думаю, что самая важная вещь (если вы не делаете рефакторинг, это не произойдет) - это комментировать и документировать свой мыслительный процесс в то время. Это поможет сделать код менее непроницаемым и поможет вам найти хорошие моменты при необходимости.
Нет-нет-нет-нет-нет!
Не пишите одноразовый код даже в исследовательской среде. Пожалуйста!
В настоящее время я балуюсь таким "одноразовым кодом", а именно проектом BLAST. Дело в том, что он начинался как игровая площадка, но потом оказался несколько успешным. Теперь это аккуратный инструмент с множеством реализованных концепций, но код практически не поддерживается. Но это не главное.
Суть в том, что вы проводите исследования для инженеров, чтобы потом извлечь выгоду из своих выводов. Проделав хорошую научную работу над общей концепцией и написав инструмент, который доказал бы ее успешность, вы можете легко забыть, что вы делаете это не только для публикации, но и для получения докторской степени. Вы делаете это на благо человечества. Ваш код может содержать кучу "особых случаев", которые трудно было отладить, набор причуд и взломов, которые не вписываются ни в одну статью конференции. Особенно важно документировать и комментировать такие вещи в своем коде.
Если бы разработчик решил внедрить ваши концепции в коммерческий продукт, он мог бы изучить причуды и хаки из вашего кода, и в реализации было бы на десять ошибок меньше, чем могло бы быть. Все говорят: "Ничего себе, его исследование A действительно полезно!" Но если вы напишите "одноразовый", они скажут, что "его концепция хорошо выглядит на бумаге, но X попытался реализовать ее и утонул в куче ошибок".
(РЕДАКТИРОВАТЬ: взято из комментариев ниже) Чтобы помочь будущим разработчикам вашей кодовой базы, вам не нужно много. Сначала прокомментируйте, что делает каждая функция. Во-вторых, убедитесь, что каждое неочевидное исправление хитрой ошибки помещено в отдельный коммит в системе контроля версий (конечно, с соответствующим комментарием). Этого вполне достаточно. И если вы даже сделаете вещи модульными (даже если они не готовы к прямому повторному использованию - это в три раза дороже, по мнению Брукса), вас обожают инженеры, которые проводят ваши исследования.
Я думаю, что мир был бы лучше, если бы исследователи выбросили свое высокомерие и перестали надменным думать, что это не те грязные программисты, которые выполняют черную работу по написанию хорошего кода. Написание хорошего кода - не просто работа для этих глупых программистов. Это действительно ценная вещь, к которой должен стремиться каждый. Без этого ваше экспериментальное поле, ваш код, ваше детище просто умрут.
Я, наверное, упустил смысл всей этой дискуссии, я часто это делаю, но здесь, приглашение для кирпичных бит и понижения голосов...
Если это одноразовый код, выбросьте его!
Если вы не хотите выбрасывать его, следуйте советам выше. Для меня, и я пишу довольно много одноразового кода, вопрос о том, будет ли он выброшен или переведен в состояние многократного использования и сохранено против дождливого дня, сводится к экономике.
Могу ли я предвидеть обстоятельства, при которых этот код снова будет полезен? Один раз на голубой луне, два раза в год, каждый месяц?
Смогу ли я переписать этот код за меньшее время, чем требуется для его повторного использования? Если ответом на этот вопрос является "Нет", то сколько раз мне придется использовать его повторно, чтобы повысить его ценность, улучшая его сейчас? (Вернуться к предыдущему вопросу.)
Если я сделаю этот код многоразовым, смогу ли я найти его снова, когда в следующий раз захочу? (У любого когда-либо был опыт знания, с абсолютной уверенностью, что где-то в вашем хранилище кода есть только тот фрагмент, который вы хотите, но не имея ни малейшего понятия, как он называется, ни где искать, ни к чему стремиться?)
Наконец, трехэтапный подход к быстрому повторному написанию кода. Остановитесь после любого из этих шагов, которые вам нравятся:
1) Документируйте код как черный ящик. Входы, выходы, операции. Храните этот документ тщательно.
2) Напишите инструкции о том, как создать / интерпретировать / установить код, на случай, если вам когда-нибудь придется его портировать. Храните эти инструкции тщательно.
3) Только если стоит усилий - улучшите качество исходного кода, чтобы в будущем его можно было поддерживать. Убедитесь, что источники находятся в системе контроля версий и доступны для поиска.
С уважением
отметка
Комментарии - опишите, что вы думали, и почему вы решили реализовать что-то определенным образом, включая альтернативы, которые вы рассматривали. Вероятно, существуют всевозможные причудливые решения, но простое комментирование кода во время написания кода кажется лучшим.
Вы также можете позаимствовать идею модульных тестов у разработчиков TDD (разработка через тестирование). Вы должны убедиться, что одноразовый код на самом деле работает нормально, так почему бы не выразить проверку как небольшой модульный тест? Это будет иметь два преимущества:
Чтение тестового кода довольно четко сообщает о намерении отбросить: в конце концов, оно выражает свои ожидания на одном языке: код.
Это также помогло бы решить четвертую проблему вашего самоответа: "Это все еще работает?". Ну, это легко: просто запустите модульные тесты, и они скажут вам, что и где (и с небольшим количеством удачи), почему (это) не работает.
Некоторые стратегии:
- Хорошие комментарии. Трудно повторно использовать то, что вы не можете найти или понять позже.
- Сохраняйте каждый запрос в папке, для которой выполняется резервное копирование или которая находится под контролем источника.
- Имейте общую библиотеку полезных функций, чтобы вы "продвигали" что-то, после того как это будет использовано повторно.