Возможность многократного использования кода: действительно ли это стоит того?
Попробуйте сопоставить шаблон регулярного выражения \d+\s*\w+ несколько раз:
var re = /\d+\s*\w+/g;
var input = '10mL 5mL';
var m;
var output = [];
do {
m = re.exec(input);
if (m) {
output.push(m[0]);
}
} while (m);
console.log(output);18 ответов
Мое общее эмпирическое правило:
- Если Вы повторяете его однажды, копируете его.
- Если Вы повторяете его дважды, осуществляете рефакторинг его.
Как другие плакаты сказали, собираетесь ли Вы скопировать код затем повторное использование, Вы будете радоваться, что сделали это, после того как Вы начинаете отлаживать свой скопированный код.
У нас есть некоторые, но из чего у нас есть намного больше, проекты с функциональностью, которую Вы хотите, но сделанный их собственным способом, так как правило, Вы заканчиваете тем, что сняли функции со старых проектов и повторно реализовали их в Вашем новом. Я утверждал бы, что это все еще рассчитывает - Вы все еще извлекаете пользу из того, что написали код прежде, и Вы все еще экономите время.
Кроме того, я нашел, что это - только второй раз, что Вы пытаетесь использовать функциональность, что становится очевидно, где возможность многократного использования, и при попытке обобщить что-то теоретически, что Вы почти всегда понимаете его превратно и должны изменить его в следующий раз.
Другое преимущество с повторным использованием - то, что Вы можете дорожка easiliy, где вещи происходят в основе oode. если Вы получили миллион строк кода, могут потребоваться часы для нахождения всех мест, где приложение ведет себя определенным способом. С современным IDE можно просто нажать "find references", и Вы найдете, в течение пары секунд, все места, где Ваш компонент/метод используется. Это может быть полезно, когда Вы хотите, добавляют новые опции, исправляют ошибки или просто хотят изучить, как система работает.
Мой 2c - то, что этика повторного использования кода должна быть вещью компании, не только вещью проекта. Это означает, что при запуске нового проекта первоочередная задача, "из которого других проектов я могу украсть код сделать это задание также и как можно быстрее?".
Это будет конфликтовать с вопросом, "что является лучшим - или самым модным - язык/инструмент для задания?"
Компании, которые имеют этот подход, заканчивают с объединением инженеров, которые могут легко переключиться от проекта до проекта, потому что язык, платформа и внутренняя кодовая база все последовательны.
Оборотная сторона - то, что переключение на "новый" язык или платформу является намного более политически трудным, даже при том, что это должно будет произойти в какой-то момент.
Я соглашаюсь с Вами, поскольку нет никакого смысла в кодировании способом, которое делает класс простым в использовании за пределами текущего приложения. Большинство, если нас не делают этого и в деловой среде, нет никакой потребности к. Если для другого приложения нужна эта функциональность позднее затем извлечение и commonalising, код может быть сделан как часть того второго проекта, и управление, вероятно, согласится с этой точкой зрения.
Однако это - хорошая практика для создания кода допускающим повторное использование в рамках ограничений текущего приложения. Осуществите рефакторинг свой код, чтобы избежать дублирования в Вашем текущем объеме работ. Таким образом, Вы помогаете работать с позднее. Не так кодируйте для повторного использования что касается изменения, изменение намного более распространено.
Одна из причин, почему SOA перестал работать или еще не поднялся, то, что трудно снова использовать сервис: или это слишком конкретно, и это не может использоваться в другом месте, или слишком универсальное (и обычно очень сложное) и не удовлетворяет потребности различных клиентов.
Это не "повторное использование кода", это - "сервисное повторное использование", но существуют некоторые общие понятия.
Если Вы уверены, что не испытываете необходимость в нем снова, не беспокоиться. Даже, если Вы не думаете, что это могло бы пригодиться. Осуществите рефакторинг его при реальной необходимости в нем снова...
Однако не создание его reuseable не является никаким оправданием за то, что не был сделан он прозрачным. Каждый раз, когда я пишу код максимально прозрачно, это всегда уже оказывается 99%, допускающими повторное использование...
Существуют совсем другие мнения о том, что делает код допускающим повторное использование. Я сказал бы, что Ваше время хорошо потратило ясно давание понять кода и хорошо учтенный (т.е. разделение между обязанностями).
Дополнительная льгота от этого является лучшей возможностью многократного использования. Основное преимущество делает код легче понять, изменить и отладить.
Обернуть его. Не делайте сложных схем конфигурации, точек расширения и событий только для создания этого допускающим повторное использование. Попытайтесь найти правильные подвижные части так, чтобы код мог быть составлен в ответ на новые потребности.
Часто "допускающий повторное использование" код является кодом, который абстрагирован и построен из модулей, и, мне, основное преимущество не является возможностью многократного использования, а скорее увеличенной тестируемостью. Поскольку, когда Вы изолируете и строите код из модулей, это обычно становится более тестируемым. Повторное использование является удобным, но часто неиспользованным побочным эффектом.
И на другой ноте, Juval Lowry защищает основанное на интерфейсе программирование, так как он поддерживает, что интерфейсы являются единственным компонентом возможности многократного использования. Что-либо еще подразумевало функциональность (трудно к повторному использованию), в то время как интерфейсы определяют контракт только, который является неявно допускающим повторное использование.
По моему скромному мнению, определенный код, вероятно, будет часто снова использоваться, и имеет смысл готовить его к частому повторному использованию. Другой код не и вероятно не должен быть разработан вне решения непосредственной проблемы.
Конечно, действительно знайте, что сообщение различия является NP-трудным.:)
После того как Вы добираетесь выше уровня технических утилит, я видел очень мало фактического повторного использования в реальном мире.
Если Вы думаете об этом, причины ясны. Скажите, что widget_bodger приложение содержало 90% функциональности, которой Вы требуете, чем Вы просто добавили бы недостающую функциональность к приложению.
Или скажите, что бизнес восхитился действительно прохладной функцией "звукового сигнала" в widget_bodger и хотел включенный в gernerate_executive_expenses приложение. А-ч resuse Вы мог бы думать, но затем Вы роете в код и находите, что НУ И ДЕЛА приложение является одним из самых старых приложений в компании, записан в C, должен работать на высоконадежных аппаратных средствах и единственной вещи, которая resuable, основной алгоритм.
leppie записал:
Мое общее эмпирическое правило:
- Если Вы повторяете его однажды, копируете его.
- Если Вы повторяете его дважды, осуществляете рефакторинг его
И я добавил бы, удостоверьтесь, что комментарий добавляется к обеим частям кода для указания на дублирование в случае, если существует ошибка. Вы не хотите фиксировать его в одной части и не другом (BTDTGTT).
Ограбить
Большой вопрос!
Я думаю, "разрабатывая для повторного использования", неправильный путь вокруг. Я нахожу, что код, который я пишу для работы, чистый и симпатичный, является допускающим повторное использование. Фактический дизайн для повторного использования только происходит в первый раз, которые кодируют, на самом деле снова используется!
Проведение времени, заранее пытаясь сделать что-то допускающим повторное использование имеет тенденцию быть пустой тратой времени, потому что Вы никогда не знаете то, что должно будет быть снова использовано.
Однако в моем задании у нас есть набор библиотек (большой, 500 МБ или больше), который снова используется почти для каждого проекта - главным образом проблемно-ориентированный материал.
Я не эксперт в методологии XP (или любой методологии), но я думаю, что принцип YAGNI мог быть применен здесь.
Только измените код для повторного использования, когда необходимо будет снова использовать его.
Я думаю, что лучший подход должен попытаться разработать код с хорошими интерфейсами и разделением обязанностей между классами, не вызывая беспокойство слишком много о повторном использовании. Но по крайней мере при разработке этого пути, Вы оставляете открытыми возможность повторного использования. Хорошее эмпирическое правило состоит в том, чтобы спросить себя, "если я возвращусь к этому коду после 3 месяцев, то я пойму это, и я мог расширить его, если бы я имел к?"
IMO, который - один из худших методов в промышленности, когда команда даны сигнал, чтобы уйти и записать их собственную "допускающую повторное использование" платформу....
Мне нравится модель LISP, где Вы постоянно расширяете язык. В конечном счете Вы волнуете с проблемно-ориентированным языком для Вашей проблемной области. Не то, чтобы я на самом деле пишу любую шепелявость, но на языках я чаще всего использую---Lua и C прямо сейчас---, я обычно вытаскиваю что-то в модуль и снова использую его, а не клонирую и изменяю.
Для программиста C наиболее существенным примером этого подхода являются Интерфейсы и Реализации bookC Dave Hanson. Dave взял каждую допускающую повторное использование идею, которую он имел в записи трех или четырех компиляторов и поместил их всех в книгу---, и программное обеспечение является бесплатным. Невероятный материал. Теперь, если я пишу код C, и я хочу использовать его во второй раз, когда я делаю интерфейс в стиле Hanson. Некоторые вещи я сделал этот термин: 2-мерные массивы, 2-мерные массивы с блокированием, двухмерными растровыми изображениями, средствами чтения и устройствами записи для pbmplus файлов, и так далее. С этой инфраструктурой на месте было легко записать программу, которую я желал в течение многих лет, который должен удалить черные края из сканирований фотокопий книжных страниц.
Таким образом, я соглашаюсь с тем, кто бы ни сказал, когда Вы хотите снова использовать его, вытащить его---, но не прежде.
Существует различие между конфигурируемостью и возможностью многократного использования - первый может быть чрезвычайно полезным в большом количестве различных ситуаций, когда изменения среды или безотносительно создания вещей, настраивающихся в способе, которым я понимаю это, главным образом случай разделения кода и данных - это - просто хорошая практика действительно.
Разработка для возможности многократного использования только действительно полезна при создании чего-то, что Вы планируете использовать в качестве библиотеки для нескольких проектов. Поскольку годы проходят, я все больше становился знающий о принципе YAGNI, и в эти дни я просто стремлюсь писать чистый и устойчивый код для задачи под рукой. Мой опыт состоял в том, что, если что-то будет снова использованным, очень маловероятно, что Вы предскажете точно, как это должно будет быть снова использовано, таким образом, будет намного лучше только добавить код, в котором Вы нуждаетесь на данный момент. Тот путь, если необходимо снова использовать его в будущем, можно добавить новый материал, который делает точно, в чем Вы нуждаетесь, не имея необходимость повреждать любую существующую функциональность, которую Вы записали в прошлой попытке ожидать, как Вам, возможно, понадобился бы он теперь.
Можно найти, что после выполнения этого пару раз у Вас есть библиотека, которая стабильна и устойчива и не нуждается в Вас для изменения его, потому что оно на самом деле делает все вещи, в которых Вы нуждаетесь - мне намного легче признать что произойти тем эволюционным способом, чем потратить впустую слишком много времени, предполагая о будущем.