Повторное использование кода: оно того стоит? - PullRequest
15 голосов
/ 28 ноября 2008

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

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

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

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

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

Ответы [ 18 ]

28 голосов
/ 28 ноября 2008

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

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

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

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

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

11 голосов
/ 28 ноября 2008

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

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

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

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

Rob

3 голосов
/ 28 ноября 2008

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

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

2 голосов
/ 28 ноября 2008

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

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

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

2 голосов
/ 28 ноября 2008

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

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

2 голосов
/ 28 ноября 2008

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

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

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

2 голосов
/ 29 ноября 2008

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

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

1 голос
/ 28 ноября 2008

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

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

1 голос
/ 28 ноября 2008

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

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

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

...