Добрый день. Понимаю, что вопрос максимально обширный, заезженный и кроме боли не вызывает ничего.
Я попробую уточнить его чтобы смягчить гнев.
Ситуация следующая, на данный момент я имею уровень middle во фронте, работаю с одним из фреймворков.
Есть мысли начать изучать один из доступных серверных языков, но к сожалению я не имею ни малейшего представления, какой язык предпочтительнее выбрать, что вообще нужно знать для бека, слышал мельком о каких то базах данных, но убежден, что этого не достаточно. Интересует скорее не сам язык , а те технологии, что окружают его.
Да, естественно в сети полно информации, но это боль читать всё что попадает под глаза и пока я смогу сам понять что из этого мусор, а что нет - пройдет много времени.
Нет цели сесть и выучить язык за 2-3мес и устроиться на работу.
Правильно ли я понимаю, если речь идет о web разработке(backend), то принцип работы связанной с базами данных, протоколами и т.п. остается одним и тем же меняется только язык ?
Прошу прощения если вопрос звучит глупо, сказывается недостаток знаний.
И нужно ли знать ООП для backend'a или это зависит от языка ? На фронте современном мало используются принципы ООП, в основном функционально пишем код , отсюда уровень знаний и опыта в ООП минимальный
В общем это скорее просьба, чем вопрос к людям опытным, которые уже прошли подобный путь. Можете ли вы посоветовать язык и в зависимости от языка указать какую-то структуру того что нужно читать и с чем придется работать(может какие-то порталы, книги, статьи). Или возможно язык не имеет значения и с ним я смогу определиться сам, но есть стек технологии , которые нужно знать вне зависимости от языка.
noxplex, он может и сеньор быть с 1 фреймворком, например синьор ангуляр девелопер, но в то же время джун реакт, и это даже полезнее для него чем знать 500 разных.
bro-dev, Нет, не бывает синьоров одного фреймворка, нигде и никогда. Мидл одного фреймворка - это ещё возможно, но синьор нет. Если вам где-то скажут что есть - это самозванцы. Потому что синьор это не только и не столько про знание инструментов, а ещё про системное понимание и кругозор.
Технологии и прикладнуха - дело наживное, да и к тому же тут достаточно об этом написали.
Пару слов от себя вставлю: язык и фреймворк выбрать - вообще не проблема. Если js, то это nodejs+express, если java, то java+kotlin+gradle+spring, я лично изучаю на досуге Elixir и Phoenix.
Вот пара мыслей, какие фундаментальные темы нужно усвоить для перехода в бэк, а языки и фреймворки уже в последнюю очередь пойдут:
Основы операционных систем
Основы реляционных баз данных
Виртуализация и контейнеры
Configuration management (CI\CD, IaC, ansimble, automation)
Парадигмы и основы программирования (без этого вообще никуда, я бы сказал до уровня middle во фронтенде даже без этого не дойти).
Главный совет - не нужно распыляться. Виделите для себя что-то одно на первое время и постепенно в комфортном для себя ритме изучайте по разным источниками (курсы, статьи, большие книги, видео, общение с другими людьми, пет-проджекты).
Можешь прямо на JS начинать. Сначала научись поднимать сервак на ноде (NodeJS). Потом попробуй поработать с фреймворками вроде ReactJS, AngularJS. Пойми как работают БД. Пойми основы роутинга. Попробуй написать свои скрипты обработки URL. Попробуй создать свой API. Научись как правильно делать запросы к серваку, а дальше само собой свяжется с помощью гугла и кучи проблем) Без понимания ООП будет сложно. Особенно сложно будет читать чужой код, ведь ООП сейчас почти везде. И пожалуй самый главный совет новичку в бэке: "Помни о принципе единичной ответственности: в любой программе всегда должен быть только один вход"(сам недавно бэком начал интересоваться, и этот совет пожалуй был самым полезным). Главное просто не сдавайся и пытайся выделять времени, сколько не жалко. Если с JS трудновато, можешь с пихи(PHP) начать попробовать. Там легче для новичков, ИМХО, потому что не требуется использовать сторонние библиотеки для реализации тех или иных действий... В JS же иногда для реализации задумок требуется подключать дополнительные библиотеки, разбираться как она работает и.т.д., что для новичков по началу сложно, потому что они и так получают много информации
Помни о принципе единичной ответственности: в любой программе всегда должен быть только один вход
Уж простите, но это нонсенс какой-то. SRP вообще про другое.
Если взять терминологию DDD, то у нас есть 4 слоя: domain, application, infrastructure, interfaces.
Набор бизнес-сущностей (модели) и бизнес-сервисов (валидация, итд) в domain layer.
"Описание" логики работы приложения (use-cases) в application layer (может быть известен, как service layer).
Имплементация работы с базой/логгерами/3rd-party services в infrastructure layer.
И как раз веб/консоль входы в interfaces layer.
То есть, один use-case может спокойно иметь несколько входов через interfaces layer, будь это REST API, консоль, SOAP, whatever.
Бэкенд разделяется как минимум на четыре части:
- язык для программирования приложения
- администрация базы данных
- администрация сервера и операционной системы
- DevOps
Языки для программирования приложения:
- JavaScript + Node.js/Express.js любимчик хипстеров и стартапов: так как у вас или как минимум у меня нет конкретных представлений о том что вы хотите не нужно далеко идти. Знания Node.js поможет вам и с фронтондом, так как Webpack работает с Express.js а индивидуальная настройка Webpack огромный pain in the ass и с поиском работы среди хипстерских компаний.
- PHP/Symfony. PHP - любимчик пролетариата - всегда хороший выбор. Язык написан как и JavaScript специально для вэб-приложений. Маленькие проекты реализуются очень быстро благодаря отсутствию каких либо рамок со стороны языка. От сюда же и плохая репутация этого языка так как очень много (с точки зрения ООП архитектуры) не грамотно созданных проектов на PHP, среди которых самый известный это WordPress. Но PHP полноценный язык программирования и нет больших объективных поводов поливать его грязью как это любят делать сектанты JavaScript, Java, Ruby, Python итп (хотя и каждый из этих языков поливается грязью сектантами других языков). Фреймворк для enterprise level: Symfony + Doctrine ( ужасное дерьмо, нужно только реально для enterprise level - для личных проектов Doctrine лучше избегать и использовать PDO). Практически все популярные eCommerce системы написаны на PHP (WooCommerce, Magento, Shopify, Shopware). Ну а про WordPress вообще говорить нечего. 35% сайтов работают с WordPress. WordPress с технологической точки зрения не самый лучший Framework, но так как самый популярный среди пользователей, то экспертиза в этой сфере всегда поможет вам с работой на фрилансе. Хотя пользователи WordPress в среднем не самые платежеспособные клиенты. Но есть (где то) и клиенты которые готовы платить десятки тысяч долларов за проект на основе WordPress.
- Java/Spring - любимчик корпораций: практически все индивидуальные разработки больших корпораций делаются на Java (если не учитывать языки Microsoft). Популярный fullstack генератор для проектов на Java: JHipster. Сектанты Java ненавидят всех и являются главным источником шитстормов против всех остальных языков. По крайней мере мне так кажется. Одно из больших преимуществ Java: можно писать приложения как для вэба, так и для мобайл и десктопа.
- Kotlin - язык программирования от русской компании JetBrains который должен в длительной перспективе заменить Java для Android, из-за каких то разногласий между Google и Oracle. Kotlin был развит на основе Java и на сколько я знаю можно всё что написано на Java (как то) использовать с Котлин. Котлин любят все как мне кажется. Ребята от JetBrains знают на генетическом уровне что нужно разработчику. По крайней мере мне так кажется когда работаю с их продуктами (PhpStorm/WebStorm + DataGrip).
- Python/Django: супер универсальный язык который популярен как для разработки веб-приложений так и в научной сфере и сфере искусственного интеллекта. Говорят его так же легко выучить как и PHP. От сюда же наверное и шитстормы в его сторону, хотя конечно их меньше чем в сторону PHP. Язык так же популярен среди хакеров и является главным языком для программирования crawler ботов. YouTube написан на Python
- Ruby (on Rails): ничего не знаю об этом языке/фрэймворке кроме того что относительно много компаний среднего уровня его используют.
- C/C++: веб-фреймворков для этих языков практически нет. Но это самые быстрые языки из всех перечисленных. Эти языки используются для всего где скорость играет большую роль (видео обработка например). JavaScript, все программы от Adobe CC, а также Ableton Live написаны на C++. Linux Kernel и PHP написаны на C. Также это главные языки для электроприборов/микроконтроллеров и поэтому в сфере IoT. Возможно эти языки начнут также играть большую роль во фронтенд!!! благодаря WebAssembly, что делает (теоретически) возможным переносить такие программы как Photoshop, Illustrator, Premiere Pro, After Effects, Ableton Live или же игры как Counter Strike полностью в броузер. Если бы я начинал учить новый бэкенд язык я бы начал с C/C++.
Сам язык там упоминается вскользь и без определенного указания предпочитаемого языка так как по факту толковому бекендеру уже всё равно на каком языке писать.
Бэк != работа только с БД. Как практикующий разработчик, Вы должны иметь представление об архитектуре Вашей системы, даже если Вы - узкоспециализированный фронтенд-разработчик. Например, если бэк предоставляет хорошо задокументированный API, с которым Вы работаете на фронте, то довольно легко представить, как реализовать подобный API с другой стороны.
Зная, какой-либо js-фреймворк, можно было бы попробовать изучить Node.JS в качестве основы для бэка.
Ну а так вообще я за Java+Spring, если речь идёт о серьёзных вещах.
На данный момент я junior, но тоже задавался этим вопросом.
Присматривался к стэку MERN, но пока не совсем ясна робота согласно ACID и что лучше для интернет магазинов и highload проектов.
Сравнение разных бд смотрел, но так же из-за отсутствия знаний пока не понял, что и для чего.
Буду отслеживать ваш вопрос)
Присматривался к стэку MERN, но пока не совсем ясна робота согласно ACID
Вообще в Монгу подвезли ACID ещё в начале 2018г.
Только единственная причина популярности Монги в js стеке это "так исторически сложилось", и помимо этого никаких объективных причин выбирать её нет.
Формально, nosql в том же postgresql появился когда Монги ещё в планах не было.
что лучше для интернет магазинов и highload проектов.
Среднестатистическому интернет-магазину не дорасти до него никогда. Такие решения в начале проекта не делаются.
Евгений Ромашкан, экспертизы нет ни в какой, планирую иузучать и развиваться в сторону бэка.
Присмотрел пока postgresql и mongodb. Но мой выбор необъективен, а основан на "что-то услышал, где-то увидел".
+ преподаватель с КПИ в чате хвалил postgresql, и его мнению я склонен доверять.
Монга и микросервисы связаны примерно никак. Ну, кроме того что микросервисы это тоже модный пушной зверёк который юзают не по назначению, да без опыта в распределённых системах.
Евгений Ромашкан, А я не имел ввиду монгу, я про начальные решения по поводу инет магазинов и прочее, такие решения хорошо дополняются микросервисами на разных языках причем.
я про начальные решения по поводу инет магазинов и прочее, такие решения хорошо дополняются микросервисами на разных языках причем.
Не нужны там микросервисы. На разных языках тем более.
Микросервисы это долго, дорого, сложно и требует проектирования, если вы не хотите монолит распределённый получить. Это не нужно на средних проектах, которые пилятся в одну команду разработчиков.
На начальных этапах развития проекта такие решения не принимаютя.
Влезать в микросервисы без чёткого понимания зачем они вам - глупо. Хоть и много на рынке любителей втащить в прод всё что модно нынче(а через год сменить работу и на новом проекте рассказывать и внедрять, ага).
Евгений Ромашкан, Тоесть чтобы использовать микросервисы нужно обязательно бить монолит? Допустим нужно прикрутить какуюнибудь рассылку емейлов, почему бы не сделать отдельный сервис для этого?
Это займет гораздо меньше времени, чем разбор архитектуры монолита.
Допустим нужно прикрутить какуюнибудь рассылку емейлов, почему бы не сделать отдельный сервис для этого?
Потому что это бесполезно. Зато инфраструктуру и процессы сильно усложнит.
Это займет гораздо меньше времени, чем разбор архитектуры монолита.
Ну вот, собственно, и корень проблемы.
И решением будет разбираться, почему у монолита такая архитектура, что её нужно долго разбирать, а не пытаться найти инструмент который за факт использования все проблемы решит.
Обычно желание распилить всё на микросервисы исходит от команд, которые в проектирование и декомпозицию, вобщем то, не умеют. То есть не представляют что монолит тоже может быть модульным, не дергать любые части системы, или там, общаться через очередь.
Decoupling это в первую очередь про умение разработчиков проектировать, микросервисы это хоть и чуть более явные границы, но и нарушать их больнее, и менять.
Вобщем, если команда построила такой монолит что в нём не ясно куда сервис рассылки емейлов впихнуть - с микросервисами у них всё станет только хуже.
Евгений Ромашкан, В принципе я с Вами согласен, если речь идет о командной работе, то так и есть.
У самого был случай на собеседовании, команда хвасталась тем что разбила инет магазин на микросервисы полностью (долго сидел с фейспалмом).
Кстати у микросерисов еще может быть утечка безопасности (микросервисы на серверах не принадлежащих компании, всмысле что компания не вкурсе об их аренде и не имеет доступа), такое иногда случается когда в бэкенде только пара человек =)
Но для фрилансе микросервисы как гарантия оплаты заказчика просто идеальна
На Java лавочка закрыта - тонны полностью готового инструментария, а junior'ов берут только на BPM (что полностью бесперспективно). Так-же тонны слоев абстракций даже для простейших вещей. Что-бы банально сложить 2 + 2, существуют несколько путей (и обязательно столько же не официальных) =) можно унаследовать Number класс, от него создать свой класс Integer и тд - вообщем полный бред.
Да и вообще начинать бекенд с c# или java нужно уже иметь опыт на скриптах, иначе почти 100% ваши временные затраты не окупятся и даже если есть постоянный клиент он обязательно уйдет на PHP или обратиться в контору.
Средний
Простой
Средний
Простой
