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

Вот сейчас яркий пример из моей практики. Захотелось мне адаптер для мидлваров под PSR-15. Уже подсуетился народ, уже есть такие, нашел парочку. Но. Не устраивает меня там два глобальных момента. Не нужен мне адаптер под либу PSR-7 - раз (а он там забит жестко). Можно конечно плюнуть на мертвый код. Однако не все он адаптирует, чего бы мне хотелось. В итоге я написал свой велик. И вот профиты:

1. Код содержит только то, что мне нужно. Соответственно чище и проще.
2. Я реализовал все свои хотелки. Не оправдываясь, что готовое решение этого не может.
3. Я узнал досконально, как это все работает. И PSR-15 знаю теперь с закрытыми глазами.

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

А мануалы врут. Вот тут у Slim уже хрен знает сколько висит не просто ошибка, а прямо вопиющее безобразие. Я потратил кучу времени, пока разобрался. И без того, чтобы залезть в код, не смог бы вообще.



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

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Ron, при чем тут вообще реверс-инжениринг?

и далее все верно

покажите

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

Так вот именно, что нужно делать новое, а не переписывать старое.

Проще код (именно код) становится не от сокращения текста, засчет урезания функционала, а от грамотной структуры и всего того, о чем написано в книге "Clean code" (R. Martin).

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

Если интересует практическая разница между mootools и jQuery, то например вот:
http://www.jqueryvsmootools.com/

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

Но брать и несфига проводить серьезное исследование (чем именно ядро jQuery отличается от mootools), извините, но это ППЦ! А давайте изучим чем кокнретно компиляторы С отличаются друг от друга. Давайте все драйверы отреверсим, утилиты, тексты ядра Linux, web серверов, самого PHP. Мы же их используем в своей работе, значит надо досканально знать, пользуясь подобной логикой. =) А потом давайте разберем электронные цепи компьютерного железа, причем всех архитектур и производителей. Надо же знать что покупать-то ё-моё! Или, может быть, стоит перепаять кондёр цепи питания (фильтра) ЦПУ с 0,22мкФ на 0,33, условно. Ну круто, не спорю, дайте мне сотню жизней, и оклад 200к, с радостью займусь.

Нет, господа, нужно адекватно относиться к любому делу, в том числе и программированию.

Здрасьте, а как же делать выводы о том