Код Повторное использование: стоит ли это?

Ответ 1

Мое общее правило:

• Если вы повторите его один раз, скопируйте его.
• Если вы повторите его дважды, рефакторируйте его.

Ответ 2

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

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

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

Ответ 3

leppie писал (а):

Мое общее правило:

• Если вы повторите его один раз, скопируйте его.
• Если вы повторите его дважды, рефакторируйте его

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

Rob

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

Для программиста на C квинтэссенцией этого подхода является книга Дейва Хэнсона C Интерфейсы и реализации. Дэйв взял все многоразовые идеи, которые он написал в письменной форме из трех или четырех компиляторов, и поместил их в книгу --- и программное обеспечение бесплатно. Невероятный материал. Теперь, если я напишу код C, и я хочу использовать его во второй раз, я создаю интерфейс в стиле Hanson. Некоторые вещи я сделал с этим термином: 2-мерные массивы, 2-мерные массивы с блокировкой, 2-мерные растровые изображения, считыватели и писатели для файлов pbmplus и т.д. Благодаря этой инфраструктуре было легко написать программу, которую я давно хотел, чтобы удалить черные края из сканирования фотокопий страниц книги.

Итак, я согласен с тем, кто сказал, когда вы хотите его повторно использовать, вытащите его, но не раньше.

Ответ 8

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

Конечно, имейте в виду, что говорить о различии NP-hard.:)

Ответ 9

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

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

Ответ 10

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

Если вы думаете об этом, причины ясны. Скажем, приложение widget_bodger содержит 90% требуемой функциональности, чем просто добавьте недостающую функциональность в приложение.

Или скажите, что бизнес восхищался действительно классной "звуковой" функцией в widget_bodger и хотел, чтобы она была включена в приложение gernerate_executive_expenses. Ах, вы можете подумать, но тогда вы вникнете в код и обнаружите, что приложение GEE является одним из старейших приложений в компании, написано на C, должно работать на высокодоступном аппаратном обеспечении, и единственное, что можно устранить, - это основной алгоритм,

Ответ 11

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

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

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

Это противоречит вопросу о том, "какой лучший или самый модный язык/инструмент для работы?"

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

Нижняя сторона заключается в том, что переход на "новый" язык или рамки гораздо сложнее политически, хотя в какой-то момент это должно произойти.

Ответ 15

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

Это не "повторное использование кода", это "повторное использование службы", но есть некоторые общие понятия.

Ответ 16

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

Ответ 17

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

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

Ответ 18

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