Разве изобретать колесо действительно так плохо?

103

Ее общее знание программирования , что изобретать колесо плохо или зло .

Но почему это так?

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

Это приводит меня к этому вопросу:

Если я вижу, что кто-то явно заново изобретает колесо, создав свой собственный метод чего-то, что уже встроено в язык / структуру. Во-первых, ради аргументов, давайте предположим, что их метод так же эффективен, как и встроенный метод. Также разработчик, осведомленный о встроенном методе, предпочитает свой собственный метод.

Почему он должен использовать встроенный над своим?

JD Исаакс
источник
16
Это большой вопрос. Я не думаю, что люди должны изобретать велосипед, но важно бросить вызов этим идеям, чтобы убедиться, что они выдерживают.
Джон Хопкинс
4
@Demian - На самом деле это очень хорошая идея. Если вы можете объяснить это, то вы, вероятно, оправданы.
Джон Хопкинс
2
Во всех решениях полезно спросить, какова ваша основная цель, а затем заставить другие подэлементы поддерживать основную цель. Если вашей главной целью является своевременное предоставление качественного продукта, то дублирование уже существующего кода, вероятно, пойдет на пользу этой цели. Если ваша основная задача - создать более продуманную библиотеку, то, возможно, это будет способствовать достижению этой цели. Если вы работаете на кого-то другого, то вам нужно задать вопрос с их точки зрения , а не с вашей.
gahooa
5
Изобретайте заново, если существующие колеса действительно не справляются с вашими конкретными задачами, или ... если вы хотите знать, как работают колеса! Интересная статья на эту тему: codinghorror.com/blog/2009/02/...
Lindes
4
Приписывается Дугласу Крокфорду:The good thing about reinventing the wheel is that you can get a round one.
Джоэл Этертон

Ответы:

72

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

Димитрий С.
источник
14
+1 Самый важный момент - это то, что он полностью под вашим контролем, и вы знаете это наизнанку. Отладка других библиотек может вызвать серьезные головные боли, если это вообще возможно, и сказать, что все зрелые библиотеки не содержат ошибок, по меньшей мере оптимистично.
Orbling
6
Команда Excel даже зашла так далеко, что написала собственный компилятор, потому что не хотела внешних зависимостей, которые могли бы повлиять на проект. Это верный момент, но насколько важен этот контроль - главный вопрос.
Джон Хопкинс
6
+1. Однажды в моей прошлой жизни в качестве программиста на MFC / VC ++ мы использовали стороннюю библиотеку для различных компонентов графического интерфейса, что оказалось для меня настоящим кошмаром. Эти вещи глубоко зацепились в программном обеспечении и не могли быть удалены (не тратя нереальные человеческие месяцы, которых у нас не было усилий). Я абсолютно уверен, что любая первоначальная экономия времени из-за того, что нам не приходилось катать наши собственные сетки и менеджеры по компоновке, была сорвана на несколько десятков лет от необходимости поддерживать это чудовище.
Бобби Столы
4
@Guzica, неудачный выбор не обязательно достаточен для обобщения, и существуют другие библиотеки, которые хорошо поддерживаются и являются хорошим выбором. Вопрос в том, было ли оригинальное решение достаточно хорошо изучено?
5
С другой стороны, если вы используете уже существующее колесо, вы, как правило, получаете МНОГО помощи, которая часто хорошо индексируется Google, чтобы помочь вам в его отладке.
Дэн Рэй
83

Зависит..

Как и во всем, это о контексте:

Хорошо, когда:

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

Это плохо, когда:

  • Функциональность уже существует и, как известно, стабильна и общеизвестна (популярна).
  • Ваша версия не добавляет ничего нового.
  • Ваша версия содержит ошибки или ограничения (например, ваша версия не является поточно-ориентированной).
  • В вашей версии отсутствуют функции.
  • Ваша версия имеет худшую документацию.
  • В вашей версии отсутствуют юнит-тесты по сравнению с тем, что она заменяет.
Darknight
источник
2
Наряду с вашим первым пунктом (и обратным к вашему четвертому), если с колесом трудно справиться или, что еще хуже, негибко, вы действительно можете улучшить его. Это часто случается с компонентами пользовательского интерфейса в некоторых областях, где колесо оказывается колесом поезда и работает только на одной дорожке.
Маг
1
Трудно понять, кольца звучат правдоподобно для меня. Я просто не получал анализ направленного графа, поэтому сделал его, и теперь я знаю. Теперь я чувствую уверенность в использовании фреймворка
JasTonAChair
1
Я бы добавил четвертый для столбца «Хорошо» (хотя это редко применяется): если вы понимаете проблемное пространство лучше, чем существующая библиотека. Де-факто стандартная библиотека времени Java Joda была написана потому, что со встроенным было трудно работать, и была переписана как библиотека стандартного времени де-юре Java 8, потому что теперь они понимают проблему гораздо лучше, чем когда они писали оригинальное время joda.
Морген
55

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

Это все так плохо? Да. Почему? Потому что существующее колесо, скорее всего, было обработано с течением времени и уже было проверено во многих обстоятельствах и на множестве различных видов данных. Разработчик (и) существующего колеса уже столкнулся с крайними случаями и трудностями, которые изобретатель еще не может себе представить.

Дэн Рэй
источник
3
Или лень - то, что нельзя потрудиться пойти и искать альтернативы или найти менее интересным пойти и сделать так, чтобы написать код.
Джон Хопкинс
9
Я видел много случаев, когда переизобретать колесо было сделано из высокомерия, с отношением, что библиотека / фреймворк xyz предназначена только для плохих программистов, которые не знали, как сделать это «правильным способом». Черт, я видел этот аргумент (так или иначе) на SO сайтах.
Билл
2
... Что создает постоянное (наихудшее) бремя обслуживания для текущих или последующих разработчиков.
gahooa
2
Это то, что я делал годами. Я бы катил свою функцию на языке, потому что не знал, что эта функция уже встроена.
Матчу
1
С тех пор, как я написал этот пост (три года назад), я нанял и уволил разработчика, которого я назвал в первом предложении «довольно редким». Он длился месяц. Я бы сказал ему, как мы здесь работаем, и он сказал бы: «Я слышу, что вы говорите». Мне потребовался месяц, чтобы услышать недосказанное «... но это неправильно, и я буду тайно делать все, кроме этого» в конце фразы.
Дэн Рэй
22

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

Просто спросите его, в чем недостаток.

user8865
источник
9
+1 Хорошая метафора «квадратные колеса должны быть изобретены заново» .
Orbling
+1 за «Квадратные колеса должны быть заново изобретены»
Tintu C Raju
17

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

Тем не менее, если мне нужно включить сторонние библиотеки, это будет суждение в зависимости от того, насколько широко используется и уважаемая библиотека. Я имею в виду, мы говорим о Boost или офигенных инструментах разбора строк 1.0 Боба?

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

Таким образом, использование существующего кода - это хорошо, но зависимости - это плохо . К сожалению, эти два утверждения противоречат друг другу, поэтому хитрость заключается в том, чтобы найти правильный баланс. Вот почему вам нужно определить приемлемые зависимости. Как я уже сказал, все в стандартной библиотеке языка, скорее всего, является приемлемой зависимостью. Далее, библиотеки, которые высоко ценятся во всей отрасли, также в целом приемлемы (например, Boost для C ++ или jQuery для Javascript), но они все еще менее желательны, чем стандартная библиотека, поскольку они , как правило, менее стабильны, чем стандартизированные библиотеки. ,

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

Так что на самом деле все это уравновешивает. Но дело в том, что просто слепо говорю: «Повторное использование кода хорошо! Изобретаем колесо плохо!» это опасное отношение. Преимущества использования стороннего кода должны быть сопоставлены с недостатками введения зависимостей.

Чарльз Сальвиа
источник
3
+1. Я склонен чувствовать то же самое. Я гораздо больше склонен изобретать маленькие колеса, если использование существующего колеса создаст проблемы с зависимостями, чем если существующее колесо уже существует, настроено и ожидает использования в любой среде, где оно может мне понадобиться.
Димча
14

Если бы люди не изобретали колеса, мир был бы наполнен этими .. введите описание изображения здесь

Вот диалог с моего рабочего места:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

Есть два варианта: либо изобретать велосипед, либо использовать Colorama. Вот к чему приведет каждая опция:

Используя Колораму

  • Может быть, немного быстрее, чтобы начать работать
  • Добавление сторонней зависимости для чего-то тривиального
  • Вы продолжаете быть таким же глупым, как и раньше, используя Колораму

Изобретая колесо

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

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

оборота Питикос
источник
2
+1 не согласен с вами на 100%, но понравился образ, используемый для передачи идеи.
Тулаинс Кордова
Этот ответ несколько обходит, что ваш работодатель платит за вашу роскошь изобретать это колесо для вашей собственной образовательной выгоды. Возможно, вы должны сделать это в свое время; если спросят, ваш работодатель, вероятно, скажет, что он. / Она просто хочет, чтобы работа была выполнена в кратчайшие сроки, и, если это делает Colorama, продолжайте в том же духе.
Нил Хотон
2
@ NeilHaughton, как я понимаю, мое «собственное» образовательное пособие также является преимуществом моего работодателя.
Питикос
Хммм ... твой работодатель, конечно, может этого не видеть, и он кладет хлеб на твой стол.
Нил Хотон
Библиотека Колорама, сама по себе была переизобретением колеса. Уже был интерфейс для отображения цветов в терминале (через специальные символы), и до его появления люди уже делали это. Библиотека Colorama заново изобретает интерфейс для достижения цели. Итак, вопрос здесь больше в том, собираетесь ли вы использовать предположительно улучшенное колесо или вы используете старое колесо в своем проекте? В этом случае заново изобретать колесо будет создавать Colorama2, который «улучшается» еще дальше, помимо того, что должен был предложить Colorama.
Лыжи
13

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

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

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

Марк Фридман
источник
+1 Очень хорошая точка зрения на перспективу обучения, чтобы эффективно использовать библиотеку, вы должны действительно хорошо знать, как она работает. Я не люблю использование инструментов в черном ящике. Также отличное замечание по криптографическим библиотекам, слишком рискованным, чтобы накатить свои собственные на этот счет.
Orbling
Я бы добавил, что если есть опасения, что сторонняя библиотека может исчезнуть, это довольно хорошее оправдание для написания программного интерфейса, который позволяет легко заменить одну библиотеку на другую.
user8865
Хороший вопрос - мы используем шаблон адаптера только для этой цели, и он недавно спас нас, когда нам пришлось поменять стороннюю библиотеку FTP.
Марк Фридман
9

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

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

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

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

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

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

Джон Хопкинс
источник
2
На вашей последней строчке: чтобы узнать, как они решаются. Программирование зависит от опыта в конце концов.
Orbling
@ Orbling - достаточно справедливо, но вы не должны делать это в рабочем коде, и я предполагаю, что это вопрос. Поправлю.
Джон Хопкинс
@ Джон Хопкинс: Хорошо, производственный код, как правило, следует из обучения, если это не сделано в ваше собственное время.
Orbling
@ Orbling - Я бы сказал, что вы никогда не должны изучать что-то ради обучения, а затем запускать его в производство. Либо что-то является рабочим кодом, и в этом случае оно должно быть лучшим решением, либо оно предназначено для обучения. Бывают моменты, когда они перекрываются, но это не будет одним из них, поскольку если вы сами не покатитесь, то это действительно лучшее решение.
Джон Хопкинс
@ Джон Хопкинс: В идеале да, но часто в команде нет никого, кто бы знал, как это сделать, до такой степени, что доступные библиотеки могут быть ненадежно исправными. Обучение, или «исследование», как его называют большинство людей, становится необходимостью. Да, это не совсем обучение ради обучения, но это обучение, чтобы избежать будущего риска.
Orbling
9

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

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

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

  • Для существующего колеса требуется другой язык и / или стиль программирования, чем я бы предпочел использовать.
  • Существующее колесо работает только с устаревшей версией языка (например, Python 2 вместо Python 3).
  • Там, где есть компромиссы между эффективностью, гибкостью и простотой, существующее колесо делает выбор, который не оптимален для моего варианта использования. (Известно, что я заново изобретал даже функциональность из библиотек, которые я сам написал в этих случаях. Обычно это потому, что я написал библиотечную версию функции как универсальную и достаточно эффективную, когда мне нужно что-то очень быстрое в моем конкретном случае. кейс.)
  • В существующем колесе есть тонна устаревшего кода, который совершенно бесполезен в случае нового кода, но тем не менее усложняет жизнь (например, используемая мной библиотека Java, которая вынуждает меня использовать ее классные контейнеры-контейнеры, потому что она была написана до обобщения и т. Д.) ,
  • Способ, которым существующие колеса моделируют проблему, полностью отличается от того, что удобно для моего варианта использования. (Например, может быть, мне удобно иметь ориентированный граф, представленный объектами узлов и ссылками, но существующее колесо использует матрицу смежности или наоборот. Может быть, мне удобно выложить свои данные в главном порядке столбцов, но существующее колесо настаивает на мажорном ряду или наоборот.)
  • Библиотека добавляет массивную, хрупкую зависимость, которая будет основной проблемой для запуска и запуска везде, где я хочу развернуть свой код, когда все, что мне нужно, это небольшая часть его функций. С другой стороны, в этом случае я иногда просто извлекаю нужную функцию в новую, меньшую библиотеку или просто копирую / вставляю, если библиотека с открытым исходным кодом и кодовая база делает это достаточно простым. (Я даже сделал это с относительно большими библиотеками, которые я написал сам, а не только с другими людьми.)
  • Существующее колесо пытается педантично соответствовать некоторому стандарту, что неудобно и неуместно для моего случая использования.
dsimcha
источник
Я думаю, что все сводится к следующему: если колесо соответствует вашим целям, используйте его, если нет, создайте новое колесо, которое подходит. Только не будьте догматичными об этом так или иначе.
Нил Хотон
5

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

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

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

Рейчел
источник
2
Это причина, чтобы не заменить его, не делать это в первую очередь. Я предполагаю, что вы не будете делать то же самое сейчас, зная, что альтернатива существует?
Джон Хопкинс
@ Джон лол определенно нет! И я первоначально прочитал вопрос о том, почему разработчик предпочел бы свой собственный метод ранее существовавшему. Перечитывание вопроса теперь заставляет меня понять, что заданный вопрос был обратным, но я оставляю здесь ответ, так как он кажется связанным и получил некоторые положительные голоса
Рэйчел
4

Изобретать колесо - отличный способ узнать, как работает колесо, но это не очень хороший способ построить автомобиль.

Дима
источник
4

В настоящее время я работаю на кучу дешевых скатов.

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

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

Презентация по сборке против покупки .
Статья о сборке против покупки .

Если я вижу, что кто-то явно заново изобретает колесо, создав свой собственный метод чего-то, что уже встроено в язык / структуру. Во-первых, ради аргументов, давайте предположим, что их метод так же эффективен, как и встроенный метод. Также разработчик, осведомленный о встроенном методе, предпочитает свой собственный метод.

Почему он должен использовать встроенный над своим?

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

Наконец, когда ваш местный разработчик уходит, а кто-то другой должен поддерживать написанный им код, он будет полностью переработан и заменен тем, что находится в фреймворке. Я знаю, что это произойдет, потому что у моего нынешнего работодателя есть код, который был перенесен на более новые версии VB за последние годы (самый старый продукт был на рынке около 20 лет), и это то, что произошло. Разработчик с самой длинной занятостью в моем офисе был здесь 17 лет.

Tangurena
источник
Чтобы быть справедливым, иногда «стандартная» версия была помещена туда как переосмысление того, что большинство людей в итоге делало до того, как была разработана стандартная версия. Таким образом, стандартным считается «грандиозное окончательное переосмысление». Но переход на стандартную, хорошо протестированную, гораздо более надежную и исправленную версию может привести к ошибкам, потому что код вашего приложения делает предположения, которые верны для вашей старой нестандартной версии, но ложны для новой стандартной.
Steve314
1
В рациональной компании, если будет решено, что привязка к поставщику является приемлемой, компании (являющейся покупателем и зависящей от предложения поставщика) необходимо будет установить хорошие деловые отношения с поставщиком, а также застраховаться от различных неудач бизнеса. Примеры: отказ от предоставления поддержки / исправления ошибок, повышение цен, изменение условий контракта, необоснованные судебные процессы или уход из бизнеса в целом. Это хеджирование также является частью стоимости, и его часто игнорируют. (Точно так же, как игнорируются затраты на внутреннюю разработку.) Примечание. Эта стоимость не указана во встроенных предложениях.
2010 г.
Разве вы не забываете, что ваши обманутые работодатели фактически предоставляют вам больше оплачиваемой работы, чем вы могли бы иметь в противном случае? Вы должны поощрять их, а не жаловаться на это!
Нил Хотон
4

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

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

Самое главное - знать, КОГДА сделать свой собственный. Вы должны иметь хорошее представление о том, что могут делать стандартные детали, а что нет, прежде чем приступить к разработке своих собственных.

Майкл Кохне
источник
4

Независимо от того, изобретать велосипед заново или нет, это вопрос стоимости / выгоды. Затраты довольно очевидны ...

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

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

Преимущества могут быть ...

  • Возможность добавлять функции, которых нет в существующих библиотеках. Например, у меня есть контейнеры, которые «поддерживают» свои экземпляры итератора / курсора. Вставки и удаления не делают недействительными итераторы. Итератор, указывающий на вектор, будет продолжать указывать на один и тот же элемент (не на тот же индекс) независимо от вставок и удалений ранее в векторе. Вы просто не можете сделать это со стандартными контейнерами C ++.
  • Более специализированный дизайн, ориентированный на ваши конкретные требования и учитывающий ваши приоритеты (но остерегайтесь тенденции к эффекту внутренней платформы).
  • Полный контроль - некоторые третьи лица не могут решить перепроектировать API таким способом, который означает, что вы должны переписать половину вашего приложения.
  • Полное понимание - вы разработали его таким образом, поэтому вы, надеюсь, полностью понимаете, как и почему вы это сделали.
  • РЕДАКТИРОВАТЬ Вы можете извлекать уроки из других библиотек, не попадая в те же ловушки, если будете избирательно относиться к тому, как вы имитируете их.

Одно дело - использование сторонней библиотеки может считаться изобретением колеса. Если у вас уже есть своя древняя, хорошо используемая, хорошо протестированная библиотека, тщательно подумайте, прежде чем отказываться от нее, чтобы использовать стороннюю библиотеку. Это может быть хорошей идеей в долгосрочной перспективе, но может потребоваться огромный объем работы и множество неприятных сюрпризов (из-за тонких семантических различий между библиотеками), прежде чем вы туда доберетесь. Например, рассмотрим, как я переключаюсь со своих собственных контейнеров на стандартные библиотечные. Наивный перевод вызывающего кода не учитывает тот факт, что стандартные контейнеры библиотеки не поддерживают свои итераторы. Случаи, когда я сохраняю итератор на потом как «закладку», вообще не могут быть реализованы с помощью простого перевода - я

Steve314
источник
3

Если есть работающий компонент, который делает то, что вам нужно, зачем тратить время на написание и отладку собственной версии? Точно так же, если вы уже написали код для выполнения подобной функции ранее, зачем переписывать его?

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

Дейв
источник
3

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

Например, я бы никогда не писал код JavaScript с нуля; вместо этого я бы начал с jQuery и строил свои приложения поверх этой платформы.

Джастин этир
источник
3

Мое личное правило:

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

Джон
источник
3

Быть «плохим» или даже «злым» - это довольно сильные слова.

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

Это не относится к Java-программам, поскольку JVM очень строго определена, но некоторые алгоритмы все еще очень трудно понять. Например, Джошуа Блох описывает, как обманчиво простой алгоритм бинарного поиска в библиотеке времени выполнения Java содержал ошибку, на которую ушло девять лет:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

Он был найден, исправлен и распространен в будущих дистрибутивах Java.

Если вы используете встроенный двоичный поиск, вы просто сэкономили время и деньги, заставив Sun выполнять тяжелую работу по поиску, исправлению и распространению этого исправления. Вы можете использовать их работу, просто сказав: «Вам нужно хотя бы Java 6 update 10».

Если вы используете свою собственную реализацию, которая, скорее всего, тоже содержит эту ошибку, вам сначала нужно, чтобы ошибка проявилась. Учитывая, что этот конкретный пример отображается только в БОЛЬШИХ наборах данных, он обязательно произойдет где-то в производстве, что означает, что по крайней мере один из ваших клиентов будет затронут и, скорее всего, потеряет реальные деньги, пока вы найдете, исправите и распространите исправление.

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

user1249
источник
+1 за использование платформы для развертывания исправлений ошибок. С другой стороны, поставщик платформы должен решить, распространять ли исправление. Другой поставщик может выбрать: (1) распространить исправление бесплатно; (2) удерживать исправление до обновления основной версии; (3) распространять исправление среди пользователей последней версии, но отрицаем, что более ранние версии (4) отказываются исправлять в целом, утверждая, что это может «вызвать повсеместную несовместимость» и «затрагивает только ограниченных пользователей».
2010 г.
@ rwong, если вы нашли ошибку во встроенной подпрограмме, лучше всего было бы предоставить собственную фиксированную версию. Это относится к «очень веским причинам».
ørn: Я хочу сказать, что помимо упомянутых вами доброжелательных продавцов есть и другие поставщики.
rwong
@ rwong, в этом случае это соответствует «очень веской причине для выбора личной реализации».
3

Недавно я опубликовал свои мысли по этой теме. Обобщить:

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

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

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

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

    «Наш сайт сломался, и мы смогли исправить это немедленно».

realworldcoder
источник
0

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

Майкл К
источник
0

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

Изобретать колесо - это не плохо, это ленивые люди, чтобы не работать. Даже авторы фреймворков действительно изобретают; вся платформа .Net была заново изобретена, чтобы сделать то, что предлагал COM.

Акаш Кава
источник
0

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

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

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

Мой фактический ответ на вопрос: есть только две ситуации, из-за которых переизобретение колеса является плохой вещью:

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

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

оборота ClosetGeek
источник
0

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

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

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

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

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

В конце концов, выбор правильных инструментов - сложное решение, а «переосмысление колеса» - не очень полезная перспектива.

лыжа
источник
-1

Я написал небольшую статью об этом - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

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

Сэмюэл Делеск
источник