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

Question

Мы все пишем повторно используемые классы и код.

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

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

Answer 8

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

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