Полезно ли долго (и вообще) «велосипедить» в программировании?
Простой 1 комментарий
Всегда есть выбор, либо пытаться написать свое, потом бросить и взять готовое, проверенное решение.
Либо разобраться как устроены готовые решения путем чтения исходников (что является оч. полезным навыком) и написать свое с нужным функционалом.
Есть ещё вариант, что готового решения нет и тогда пригодятся навыки, которые вы получите в процессе велосипедостроения, а конкретно навыки решения задач, построения алгоритмов, планирования и проектирования.
Но это если обстоятельно подходить. С чувством, с толком, с расстановкой.
В любом случае пока ваше время ничего/недорого не стоит, вы можете себе позволить все.
Рано или поздно эмпирическим путем придете к выводу что бессмысленно тратить свое время на велосипеды, даже в образовательных целях. Намного выгоднее(эффективнее) разобраться в «предмете» по имеющейся документации (понять как работает/устроено).
Почему-то при обучении программированию
Да это так, при обучении программированию всегда говорят не изобретайте велосипеды пользуйтесь готовыми проверенными решениями (изучайте/пользуйтесь библиотеки/ами). Потому что до вас это уже сделали и потратили кучу времени, а вы можете потратить свое время более эффективно, позволить себе мыслить на более высоком уровне абстракции. Делать больше, тратя меньше.
Изобретайте велосипеды: почему это должен делать каждый разработчик
Сказать программисту, что уже есть библиотека, делающая Х, — это то же самое, что сказать музыканту, что уже есть песня про любовь.
Созданием велосипедов в программировании (и не только) называют решение проблемы, которая уже давно решена. Например, разработку сайта на чистом языке вместо использования фреймворков.
Многие считают это занятие чем-то неэффективным: оно отнимает время, которое можно потратить на что-то стоящее, вместо того чтобы делать то, что уже сделали за тебя.
Я с этим не согласен, потому что очень часто проблему можно решить более эффективным способом.
Важно!Всё это касается ваших личных проектов или проектов, в которых кодом занимаетесь только вы. Работая в команде, используйте выбранные готовые инструменты.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Чем опасен отказ от велосипедов
Больше всех готовые решения любят разработчики на JavaScript — они чаще других пользуются фреймворками и библиотеками.
Доходит даже до того, что они называют себя не JS-разработчиками, а React-, Angular-, Vue-разработчиками и так далее. В принципе, в этом нет ничего плохого — работодателю проще найти человека, который разбирается в том, что уже используется в его проекте. Но тут вас подстерегает первая проблема.
Поверхностные знания
Многие разработчики на фреймворках зачастую плохо знают сам язык и как он вообще устроен. В случае с JS многих пугает работа с DOM — они не знают, что это и зачем нужно. А это, между прочим, самое главное в JavaScript.
JS был одним из первых языков, которые я изучал. На тот момент он показался мне сложным, а вот jQuery я освоил достаточно быстро. То есть я смог разобраться с фреймворком, не зная языка, — мне это было не нужно, потому что я и без него справлялся.
Другой яркий пример связан с PHP: однажды мне пришлось переделывать проект за другим разработчиком, который использовал библиотеку для работы с базой данных.
Автор библиотеки обещал простую и безопасную отправку запросов, но, изучив документацию, я пришёл к выводу, что ничего простого тут нет. Было лишь обилие методов с названиями, по котором сложно было понять, что они делают, и странная система плейсхолдеров.
К тому же в PHP уже есть необходимый функционал, который действительно прост и безопасен, — PDO. Знай об этом предыдущий разработчик или автор библиотеки — мне не пришлось бы мучиться.
Как тут поможет велосипед
Так как в веб-разработке постоянно приходится иметь дело с базами данных, я написал свой велосипед поверх PDO. В результате я лучше разобрался в том, как устроены базы данных и запросы к ним, и написал то решение, которое будет удобно мне и отлично впишется в мои проекты.
Это был статичный метод, который принимает запрос и массив с параметрами, а потом возвращает либо массив со строками из таблицы, либо номер вставленной строки, либо просто булево значение — в зависимости от того, какой запрос был отправлен.
Пересматривая его сейчас, я вижу, что он не идеален, но само его написание было для меня полезным опытом. Не говоря уже о том, что он ускорил мою работу над проектами, когда я ещё писал на PHP.
Сейчас, если мне нужно решить небольшую проблему, я стараюсь писать собственные велосипеды, используя возможности языка.
Плохая оптимизация
Многие фреймворки и библиотеки, вроде того же jQuery, снижают скорость работы сайта и занимают место на сервере. Многие так зависят от разных подключаемых скриптов, что их веб-страницы начинают выглядеть так:
Индустрия it-велосипедов
Введение
Я точно не могу сказать, что заставило написать этот пост — может быть мой накопившийся опыт и принадлежность к php-программистам, которые, всемирно известны своим быдлокодом или недавний пост, в котором автор описывает проблему, появившуюся в его велосипеде и связанную с глобальными переменными в различных модулях.
Почитав комментарии к которому, мне стало уж совсем плохо… Я просто не понимал как люди не видят сути проблемы, а видят только лишь ее последствия — проблему в велосипеде. А суть то заключается в том, что у автора напрочь отсутствуют какие-либо познания в «велосипедостроении». И что самое страшное — эти знания отсутствуют не у одного него. А практически у всей массы изобретателей которые сами велосипеды видели только на картинках.
А если взять в расчет то, что они не хотят даже посмотреть на другие велосипеды…
Часть первая. История одного велосипедиста
Я думаю начать нужно с того, что следует мысленно вернутся к той планке опыта молодого велосипедостроителя, на которой я впервые столкнулся с трудностями. На полтора года назад — в снежную зимнюю ночь и мою комнату, освещенную 19-ти дюймовым элт-монитором, тихой депрессивной музыке, доносившейся из недр старого советского проигрывателя пластинок и собственно мне — сидящим на полу и высекающему медиатором на не подключенном семиструнном Ibanez’е.
В то время я был обычным студентом, учившимся на последнем курсе по специальности 230101, которому до преддипломной практики оставалось чуть больше одного месяца, а дальше… одна единственная черта — защита диплома, перешагнув которую я буду выкинут в совершенно иной мир, который по сложности, размерам, жестокости и количеству возможностей реализовать себя, едва ли сравнится с тем, в котором я пребывал. Со знаниями едва ли немногим превышающие те, что я получил еще в школе, да и с полным непониманием как их можно применять в реальной жизни.
А еще я был пыхарем и быдлокодером в своем самом ужасном проявлении — сорцы написанные мною в столбик представляли собой смесь из четырех языков(html, php, sql и javascript) с использованием функций и классов, разбросанный по различным файлам со всеми видами уязвимостей, которые только могут существовать. Но несмотря на это я чувствовал, что мне очень хочется развиваться дальше в этом направлении и совершенствовать свои навыки как программиста.
Поэтому я на отлично сдал диплом, тема которого звучала примерно так «CMS с использованием технологии AJAX», и так же как и многие пыхари, решил создавать свой велосипед. Я был полон энтузиазма, и мне не терпелось наконец-то собрать воедино все свои знания о современном велосипедостроении: парадигме объектно ориентированном программирования, технологии ajax, блочной верстки с использованием CSS и даже связку xml с xslt.
Это сейчас я понимаю, что тогда я ничего не знал о велосипедостроении. Все мои знания о двухколесных транспортных средствах ограничивались XIX-ым веком. Конечно они уже не были модификацией дрезины Макмилланом, который по сути и создал первый в мире велосипед в нашем понимании — с седлом и рулем, то они явно были не прогрессивнее детища Пьера Лалмана, который придумал оснастить велосипед педалями. На переднем колесе.
 |  |  |
| Дрезина Макмиллана | велосипед Пьера Лалмана | Идеальный велосипед в понимании среднестатистического пыхаря |
Но тогда мне казалось, что я изобретаю, современный mtb-хардтейл на усиленной дёртовой раме, гидравлическими дисковыми тормозами, мультиспидом и достаточно легким весом. Что бы можно себя комфортно чувствовать как в кросс-кантри, не беспокоясь за то, что можно где-нибудь застрять посредине леса. Так и на улицах города, занимаясь стритом, даже не думая о том, что он может сложится под тобой при неудачном прыжке с лестницы.
 |
| mtb-хардтейл |
Этому способствовало еще и мое окружение, состоящее из таких же пыхарей, разных возрастов. У некоторых из них был опыт гораздо больший нежели у меня. И все они твердили одно и тоже: «Надо писать свою cms», «Зачем мне пользоваться чужим фреймворком если я способен написать его сам» и «Веб — сомнительное место для объектно ориентированного подхода, где время жизни скрипта не больше чем одна пятая секунды».
Я был глуп, наивен и поэтому их слушал. И писал. Поэтому неудивительно что мой первый велосипед был похож на инвалидную коляску — некоторые детали в ней сначала прибивались друг к другу с помощью гвоздей, а уже после приваривались, образуя монолитную конструкцию, которой все ни по чем… но она все таки ездила. И было уже неважно, что для поворота налево, нам необходимо убрать ноги с педалей, приподнять руль и только потом поворачивать. Что передний амортизатор был заблокирован в одном положении и после езды по кочкам можно было ощущать себя как шахтером, отработавшим восемь часов с отбивным молотком. Что пробив камеру, если конечно такое вообще могло когда-нибудь случится с металлической камерой, — нам пришлось бы заменять пол велосипеда, орудуя молотком, ножовкой и газосварочным аппаратом.
Но я учился. И упорно следовал этим бездарным указаниями. Пиши свой велосипед крутилось в моей голове. ПИШИ! Я и писал. Опыта конечно у меня становилось все больше — картинки с различными велосипедами встречались все чаще и чаще, они становились больше, поэтому на них можно было разглядеть и некоторые детали. Да и узнал я о такой штуке как шаблоны проектирования.
На тот момент я считал их чем-то таким посланным свыше, давно решенными проблемами всего человечества, которыми не пользуется только последний дурак. А в тот момент я, глядя на себя со стороны, начинал считать себя именно дураком — я пишу, стараюсь, трачу свое время а у меня ничего не получается. Прогресса нет.
Сейчас то я понимаю, что трактовал эти шаблоны не совсем правильно — я воспринимал их как серебряную пулю, которая в идеале решает все проблемы, с которыми сталкивались люди до меня. И владея ей, я с легкостью мог создавать сложные приложения за очень короткий срок, даже не думая о том, что смогу наступить на неизвестные грабли- все уже решено до меня. Это до меня люди наступали на грабли. До меня они больно бились головой о стены, пока не нашли правильный путь. А мне стоит только лишь пройтись по нему — вот и все.
И я начал писать с использованием их. А знал я их порядка 15 штук. Вы знаете что такое эффект второй системы? Если нет, то представьте себе bmx с 20 дюймовыми шипованными колесами, рулем от шоссейного велосипеда, двумя амортизаторами, четырьмя гидравлическими тормозами по два на каждое колесо (дисковые и v-brake), поддерживающими боковыми колесами (для тех кто только учится ездить), тремя сиденьями, бардачком для инструментов, коляски сзади, планетарным механизмом переключения передач, контактными педалями, четырьмя фарами работающих от автомобильного аккумулятора, зеркалами заднего вида и ремнем безопасности.
 обыкновенный bmx |
А если это все заставить держатся на одном огромном объектно-ориентированном гвозде — Registry, благодаря которому мы точно не можем сказать сможет ли ездить этот велосипед, если мы захотим снять один из фонарей… то получим точную копию созданной мной системы…
Часть вторая. Продолжение
Я не буду удивлен если многие программисты увидят в этой истории самих себя. Тем более я не удивлюсь, если они увидят себя в самом начале этого пути — в окружении пыхарей, которые советуют изобретать, изобретать и еще раз изобретать. Забывая о том, что для того, что бы создать что-то новое. Необходимо понимать как работает. Умные люди этот момент понимают.
Я даже приму как должное если вы дочитав до этой строчки ловите себя на мысли о том, что я вот с высоты своего опыта, который вы наверное уже поставили под сомнение, пытаюсь сказать «Изобретение велосипедов — зло». Пользуйтесь существующими. Нет. Тогда мы вернемся опять к уровню обезьян, а может быть даже и обратно в море.
Но давайте все разложим по полочкам.
Часть третья. Полочки
И так у нас существует небольшая проблема (мы положим ее на первую полочку), которая подогревается другими проблемами (их мы сложим на второй полочке), и которые в свою очередь порождают третий вид самых ужасных проблем, которые только могут существовать. Их мы положим на самую низкую полочку.
А вот на последней полке у нас лежат самые интересные проблемы, о которых я здесь и распинаюсь. А именно о том, что люди, которые сами ничего не смыслят в велосипедостроении начинают поучать других, ведут их по самой неудачной тернистой тропе, по которой и шли когда-то сами, заставляя наступать на те же самые грабли на которые наступили они сами. Тропе изобретения велосипедов-мутантов.
И вот я только сейчас понял, что разложив все эти проблемы по полочкам, как-то легче и не становится. Скорее даже наоборот, еще больше понимаешь что механизм давно уже запущен и отлажено работает, порождая на свет все новых пыхарей, создающих тоннами быдлокод и считающих что лучше написать все самому, с нуля. Хотя вот интересно, что это они сами для себя домов не строят, одежду не шьют, деньги свои собственные не печают. Да почему они вообще пользуются программным обеспечением если в силах написать все сами и лучше!
Но мне все таки хочется надеется что выход из этой привычной всем системы существует. По крайней мере для себя я его нашел. И мне даже не пришлось изучать другой язык программирования велосипедов.
Часть четвертая. Начинаем с нуля.
И только после того, как я во второй раз осознал, что я делаю что-то не так. Я решил посмотреть на проблему с другой стороны. Просто сесть и подумать над тем что же именно я делаю не так. Через некоторое время я увидел ответ — я знал как можно решить проблему, но не знал почему её следует решать именно так. У меня банально была очень слаба теоретическая база.
И я начал учится. С нуля. По два-три часа в день, которые я нашел благодаря тому, что стал уделять меньше времени всему, что меня окружало — друзьям, любимым, музыке. И за это время я заново для себя открыл такие понятия как абстракция, полиморфизм. Я наконец-таки понял зачем нужно наследование, когда его следует применять, а когда вместо него необходимо использовать инкапсуляцию. Я заново открыл для себя объектно ориентированное программирование.
До меня дошло что то, что написано в учебниках годится только для написания глупых оторванных от реальности примеров с яблоками и геометрическими фигурами. Я понял что объект — это какая сущность, она не привязана к реальным объектам. У нее есть свое состояние, обязательства перед другими сущностями и потребности в других объектах. Это так просто. Это написано в каждом учебнике по программированию. Первыми строчками. Они дают нам понимание что такое объектно ориентированное программирование, а потом забирают его примерами с квадратом наследованным от прямоугольника. И человек привыкает считать что объект — это что-то из реального мира. А после вопит «наплодили тут объектов», когда встречает грамотный объектно ориентированный код. Ему приходится ломать свое понимание этого подхода. Так же как сломал его и я.
До меня наконец-то дошла суть шаблонов проектирования, которые действительно стали для меня шаблонами, а не серебряной пулей, решающей все возможные проблемы. Они нам не указывают как нужно писать. А всего лишь подсказывают. Теперь рефакторинг для меня не означал переписывание заново какого-либо куска кода не трогая все остальные.
Во многом благодаря различным книгам по проектированию (которые легко читаются во время поездки в метро) и копанию в чужих велосипедах (zend, ci, symfony), я понял, что не всегда использование планетарного механизма переключения передач, который идеально подходит для городских прогулок (который я могу собрать и разобрать с утра, с закрытыми глазами и жутким похмельем), гораздо лучше обычного механизма с кучей звезд. Я даже понял, что иногда он вообще не нужен. Зачем bmx’у с десяток скоростей. Чтоб банники дергать на скамейку было проще? Или занимала флетлендом (по сути танцы с велосипедом).
Нам не всегда требуется проектировать тяжелый двух подвес, который идеально подойдет для фрирайда, но так же ненадо и вдаватся в другую грань — создавая невероятно легкие шоссейники, на которых можно ездить с нереальной скоростью, но только по идеально гладкой поверхности.
Я каждый день пытался научится чему-то новому. Писал и по несколько раз переписывал код в песочнице, в которой происходило мое первое практическое знакомство с компонентами из которых должен состоять велосипед. Второго знакомства или не было, или оно уже происходило в реальных проектах. Где я видел, что эта штука работает. И именно так как я себе и представлял. Сейчас из них можно уже собрать неплохой велосипед*, который будет практически полностью копировать ZF. Но как раз поэтому я и не вижу в этом смысла. Он даже не появится тогда, когда я столкнусь с условиями в которых ZF станет камнем тянущем весь проект на дно (из за своей низкой производительности). Я понимаю, что там уже будут эффективно работать совершенно другие подходы к написанию кода.
Заключение
В заключение хотел бы извинится перед теми, кто считает, что я его задел, а среди таких я думаю наберется достаточное количество грамотных разработчиков со своими довольно грамотными велосипедами, на которых был поднят не один хороший проект. Речь шла все таки не о вас. Вас пыхарями назвать нельзя 
Сейчас это уже не так. Сейчас он уже собран во один единственный «чертеж», в котором я оставил только лишь интерфейсы для каждого компонента вместе с эксепшнами. Безжалостно удалив все то, что когда-то было написано и лишив старого названия(brix framework), которое, думаю, только сейчас будет наиболее точно отражать его суть: brix от того, что briks (кирпичи), а не мера массового отношения растворённой сахарозы, как говорит нам википедия.
Нужно ли программисту изобретать велосипед?
Простой 4 комментария
часто готовые решения покрывают потребности. но так же часто они это делают не самым оптимальным образом, или не совсем так, как это нужно конкретно мне для решения конкретно этой задачи.
Представьте себе, у меня в одной коммерческой программе есть велосипед и чужая библиотека, занимающиеся одним и тем же, доступом к XLSX.
В одном месте пользователи иногда скармливают программе огромный XLSX размером мегабайт этак в 20, что соответствует ≈100M памяти, если развернуть в структуры данных, >130M — если сериализовать в XML, и добрых полгига — если этот XML разобрать рекордной библиотекой, а ведь в той XLSX-библиотеке, которую мы купили, ничего рекордного не было. На x86 не хватало памяти ни на что, на x64 тормозило адски. В общем, сделал потоковый разбор XML с пространствами имён «из коробки» и предельно простой разбор XLSX без стилей, без картинок и диаграмм, без сохранения — этот XLSX грузило ≈3 с, из которых более трёх лет назад
Создавать велосипед можно в учебных целях. Еще один вариант, если нам надо что-то простое и его проще продублировать чем тащить дополнительную библиотеку в проект, в которой еще куча вещей.
По умолчанию лучше пользоваться готовеньким, если оно есть и в данном слуае удобно. Оно уже протестировано и народ прошел по граблям и знает тропинки. И не только народ в вашей конторе, но и за ее пределами.
Есть учебные велосипеды. Вы его сделали чтобы понять, как это всё работает. Я сам пару месяцев назад написал нейросетку, просто чтобы понять метод обратного распространения ошибки. Сетка работала весьма тормознуто, но работала же. Но тут речь о том, чтобы сделать, посмотреть и выкинуть.
В этом бизнесе выживают либо те, кто специализируется на очень больших и серьёзных проектах (вот только для этого нужно иметь имя и неплохой штат), либо те, кто собирают сайт как конструктор в течении пары дней.
7 типичных ошибок неопытных программистов
Сколько люди будут учиться программированию, столько будут совершать одни и те же ошибки. Существуют грабли, на которые просто невозможно не наступить. Тем не менее н ебольшая ошибка в начале разработки может обернуться сильной головной болью для программиста и его коллег в будущем. Х очется верить, что читатели этой статьи смогут сократить количество неверно принятых решений в ходе разработки программ до минимума.
Неумение кататься на велосипедах
Использование неподходящих средств разработки
Вопросы, на которые уже 100 раз ответили
Перед тем, как начать спрашивать что-либо на форумах и в сообществах, просто поищите ответ на свой вопрос. Если Вы начинающий программист, то наверняка кто-то до Вас уже интересовался тем, что Вам не понятно. Сначала ищите информацию в мануалах, документациях, форумах, разделах FAQ, а только потом, в случае неудачи, спрашивайте у других.
Костыли
У новичков код пестрит неочевидными ходами и решениями. Некоторые из них появляются в результате того, что при тестировании программа начинает вести себя не так, как ожидается. Вместо того, чтобы докопаться до сути проблемы, неопытный программист на скорую руку начинает вставлять в код заплатки, которые уродуют программу.Доходит до смешного. Например, на сайте была форма, куда пользователь должен был ввести число от 0 до 999. Вместо того, чтобы получить из поля данные и проверить, действительно ли это число находится в заданном диапазоне, человек сделал проверку на количество символов не больше трех.В итоге в логике программы становится трудно разобраться. Ещё сложнее становится вносить изменения и расширять функционал.
«Этого точно никогда не будет»
Любимая тема новичка – игнорировать обработку некорректных входных данных. Мотив – «этого точно никогда не будет» А ведь будет наверняка! Закон программистской подлости – случится именно то, чего ты не предусмотрел. Надо быть готовым, что там, где должны ввести год рождения, будут вводить все, что угодно, кроме нужных четырех цифр. При этом еще нужно придумать правильные ограничивающие условия.
Некрасивый код
Стоит ли говорить, что вначале многие не задумываются о длине строчек кода, размере функции, забывают о комментариях и т.д.Не задумываются в основном потому, что не имеют опыта длительной разработки, когда начинаешь понимать, что всё то, что на первый взгляд кажется мелочью, на самом деле очень важно для жизнеспособности программы в дальнейшем.
Не получилось с первого раза – ищем простой путь
Учимся на своих ошибках и не забываем: хорошо написанная программа – плюс один в карму!)
Тем, кто хочет стать программистом, рекомендуем профессию «Веб-разработчик».
Сколько люди будут учиться программированию, столько будут совершать одни и те же ошибки. Существуют грабли, на которые просто невозможно не наступить. Тем не менее н ебольшая ошибка в начале разработки может обернуться сильной головной болью для программиста и его коллег в будущем. Х очется верить, что читатели этой статьи смогут сократить количество неверно принятых решений в ходе разработки программ до минимума.
Неумение кататься на велосипедах
Использование неподходящих средств разработки
Вопросы, на которые уже 100 раз ответили
Перед тем, как начать спрашивать что-либо на форумах и в сообществах, просто поищите ответ на свой вопрос. Если Вы начинающий программист, то наверняка кто-то до Вас уже интересовался тем, что Вам не понятно. Сначала ищите информацию в мануалах, документациях, форумах, разделах FAQ, а только потом, в случае неудачи, спрашивайте у других.
Костыли
У новичков код пестрит неочевидными ходами и решениями. Некоторые из них появляются в результате того, что при тестировании программа начинает вести себя не так, как ожидается. Вместо того, чтобы докопаться до сути проблемы, неопытный программист на скорую руку начинает вставлять в код заплатки, которые уродуют программу.Доходит до смешного. Например, на сайте была форма, куда пользователь должен был ввести число от 0 до 999. Вместо того, чтобы получить из поля данные и проверить, действительно ли это число находится в заданном диапазоне, человек сделал проверку на количество символов не больше трех.В итоге в логике программы становится трудно разобраться. Ещё сложнее становится вносить изменения и расширять функционал.
«Этого точно никогда не будет»
Любимая тема новичка – игнорировать обработку некорректных входных данных. Мотив – «этого точно никогда не будет» А ведь будет наверняка! Закон программистской подлости – случится именно то, чего ты не предусмотрел. Надо быть готовым, что там, где должны ввести год рождения, будут вводить все, что угодно, кроме нужных четырех цифр. При этом еще нужно придумать правильные ограничивающие условия.
Некрасивый код
Стоит ли говорить, что вначале многие не задумываются о длине строчек кода, размере функции, забывают о комментариях и т.д.Не задумываются в основном потому, что не имеют опыта длительной разработки, когда начинаешь понимать, что всё то, что на первый взгляд кажется мелочью, на самом деле очень важно для жизнеспособности программы в дальнейшем.
Не получилось с первого раза – ищем простой путь
Учимся на своих ошибках и не забываем: хорошо написанная программа – плюс один в карму!)
Тем, кто хочет стать программистом, рекомендуем профессию «Веб-разработчик».