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

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

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

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

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

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

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

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

Зависит..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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