Насколько полезно писать велосипеды?
Здравствуйте.
Работаю как Junior React-разработчик (React 18, Redux, TypeScript) уже 3-й месяц.
Столкнулся с тем, что более-менее нестандартные задачи, требующие более глубокого понимания работы всех механизмов мне очень сложно даются (например четкое понимание асинхронности, работы с промисами и callback-функциями).
Задачи, такие как создание новых страниц в приложении на основе старых, подключение запросов, прикручивание пагинации, копипаст экшенов, редюсеров и.т.д и.т.п решаются относительно просто, т.к есть на что опереться. Нужно создать новую страницу с таблицей данных, фильтрами, поиском и сортировкой - посмотрел уже готовую страницу, взял готовые куски, переделал под себя, все проверил - готово.
Если же задача требует четкого понимания каждого шага работы программы - тут сразу проблема.
Насколько полезно будет, например, отойти на время от готового React, Axios и.т.д., и попробовать, например, реализовать что-то на чистом JS, используя модули, fetch и все нативное? Или это больше бесполезная трата времени?
Думается, что при написании велосипедов и использовании только нативных возможностей языка и браузера, при конструировании приложения лично сталкиваешься с проблемами, эффективным решением которых занимаются готовые библиотеки. И вот тогда суть улавливается.
Работая с готовыми библиотеками куда не плюнешь - везде абстракции над абстракциями. А хочется самую суть уловить и уложить в голове, чтобы получился крепкий фундамент.
Начал писать пет-проект опять же на React, но чувствуется, что и там много пробелов.
Основная цель - получить крепкие фундаментальные знания по JS и веб-разработке в целом, при этом продолжая использовать React, как основной инструмент в настоящем и будущем.
Может вы что-то подскажете и поделитесь своим опытом. Буду благодарен.
Дополнительно:
Ответы:
Думается, что при написании велосипедов и использовании только нативных возможностей языка и браузера, при конструировании приложения лично сталкиваешься с проблемами, эффективным решением которых занимаются готовые библиотеки. И вот тогда суть улавливается.
Хорошо сказано.
Пишите в качестве пэт-проекта, демо или пруф-оф-консепт. В прод велосипеды тащить не надо.
Есть ещё ненулевой шанс, что ваш велосипед окажется пригодным для серийного производства.
работа инженера это складывание решение из кирпичей.
новый кирпич изготовить очень дорого. так что четко понимайте зачем вам этот костыль
Я зашел в разработку на стеке Vue и его окружения Nuxt, Vuex и т.п.
Начал копать в суть вещей только уже когда понял, что могу что то делать, но уперса в то, что не понимаю как некоторые вещи работают под капотом и это мешает мне делать задачи => недает расти по ЗП.
В общем есть смысл ковырять, если чувствуешь, что стоишь на месте из за того, что не знаешь как реализовать что либо если делаешь шаг влевовправо.
Если что-то в готовом решении кажется сложным, значит ты не уловил какие именно проблемы успели порешать те, кто это решение писал.
Можно написать свой велосипед, но пока будешь его писать, скорее всего столкнешься с этими проблемами и в попытках решения их собственно напишешь то, что уже сделано.
Писать велосипеды - полезно для себя. Для какихто простых вещей.
В проекте использовать можно, но палка о двух концах - готовое решение в разы проще поддерживать. Возможные баги возможно пофиксят за тебя, тебе просто версию обновить. Если свой проект кому-то передавать то с велосипедами это будет жесть. Разбираться в чужих велосипедах, к которым нет документации - это худшее что может быть.
Поэтому свои велосипеды пиши или в очень простых кейсах или когда уже будешь четко понимать зачем ты решил не юзать готовое.
смысл в том что надо всё делать стандартно
для всего гуглить готовое решение
чтобы тебя можно было в любой момент уволить и без тебя легко всё поддерживать
для капиталиста нет ничего важнее этого
для возможности этого можно пожертвовать качеством
делай свои фреймворки если ты инженер
если у тебя инженерные изобретательские таланты и позывы
а если ты обычный чесальщик-мотальщик кода то изобрерать велосипеды тебе вредно
лучше изучай инструмент, и следи за новыми версиями, то есть вечно страдай
и если повезет - станешь руководителем, и страдать будут другие
Бест практис и патерны быстро меняются. Тот стек технологий и библиотек, который был популярен 3 года назад уже не актуален сегодня, так как все развивается и меняется в быстром темпе, который задается теми, кто понимает, как вещи устроены. Самому менять и выдумывать что-то в продакшене просто приведет к тому, что проект будет зависим от тебя, только ты будешь понимать, что там происходит. Это конечно же не хорошо. Разработка должна быть понятной другим и соответствовать требованиям заказчика прежде всего...
- Какие паттерны быстро меняются?)) Паттерны проектирования описали несколько десятилетий назад. Архитектурые шаблоны - тоже большой скорости развития не наблюдается.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Писать "велосипеды" (то есть, писать свой собственный код, вместо использования готовых решений или библиотек) может быть как полезным, так и не очень полезным, в зависимости от конкретной ситуации.
Полезно писать велосипеды, если вы хотите глубже понять принципы работы определенных алгоритмов или языков программирования. Это может помочь вам стать более опытным разработчиком и лучше понимать, как работает ваш код.
Также, писание велосипедов может быть полезно в случае, если вы сталкиваетесь с очень специфической задачей, для которой нет готового решения или библиотеки. В этом случае, написание собственного кода может быть единственным способом решения проблемы.
Однако, писать велосипеды не всегда полезно. Если у вас ограниченное время на выполнение проекта, использование готовых решений или библиотек может значительно сократить время разработки и улучшить качество кода за счет использования проверенных и оптимизированных решений.
Также, писание велосипедов может привести к повторению уже существующего кода, что может привести к увеличению объема кода и усложнению его поддержки в будущем.
В итоге, решение о том, стоит ли писать велосипеды, зависит от конкретной ситуации. Важно оценить все плюсы и минусы перед тем, как принять решение.
Писать "велосипеды" в программировании, то есть создавать свои собственные решения для уже существующих проблем, может быть как полезным, так и вредным в зависимости от конкретной ситуации. Вот несколько аспектов, которые стоит учитывать при принятии решения о том, стоит ли писать "велосипеды":
1. Обучение и понимание: Писать свои собственные решения помогает углубить понимание языка программирования, алгоритмов и структур данных. Это может быть особенно полезно для начинающих разработчиков, которые могут изучить основы программирования на практике.
2. Уникальность: Иногда стандартные библиотеки или фреймворки не могут полностью удовлетворить требования проекта. В таких случаях написание собственных решений может быть необходимо для достижения желаемой функциональности.
3. Эффективность: Иногда использование готовых решений может быть излишне сложным или неэффективным с точки зрения производительности. Написание оптимизированных "велосипедов" может помочь улучшить производительность приложения.
Однако есть и недостатки в написании "велосипедов":
1. Переизобретение колеса: Написание собственных решений может быть излишним, если уже существуют проверенные и надежные библиотеки или фреймворки, которые могут решить вашу проблему.
2. Уязвимости и ошибки: При написании собственных решений есть риск допустить ошибки или уязвимости, которые могут быть избежаны при использовании стандартных решений.
3. Обслуживание и поддержка: Писать "велосипеды" требует времени и усилий на их обслуживание и поддержку. Если вы создали свое собственное решение, вам придется самостоятельно обновлять его и исправлять ошибки.
Итак, прежде чем принять решение о том, стоит ли писать "велосипеды", необходимо внимательно взвесить все плюсы и минусы и решить, что будет наиболее эффективным и удовлетворяющим для вашего проекта.