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

Мое общее практическое правило:

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

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

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

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

Леппи написал:

Мое общее практическое правило:

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

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

Роб

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

Изменяйте код для повторного использования только тогда, когда вам нужно его повторно использовать.

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

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

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

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

IMO - одна из худших практик в отрасли - когда команде дают добро написать свою собственную «многоразовую» структуру ....

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

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

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

Конечно, имейте в виду, что отличить разницу сложно. :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это БУДЕТ противоречить вопросу «какой лучший - или самый модный - язык / инструмент для работы?»

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

Обратной стороной является то, что переключиться на «новый» язык или фреймворк гораздо сложнее с политической точки зрения, даже если в какой-то момент это БУДЕТ.

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

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

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

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