Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 92
Ну в статье вообще не затрагивается влияние велосипедизма на проект. Там только про позитивное влияние на разработчика. Я бы сказал «изобретайте велосипед почаще, и дома»
Какой может быть вред?
Если всегда использовать готовое и не пытаться делать самому — прогресс тут-же остановится.
Если всегда использовать готовое и не пытаться делать самому — прогресс тут-же остановится.
в принципе много успешных некоммерческих проектов (или даже все) когда-то были велосипедами для себя )))
Ну это про проект в целом. А как насчет отдельных юнитов? Ну например свой собственный XML-парсер, в коммерческом, и в целом невелосипедном проекте. Нет, нельзя так :)
Как-то выбирал себе php-компонент для очистки html кода, введенного пользователем от вредных, смотрел готовые. Среди прочих обратил внимание на kses, нашел в нем сам несколько уязвимостей (которые можно вылечить выбросив код и переписав все заново), перебрал другие компоненты, некоторые были слишком объемные и сложно настраиваемые, другие содержали массу ошибок. В итоге написал сам.
Смотря на такие готовые компоненты, я часто прихожу к выводу, что писать свой велосипед не просто можно, а необходимо.
Хотя некоторые забивают, как, например wordpress и им приходистя постоянно латать дыры из-за таких сторонних продуктов.
Смотря на такие готовые компоненты, я часто прихожу к выводу, что писать свой велосипед не просто можно, а необходимо.
Хотя некоторые забивают, как, например wordpress и им приходистя постоянно латать дыры из-за таких сторонних продуктов.
Чем не устроил htmlpurifier.org?
А чем не устроил simplepie.org?
Что вы хотите этими всеми «чем не устроил ...» сказать?
Хочу сказать, что по моему мнению в приведенных примерах изобретать велосипед не было необходимости.
так суть же в саморазвитии,)
людям не стоило развиваться?)
людям не стоило развиваться?)
Стоило, но смысл их высказываний в том, что они изобретали велосипед потому, что существующие решения их не устроили. А я не согласен :) Во всяком случае, сильных аргументов не услышал.
Не согласны, что их не устроило? :) А вообще, по-моему редкость, когда готовые решения устраивают на 100% даже по функциональности, не говоя про другие критерии. Причём не любые готовые, а те что сумел найти, то есть может где-то и есть устраивающее, но вот на глаза не попалось. И приходится выбирать то ли реализовать самому с нуля, то ли писать какую-то обертку/расширение к готовому, то ли засыпать автора фичереквестами и патчами (без всякой гарантии, что он примет), то ли форкать. Часть способов такого использования готового подразумевает не только изучение документации, но и глубокое «ковыряние» в чужом коде, далеко не факт, что легкочитаемом.
:) Наверное, я — такая редкость, но в основном я пользуюсь готовыми компонентами, даже если их надо чуть-чуть допилить. Редко когда приходится свое писать.
Интерфейсами занимаетесь?
кстати Джоел тоже говорит, что не надо выбрасывать старый код и писать новый, легче исправить тот, что не работает, чем заново переписать. Приводит в пример netscape :)
не развивается, заброшен автором
Чем больше ошибок — тем больше опыта.
Чем больше опыта — тем меньше ошибок.
Совет конечно ужасный. Мне сложно представить реальную ситуацию, когда такой подход себя оправдывает: не обязательно попадать под машину, чтобы понять что попадать под машину — плохо.
Чем больше опыта — тем меньше ошибок.
Совет конечно ужасный. Мне сложно представить реальную ситуацию, когда такой подход себя оправдывает: не обязательно попадать под машину, чтобы понять что попадать под машину — плохо.
Процесс написания своего велосипеда повышает профессиональный уровень программиста. © Opik
добавить бы еще одну фразу:
«ну и не забывайте иногда напрягать мозг алгоритмическими задачами»
«ну и не забывайте иногда напрягать мозг алгоритмическими задачами»
В таком случае разработку программы нужно начинать с написания собственного компилятора. А может с проектирования собственного процессора?
Есть естественный процесс роста специалиста — мы учимся работать с некими готовыми блоками и собирать из них программу. Или сеть. Или ИТ инфраструктуру. Используем при этом всевозможные How-To, Configuration Guides и прочие Best Practices. Если этого оказалось достаточно — замечательно.
Если нет, мы находим тот блок, работу которого нам нужно оптимизировать, и вникаем в его строение и логику.
Главное на этом этапе — не просто «дергать за ниточки, может и заработает», а реально разобраться.
Понять логику.
Именно на этом этапе различается специалист от «натаскаканного ламера». Специалист понимает как оно работает. Ламер — «камлает».
И, поняв, подкрутить что нужно и вновь вернуться на предыдущий уровень абстракции.
Через какое-то время, изучив много примеров работающего и оттестированного кода, специалист может писать сам с нуля. И писать — правильно.
Помните — платят вам не за то, что вы гениально кодите, а за создание работающих программ в заданные сроки. Умение писать алгоритмы сортировки на любых языках является полезной привычкой для развития мышления, но на вашу эффективность как разработчика влияет косвенно. А вот умение разобраться в написанном другим алгоритме и подправить фрагмент кода, чтобы он заработал в новых граничных условиях или включил новый параметр — это влияет прямо.
Есть естественный процесс роста специалиста — мы учимся работать с некими готовыми блоками и собирать из них программу. Или сеть. Или ИТ инфраструктуру. Используем при этом всевозможные How-To, Configuration Guides и прочие Best Practices. Если этого оказалось достаточно — замечательно.
Если нет, мы находим тот блок, работу которого нам нужно оптимизировать, и вникаем в его строение и логику.
Главное на этом этапе — не просто «дергать за ниточки, может и заработает», а реально разобраться.
Понять логику.
Именно на этом этапе различается специалист от «натаскаканного ламера». Специалист понимает как оно работает. Ламер — «камлает».
И, поняв, подкрутить что нужно и вновь вернуться на предыдущий уровень абстракции.
Через какое-то время, изучив много примеров работающего и оттестированного кода, специалист может писать сам с нуля. И писать — правильно.
Помните — платят вам не за то, что вы гениально кодите, а за создание работающих программ в заданные сроки. Умение писать алгоритмы сортировки на любых языках является полезной привычкой для развития мышления, но на вашу эффективность как разработчика влияет косвенно. А вот умение разобраться в написанном другим алгоритме и подправить фрагмент кода, чтобы он заработал в новых граничных условиях или включил новый параметр — это влияет прямо.
Нужно знать, когда стоит изобретать велосипед, а когда пользоваться готовым. К сожалению, часто встречаются люди впадающие в крайности.
Всё хорошо, если в меру. И лень, и «велосипеды», и амбиции, и даже мат.
Один из факторов побуждающий изобретать велосипеды — это недостаток информации (кажется, что задача уникальна и даже не пытаешься найти готовых решений) или, как ни странно, наоборот, — избыток информации (готовых решений столько, что проще реализовать самому, чем искать искать плюсы и минусы уже существующих продуктов, особенно если интуиция подсказывает, что минусы бывают всегда, а опыт, что обнаружатся они, когда откатиться будет поздно).
Плюс далеко не всегда разработчику нужно решить задачу в минимально возможные сроки с максимально возможным качеством. Цель разработчика, как «существа экономического», вовсе не оптимизация расходов заказчика, а оптимизация своих доходов и далеко не всегда эти цели не вступают в прямой конфликт. Примеров множество, самые типичные — оплата по трудоемкости и «подсаживание на иглу поддержки». Почему-то многие заказчики не хотят платить за результат, а хотят за трудоёмкость (в строках кода ли её измерять, или в человеко-часах — не важно) и считают себя обманутыми, если с них возьмут 10 000 за часовую настройку бесплатной CMS и довольны, если им за 50 000 за пару месяцев напишут жалкое подобие этой CMS.
Плюс далеко не всегда разработчику нужно решить задачу в минимально возможные сроки с максимально возможным качеством. Цель разработчика, как «существа экономического», вовсе не оптимизация расходов заказчика, а оптимизация своих доходов и далеко не всегда эти цели не вступают в прямой конфликт. Примеров множество, самые типичные — оплата по трудоемкости и «подсаживание на иглу поддержки». Почему-то многие заказчики не хотят платить за результат, а хотят за трудоёмкость (в строках кода ли её измерять, или в человеко-часах — не важно) и считают себя обманутыми, если с них возьмут 10 000 за часовую настройку бесплатной CMS и довольны, если им за 50 000 за пару месяцев напишут жалкое подобие этой CMS.
Я когда изобретаю велосипеды то чтоб не утруждать себя фантазиями просто копирую что-то, для интереса, так что не только в недостатке информации дело.
Я говорил об изобретении велосипедов в ходе решения реальных задач, а не «от скуки». То есть задача поставлена, можно решать её самому, а можно попытаться найти готовое решение. Во втором случае можно не найти готовых решений не потому, что их нет, а потому, например, что неправильно сформулировал запрос гуглу или гуглил только на русском или не добшёл до 11-й страницы результатов. Вот это я и имел в виду под недостатком информации — нет информации, где взять готовое решение.
Я очень благодарен своему прошлому, когда, еще программируя на php, я из-за своей юношеской амбициозности не приемлел чужого кода нигде в своих проектах. Хорший пример: нужно было написать многопоточный(как выразился заказчик) веб-краулер. Я, не зная про существование curl_multi, сначала реализовал эту многопоточность через системные вызовы, потом посредством pcntl_fork, а затем реализовал весь проект на неблокирующих сокетах — нехилый опыт принесло незнание одной маленькой технологии.
Ныне пишу на rails, где для всего и вся уже написаны плагины и гемы, но предыдущий опыт позволяет легко разбираться в сложных чужих либах, разрабатывать свои нетривиальные решения и участвовать в жизни опенсорца тем или иным путем.
Ныне пишу на rails, где для всего и вся уже написаны плагины и гемы, но предыдущий опыт позволяет легко разбираться в сложных чужих либах, разрабатывать свои нетривиальные решения и участвовать в жизни опенсорца тем или иным путем.
Что реально плохо — это не иметь собственного мнения, умение выбирать — вот что отличает человека от амоёбы, и «эффективного» программиста от хорошего. Вообще советы вроде «никогда не пишите велосипеды!» или «никогда не используйте шрифт с засечками!» или «никогда не переходите дорогу на красный свет!» — это вредные советы, которые не указывают на контекст, когда за тобой гонится армия зомби-мутантов можно светофор и не подождать, однако-же учат эти советы наизусть, и цитируют где-бы только не пришлось.
Плохо писать велосипед для проекта с бюджетом 2 бутерброда, который сдать нужно было вчера, а реализация требуемой задачи — годы работы, однако-же так бывает крайне редко, а вот «эффективное внедрение готового функционала» длящееся месяц, там где этот функционал — три строчки кода, которые еще и не работают — повсеместный случай.
Тут большинство евангелистов «антивелосипедов», учитывая специфику хабра — веб-программисты, делающие проекты под заказ, в составе фирмы или как частное лицо, в их работе это действительно зачастую верно, потому что это не критичная, разовая работа, в ней банально глупо изголяться, однако один шаг в сторону — и уже все далеко не так однозначно. Пользователи безусловно будут писать кипятком по ночам от радости, когда в критичном проекте будет захардкожена библиотека, разрабатываемая студентом Васей, или когда для скрипта гостевой книги будет использован фреймворк на 100 мегабайт кода, или когда клиенту предоставят отчет по проделанной работе, «три месяца мы писали код, и еще 2 года мы придумывали костыли для используемого нами микрофреймворка include „{$_GET['action']}.php“; но ведь он готовый уже!».
Всегда нужно иметь перед глазами контекст задачи, то что недопустимо для проекта длительностью две недели — жизненная необходимость для проекта длительностью два года, а без понимания этого глаз будут радовать проекты, подключающие на одной странице jquery, prototype, mootools и dojo разом, выкидывающие посередине исключение ezcomponents, обрабатываемое zend'ом и припиской снизу «powered by drupal».
Плохо писать велосипед для проекта с бюджетом 2 бутерброда, который сдать нужно было вчера, а реализация требуемой задачи — годы работы, однако-же так бывает крайне редко, а вот «эффективное внедрение готового функционала» длящееся месяц, там где этот функционал — три строчки кода, которые еще и не работают — повсеместный случай.
Тут большинство евангелистов «антивелосипедов», учитывая специфику хабра — веб-программисты, делающие проекты под заказ, в составе фирмы или как частное лицо, в их работе это действительно зачастую верно, потому что это не критичная, разовая работа, в ней банально глупо изголяться, однако один шаг в сторону — и уже все далеко не так однозначно. Пользователи безусловно будут писать кипятком по ночам от радости, когда в критичном проекте будет захардкожена библиотека, разрабатываемая студентом Васей, или когда для скрипта гостевой книги будет использован фреймворк на 100 мегабайт кода, или когда клиенту предоставят отчет по проделанной работе, «три месяца мы писали код, и еще 2 года мы придумывали костыли для используемого нами микрофреймворка include „{$_GET['action']}.php“; но ведь он готовый уже!».
Всегда нужно иметь перед глазами контекст задачи, то что недопустимо для проекта длительностью две недели — жизненная необходимость для проекта длительностью два года, а без понимания этого глаз будут радовать проекты, подключающие на одной странице jquery, prototype, mootools и dojo разом, выкидывающие посередине исключение ezcomponents, обрабатываемое zend'ом и припиской снизу «powered by drupal».
когда за тобой гонится армия зомби-мутантов можно светофор и не подождать
Согласен. Я никогда не жду в таких ситуациях.
Что реально плохо — это не иметь собственного мнения, умение выбирать — вот что отличает человека от амёбы, и «эффективного» программиста от хорошего.
В первый раз в жизни нажал звездочку рядом с комментарием, образно говоря.
Поддерживаю и статью, и этот комментарий. :) От себя хочу добавить, что очень многие существующие сегодня полезные библиотеки и фреймворки тоже начинались в виде велосипедов. Всё зависит от контекста — если у человека достаточно знаний, опыта, энтузиазма и ресурсов, чтобы создать что-то, что лучше существующего аналога, то почему бы и нет?
LoneCat: «Что реально плохо — это не иметь собственного мнения, умение выбирать — вот что отличает человека от амоёбы, и «эффективного» программиста от хорошего. Вообще советы вроде «никогда не пишите велосипеды!» или «никогда не используйте шрифт с засечками!» или «никогда не переходите дорогу на красный свет!» — это вредные советы, которые не указывают на контекст...»
Совершенно верно, когда нечто воспринимается строго и без учёта контекста, то это чаще всего догматизм.
Что касается темы, то, например, когда я решаю трудную задачу перечислительной комбинаторики, то совершенно недопустимо, чтобы туда попал чей-то готовый код, так как этот код разрабатывался либо для универсальных случаев (например, у меня алгоритмы stl в среднем работают в 10 раз медленнее кода, написанного специально для одной задачи), либо для других случаев, которые к конкретной задаче не подходят. Кроме того, есть ещё сферы программирования, где почти нет готового кода. Например, параллельное программирование. Далеко не все алгоритмы есть в параллельной реализации, поэтому тут приходится работать только руками.
Пользоваться же готовым кодом удобнее, когда пишешь ПО на заказ или делаешь прототип программы: пользователю главное быстро и надёжно. И хорошо, когда надежный код за тебя написали и отладили 20 других разработчиков, которые этим уже полжизни занимаются. Кроме того, есть программисты, которые не изучали алгоритмы и структуры данных, у них другого выхода кроме использования чужого кода нет. С другой стороны, я вот изучал алгоритмы, но едва ли понимаю, как написать на php надежный и удобный форум или блог – значит беру готовый, за надёжность которого отвечает специально обученная команда.
То есть не следует поднимать по этой теме очередной холивар.
Совершенно верно, когда нечто воспринимается строго и без учёта контекста, то это чаще всего догматизм.
Что касается темы, то, например, когда я решаю трудную задачу перечислительной комбинаторики, то совершенно недопустимо, чтобы туда попал чей-то готовый код, так как этот код разрабатывался либо для универсальных случаев (например, у меня алгоритмы stl в среднем работают в 10 раз медленнее кода, написанного специально для одной задачи), либо для других случаев, которые к конкретной задаче не подходят. Кроме того, есть ещё сферы программирования, где почти нет готового кода. Например, параллельное программирование. Далеко не все алгоритмы есть в параллельной реализации, поэтому тут приходится работать только руками.
Пользоваться же готовым кодом удобнее, когда пишешь ПО на заказ или делаешь прототип программы: пользователю главное быстро и надёжно. И хорошо, когда надежный код за тебя написали и отладили 20 других разработчиков, которые этим уже полжизни занимаются. Кроме того, есть программисты, которые не изучали алгоритмы и структуры данных, у них другого выхода кроме использования чужого кода нет. С другой стороны, я вот изучал алгоритмы, но едва ли понимаю, как написать на php надежный и удобный форум или блог – значит беру готовый, за надёжность которого отвечает специально обученная команда.
То есть не следует поднимать по этой теме очередной холивар.
Пост изобретателей велосипедов.
А если серьезно, то такие «велосипедисты» — очень большая проблема в реальных проектах. Они тратят огромное количество времени и средств заказчика на реализацию того, что уже было написано до них — просто потому, что либо не знают о существовании уже готового решения, либо буквально отвергают чужой код и идеи. Низкое качество продукта, перенос сроков и постоянное переписывание кода с нуля — вот самые болезненные признаки таких людей.
А если серьезно, то такие «велосипедисты» — очень большая проблема в реальных проектах. Они тратят огромное количество времени и средств заказчика на реализацию того, что уже было написано до них — просто потому, что либо не знают о существовании уже готового решения, либо буквально отвергают чужой код и идеи. Низкое качество продукта, перенос сроков и постоянное переписывание кода с нуля — вот самые болезненные признаки таких людей.
Выше я написал, что оптимизация затрат заказчика вовсе не основная цель многих разработчиков (хоть фрилансеров-одиночек, хоть монстров типа MS). И зачастую заказчики сами в этом виноваты, т. к. не хотят платить за результат, им подавай смету и т. п., ну и приходится всеми правдами и неправдами эту смету «раздувать», а самый простой способ (если не опускаться до прямого обмана) — самостоятельная реализация какого-то функционала, причём разумные причины его самостоятельной реализации всегда (почти) можно найти.
Положив руку на сердце, вы предпочтёте взять 500 (условно) рублей за час настройки готового продукта, или 960 000 (500 рублей*8 часов*20 дней*12 месяцев) за год разработки нового с аналогичным, а то и меньшим, функционалом? Особенно учитывая, что неизвестно когда следующий заказчик будет, а этот за час работы вам 960 000 явно не заплатит, так как ему нужно обоснование цены.
Положив руку на сердце, вы предпочтёте взять 500 (условно) рублей за час настройки готового продукта, или 960 000 (500 рублей*8 часов*20 дней*12 месяцев) за год разработки нового с аналогичным, а то и меньшим, функционалом? Особенно учитывая, что неизвестно когда следующий заказчик будет, а этот за час работы вам 960 000 явно не заплатит, так как ему нужно обоснование цены.
Я тот еще велосипедист, потому что в готовом коде как правило есть серьезные проблемы, которые всплывают слишком поздно.
Кроме того, мне нравится чувствовать как работает код, что невозможно, если половина кода скрыта от меня в готовых библиотеках чужого авторства.
Однако, я считаю, что решать всегда должен заказчик. Если заказчик говорит, что надо закончить «вчера», то конечно, не может быть и речи о велосипедах. Если же время есть и заранее видны критичные места кода, то имеет смысл написать их самому, не пользуясь готовыми решениями.
Кроме того, мне нравится чувствовать как работает код, что невозможно, если половина кода скрыта от меня в готовых библиотеках чужого авторства.
Однако, я считаю, что решать всегда должен заказчик. Если заказчик говорит, что надо закончить «вчера», то конечно, не может быть и речи о велосипедах. Если же время есть и заранее видны критичные места кода, то имеет смысл написать их самому, не пользуясь готовыми решениями.
Изобретение велосипедов при работе на дядю или на клиента, может стоить им факапнутого проекта, а вам работы :) А так, да, полезно поизобретать, особенно, низкоуровневые штуки, помогает писать более качественный высокоуровневый код.
Я бы даже сказал больше, что если вы не знаете чем заняться, просмотрите просто объявления вакансий, потом отпишите на интересные попросив прислать «Тестовые Задания», порой бывают очень и очень интересные задачи!
Следует разделять упражнения и эксперименты и собственно работу.
Вообще фразы «Не изобретайте велосипед!» и «Не изобретайте колесо!» придумали люди, которые ни разу не видели историю ни первого, ни второго!!!
Современный велосипед, по сравнению со своим предком, имеет общего пожалуй только наличие рамы и колёс.
А современное колесо «с шипованой резиной и накаченное азотом» много-ли общего имеет кроме округлой формы со своим предком, которым был просто тупо кусок бревна с дыркой для оси?!
Так что изобретение как велосипеда, так и колеса — не самый плохой тип занятия: если всем кажется, что лучше чего-то и быть не может, то это не значит, что это что-то дошло до своего идеала!
Современный велосипед, по сравнению со своим предком, имеет общего пожалуй только наличие рамы и колёс.
А современное колесо «с шипованой резиной и накаченное азотом» много-ли общего имеет кроме округлой формы со своим предком, которым был просто тупо кусок бревна с дыркой для оси?!
Так что изобретение как велосипеда, так и колеса — не самый плохой тип занятия: если всем кажется, что лучше чего-то и быть не может, то это не значит, что это что-то дошло до своего идеала!
долгие годы до того как начал работать специально изобретал велосипеды. Отсусвие инета это дело ускоряло.
Зато на работе очень пригодилось. Особенно при миграциях.
И теже самые массивы, строки и деревья — до сих пор мои — на самом деле они лучше std либы :)
А самое главное — создавались под задачу!(10 лет назад, никакого cvs даже, часть программы на atl часть на std. Надо мигрировать под линукс)
Зато на работе очень пригодилось. Особенно при миграциях.
И теже самые массивы, строки и деревья — до сих пор мои — на самом деле они лучше std либы :)
А самое главное — создавались под задачу!(10 лет назад, никакого cvs даже, часть программы на atl часть на std. Надо мигрировать под линукс)
Изобретать велосипед, даже если он с квадратными колесами — хорошо и полезно. Но только, если есть кто-то рядом, кто может тебе сказать: «Эй, да о же с квадратными колесами! На нем далеко не уедешь.» А то можно вечно изобретать свои решения, узнав о своих ошибках слишком поздно.
Кстати да, важное замечание про кого-то рядом. Одно дело, когда велосипед во всех отношениях будет заведомо хуже готовых продуктов, другое — когда он хоть в чём-то важном (скорость, удобство использования, технологичность и т. п.) их превосходит. Но определить первую ситуацию чаще всего может только тот, кто знает плюсы и минусы этих конкурентов и способен разглядеть идёшь ты по их стопам или действительно нашёл оригинальный и, возможно, более эффективный способ решения уже решенной задачи.
«Мы построим свой Луна-парк, с блекджеком и шлюхами!» Даже великий Бендер — за велосипеды :-)
Изобретать велосипед всегда полезно, а иногда даже нужно.
Помните недавно на Хабре был пост про захват движения для 3Д за счет маркеров и камер? Я до этой идеи додумался еще несколько лет назад, но я не стал ее развивать.Почему? Да потому что мне и в голову не приходило, что до такой простой и очевидной идеи никто ранее не додумался.
И вообще. В США самый большой процент «велосипедистов», и одновременно самый большой процент изобретений сейчас. Это не просто так.
Помните недавно на Хабре был пост про захват движения для 3Д за счет маркеров и камер? Я до этой идеи додумался еще несколько лет назад, но я не стал ее развивать.Почему? Да потому что мне и в голову не приходило, что до такой простой и очевидной идеи никто ранее не додумался.
И вообще. В США самый большой процент «велосипедистов», и одновременно самый большой процент изобретений сейчас. Это не просто так.
Как всегда, важен компромисс. Электронщики не делают электронные компоненты вроде резисторов, конденсаторов — используют готовые «черные ящики», а из них уже собирают нужное устройство. Так же и программисты обычно не паяют свой проц с «сапёром» и массажистками, просто используют готовый и его программируют. И директора не пишут код, потому что есть этакие «чёрные ящики» — программисты. На входе — задача и деньги, на выходе — код.
Конечно, я утрирую, но мне компромиссы видятся именно так. Поэтому я не стану разрабатывать свою STL или свой кошерный vector, свою сортировку: всё уже написано как раз для того, чтобы не пришлось писать мне. Если я такое и сделаю, то пользоваться этим скорее всего не стану — получил опыт, выкинул поделку на помойку. Написал лучше — отлично, можно использовать, и то не всегда (совместимость и другие страшные слова никто не отменял).
Конечно, я утрирую, но мне компромиссы видятся именно так. Поэтому я не стану разрабатывать свою STL или свой кошерный vector, свою сортировку: всё уже написано как раз для того, чтобы не пришлось писать мне. Если я такое и сделаю, то пользоваться этим скорее всего не стану — получил опыт, выкинул поделку на помойку. Написал лучше — отлично, можно использовать, и то не всегда (совместимость и другие страшные слова никто не отменял).
Невозможно изучить всё.
Человек, который знает «всё» (читай, может реализовать всё, чем пользуется) — гипергуру, и таких в нашем слое реальности не водится.
Человек, который знает «всё» (читай, может реализовать всё, чем пользуется) — гипергуру, и таких в нашем слое реальности не водится.
Напомнило «для каждого афоризма можно другой, противоположный по смыслу и равный по значению».
То говорят, что изобретать велосипеды это глупо, а вот теперь наоборот. Итак понятно, что пока ты молодой — лучше изобретай велосипеды. А вот потом для этого нужны время x деньги или уверенность (вера), что твой велосипед более инновационный чем другие.
То говорят, что изобретать велосипеды это глупо, а вот теперь наоборот. Итак понятно, что пока ты молодой — лучше изобретай велосипеды. А вот потом для этого нужны время x деньги или уверенность (вера), что твой велосипед более инновационный чем другие.
Долго читал цитату. Раза с пятого понял, о чём речь. Знаки препинания кошмарны:(
Мне кажется, что многие несогласные с заметкой просто путают два вида пользы:
Для личного роста программиста страшно полезно изобретать велосипеды. Более того — пользоваться этими велосипедами в реальных коммерческих проектов. Создать свою систему сборки, свои умные указатели — это отличный способ сильно вырасти.
Для пользы команды и тем более для пользы предприятия велосипеды — это жуть, зло и отстой. Велосипеды не документируются так как готовые решения. Они очень редко обладают универсальностью готовых решений. Если создатель велика смог заставить своих коллег пользоваться своим детищем — он становится Владыкой Кода его уход влечет огромные потери.
Хочешь многое узнать, с легкостью проходить собеседования с самыми дурацкими заковыристыми вопросами, повысить свою квалификацию — пиши велосипеды.
Пишешь программу не в одиночку, заботишься об успешности проекта, хочешь, чтобы твои соратники могли обходиться без тебя — используй готовые решения.
Для личного роста программиста страшно полезно изобретать велосипеды. Более того — пользоваться этими велосипедами в реальных коммерческих проектов. Создать свою систему сборки, свои умные указатели — это отличный способ сильно вырасти.
Для пользы команды и тем более для пользы предприятия велосипеды — это жуть, зло и отстой. Велосипеды не документируются так как готовые решения. Они очень редко обладают универсальностью готовых решений. Если создатель велика смог заставить своих коллег пользоваться своим детищем — он становится Владыкой Кода его уход влечет огромные потери.
Хочешь многое узнать, с легкостью проходить собеседования с самыми дурацкими заковыристыми вопросами, повысить свою квалификацию — пиши велосипеды.
Пишешь программу не в одиночку, заботишься об успешности проекта, хочешь, чтобы твои соратники могли обходиться без тебя — используй готовые решения.
Ну насчет «Владыки Кода» — это не всегда так. Если код открытый и тебе понятен смысл его работы — ты просто используешь его и для этого уже не нужен автор. Если нужно доработать этот код — опять-же при открытости и понятности — не вижу особых проблем.
А к данной статье я бы еще добавил пожелание периодически копаться в чужих текстах программ. Тоже в плане самообразования. Грамотно написанный код может быть неплохим учебным пособием и источником новых приемов программирования…
Ну а разбирая плохой код (если нужда заставила) учишься, как не надо делать :)
А к данной статье я бы еще добавил пожелание периодически копаться в чужих текстах программ. Тоже в плане самообразования. Грамотно написанный код может быть неплохим учебным пособием и источником новых приемов программирования…
Ну а разбирая плохой код (если нужда заставила) учишься, как не надо делать :)
Ещё бы знать заранее, какой код хороший, а какой нет :) Популярность и долгое существование продукта критерием служить врядли могут.
Для меня основной критерий — удовлетворяет ли меня результат работы этого кода. Если в основном удовлетворяет, значит хороший.
Ну а когда лезу в дебри этого кода, смотрю, как бы это сделал я. Если удается сделать более эффективный код, значит исходный не очень удачен, а если «вау! я бы до этого не додумался!» — значит в данном вопросе автор сильнее меня и у него не стыдно поучиться. Изучение чужого опыта и чужих ошибок — более быстрый способ роста, чем набивать на том-же месте свои шишки :) Шрамы, даже виртуальные, украшают мужчину, когда их количество разумно. Когда их слишком много — получается уродство.
Ну а когда лезу в дебри этого кода, смотрю, как бы это сделал я. Если удается сделать более эффективный код, значит исходный не очень удачен, а если «вау! я бы до этого не додумался!» — значит в данном вопросе автор сильнее меня и у него не стыдно поучиться. Изучение чужого опыта и чужих ошибок — более быстрый способ роста, чем набивать на том-же месте свои шишки :) Шрамы, даже виртуальные, украшают мужчину, когда их количество разумно. Когда их слишком много — получается уродство.
Я за разработку собственных колес.
Но в жизни бывают разные ситуации. Иногда пишу свое, хотя что-то уже есть, иногда использую готовые решения. В каждом случае решаю из ситуации. Иногда работа стороннего продукта меня не устраивает по каким-то причинам (как правило — большая ресурсоемкость, медленная скорость работы), тогда пытаюсь найти свое решение. Иногда не заморачиваюсь и беру готовое — когда нужно быстро получить и оценить результат или самостоятельно ваять слишком долго и дорого. В процессе жизни кода, бывает, переделываю отдельные участки, когда с ростом нагрузок становятся более заметны узкие места или просто вижу способ улучшить результат.
В общем правда, как обычно, где-то посередине. Но в любом случае, понимание, как работает используемая вами сторонняя программа позволяет добиться лучших результатов. Иногда для этого совсем не обязательно параллельно писать свое. Достаточно хорошенько подумать, как это может крутиться внутри.
Но в жизни бывают разные ситуации. Иногда пишу свое, хотя что-то уже есть, иногда использую готовые решения. В каждом случае решаю из ситуации. Иногда работа стороннего продукта меня не устраивает по каким-то причинам (как правило — большая ресурсоемкость, медленная скорость работы), тогда пытаюсь найти свое решение. Иногда не заморачиваюсь и беру готовое — когда нужно быстро получить и оценить результат или самостоятельно ваять слишком долго и дорого. В процессе жизни кода, бывает, переделываю отдельные участки, когда с ростом нагрузок становятся более заметны узкие места или просто вижу способ улучшить результат.
В общем правда, как обычно, где-то посередине. Но в любом случае, понимание, как работает используемая вами сторонняя программа позволяет добиться лучших результатов. Иногда для этого совсем не обязательно параллельно писать свое. Достаточно хорошенько подумать, как это может крутиться внутри.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изобретайте велосипед часто